PPP in Frame Relay
How the Point-to-Point Protocol is carried inside Frame Relay frames, and how the two ends tell PPP apart from other traffic.
Simpson, W., "PPP in Frame Relay", RFC 1973, DOI 10.17487/RFC1973, June 1996, <https://www.rfc-editor.org/info/rfc1973>.
@misc{rfc1973,
series = {Request for Comments},
number = 1973,
howpublished = {RFC 1973},
publisher = {RFC Editor},
doi = {10.17487/RFC1973},
url = {https://www.rfc-editor.org/info/rfc1973},
author = {W. Simpson},
title = {{PPP in Frame Relay}},
pagetotal = 10,
year = 1996,
month = jun,
} RFC text
Contents
Network Working Group W. Simpson
Request for Comments: 1973 Daydreamer
Category: Standards Track June 1996
PPP in Frame Relay
Status of this Memo
This document specifies an Internet standards track protocol for
the Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Abstract
The Point-to-Point Protocol (PPP) [1] provides a standard method for
transporting multi-protocol datagrams over point-to-point links.
This document describes the use of Frame Relay for framing PPP
encapsulated packets.
Applicability
This specification is intended for those implementations which desire
to use facilities which are defined for PPP, such as the Link Control
Protocol, Network-layer Control Protocols, authentication, and
compression. These capabilities require a point-to-point
relationship between peers, and are not designed for multi-point or
multi-access environments.
Table of Contents
1. Introduction .......................................... 1
2. Physical Layer Requirements ........................... 1
3. The Data Link Layer ................................... 2
3.1 Frame Format .................................... 2
3.2 Modification of the Basic Frame ................. 3
4. In-Band Protocol Demultiplexing ....................... 4
5. Out-of-Band signaling ................................. 5
6. Configuration Details ................................. 5
SECURITY CONSIDERATIONS ...................................... 7
REFERENCES ................................................... 7
ACKNOWLEDGEMENTS ............................................. 7
CHAIR'S ADDRESS .............................................. 8
AUTHOR'S ADDRESS ............................................. 8
1. Introduction
Frame Relay [2] is a relative newcomer to the serial link community.
Like X.25, the protocol was designed to provide virtual circuits for
connections between stations attached to the same Frame Relay
network. The improvement over X.25 is that Q.922 is restricted to
delivery of packets, and dispenses with sequencing and flow control,
simplifying the service immensely.
PPP uses ISO 3309 HDLC as a basis for its framing [3].
When Frame Relay is configured as a point-to-point circuit, PPP can
use Frame Relay as a framing mechanism, ignoring its other features.
This is equivalent to the technique used to carry SNAP headers over
Frame Relay [4].
At one time, it had been hoped that PPP in HDLC-like frames and Frame
Relay would co-exist on the same links. Unfortunately, the Q.922
method for expanding the address from 1 to 2 to 4 octets is not
indistinguishable from the ISO 3309 method, due to the structure of
its Data Link Connection Identifier (DLCI) subfields. Co-existance
is precluded.
2. Physical Layer Requirements
PPP treats Frame Relay framing as a bit-synchronous link. The link
MUST be full-duplex, but MAY be either dedicated (permanent) or
switched.
Interface Format
PPP presents an octet interface to the physical layer. There is
no provision for sub-octets to be supplied or accepted.
Transmission Rate
PPP does not impose any restrictions regarding transmission rate,
other than that of the particular Frame Relay interface.
Control Signals
Implementation of Frame Relay requires the provision of control
signals, which indicate when the link has become connected or
disconnected. These in turn provide the Up and Down events to the
LCP state machine.
Because PPP does not normally require the use of control signals,
the failure of such signals MUST NOT affect correct operation of
PPP. Implications are discussed in [2].
Encoding
The definition of various encodings is the responsibility of the
DTE/DCE equipment in use, and is outside the scope of this
specification.
While PPP will operate without regard to the underlying
representation of the bit stream, Frame Relay requires NRZ
encoding.
3. The Data Link Layer
This specification uses the principles, terminology, and frame
structure described in "Multiprotocol Interconnect over Frame Relay"
[4].
The purpose of this specification is not to document what is already
standardized in [4]. Instead, this document attempts to give a
concise summary and point out specific options and features used by
PPP.
3.1. Frame Format
As described in [4], Q.922 header address and control fields are
combined with the Network Layer Protocol Identifier (NLPID), which
identifies the encapsulation which follows. The fields are
transmitted from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| Flag (0x7e) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Q.922 Address | Control | NLPID(0xcf) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The PPP Protocol field and the following Information and Padding
fields are described in the Point-to-Point Protocol Encapsulation
[1].
3.2. Modification of the Basic Frame
The Link Control Protocol can negotiate modifications to the basic
frame structure. However, modified frames will always be clearly
distinguishable from standard frames.
Address-and-Control-Field-Compression
Because the Address and Control field values are not constant, and
are modified as the frame is transported by the network switching
fabric, Address-and-Control-Field-Compression MUST NOT be
negotiated.
Protocol-Field-Compression
Note that unlike PPP in HDLC-like framing, the Frame Relay framing
does not align the Information field on a 32-bit boundary.
Alignment to a 32-bit boundary occurs when the NLPID is removed
and the Protocol field is compressed to a single octet. When this
improves throughput, Protocol-Field-Compression SHOULD be
negotiated.
4. In-Band Protocol Demultiplexing
The PPP NLPID (CF hex) and PPP Protocol fields easily distinguish the
PPP encapsulation from the other NLPID encapsulations described in
[4].
The joining of the PPP and NLPID number space has an added advantage,
in that the LCP Protocol-Reject can be used to indicate NLPIDs that
are not recognized. This can eliminate "black-holes" that occur when
traffic is not supported.
For those network-layer protocols which have no PPP Protocol
assignment, or which have not yet been implemented under the PPP
encapsulation, or which have not been successfully negotiated by a
PPP NCP, another method of encapsulation defined under [4] SHOULD be
used.
Currently, there are no conflicts between NLPID and PPP Protocol
values. If a future implementation is configured to send a NLPID
value which is the same as a compressed Protocol field, that Protocol
field MUST NOT be sent compressed.
On reception, the first octet following the header is examined. If
the octet is zero, it MUST be assumed that the packet is formatted
according to [4].
PPP encapsulated packets always have a non-zero octet following the
header. If the octet is not the PPP NLPID value (CF hex), and
Protocol-Field-Compression is enabled, and the associated NCP has
been negotiated, then it is expected to be a compressed PPP Protocol
value. Otherwise, it MUST be assumed that the packet is formatted
according to [4].
The Protocol field value 0x00cf is not allowed (reserved) to avoid
ambiguity when Protocol-Field-Compression is enabled. The value MAY
be treated as a PPP Protocol that indicates that another PPP Protocol
packet follows.
Initial LCP packets contain the sequence cf-c0-21 following the
header. When a LCP Configure-Request packet is received and
recognized, the PPP link enters Link Establishment phase.
The accidental connection of a link to feed a multipoint network (or
multicast group) SHOULD result in a misconfiguration indication.
This can be detected by multiple responses to the LCP Configure-
Request with the same Identifier, coming from different framing
addresses. Some implementations might be physically unable to either
log or report such information.
Once PPP has entered the Link Establishment phase, packets with other
NLPID values MUST NOT be sent, and on receipt such packets MUST be
silently discarded, until the PPP link enters the Network-Layer
Protocol phase.
Once PPP has entered the Network-Layer Protocol phase, and
successfully negotiated a particular NCP for a PPP Protocol, if a
frame arrives using another equivalent data encapsulation defined in
[4], the PPP Link MUST re-enter Link Establishment phase and send a
new LCP Configure-Request. This prevents "black-holes" that occur
when the peer loses state.
An implementation which requires PPP link configuration, and other
PPP negotiated features (such as authentication), MAY enter
Termination phase when configuration fails. Otherwise, when the
Configure-Request sender reaches the Max-Configure limit, it MUST
fall back to send only frames encapsulated according to [4].
5. Out-of-Band signaling
There is no generally agreed method of out-of-band signalling. Until
such a method is universally available, an implementation MUST use
In-Band Protocol Demultiplexing for both Permanent and Switched
Virtual Circuits.
6. Configuration Details
The following Configuration Options are recommended:
Magic Number
Protocol Field Compression
The standard LCP configuration defaults apply to Frame Relay links,
except Maximum-Receive-Unit (MRU).
To ensure interoperability with existing Frame Relay implementations,
the initial MRU is 1600 octets [4]. This only affects the minimum
required buffer space available for receiving packets, not the size
of packets sent.
The typical network feeding the link is likely to have a MRU of
either 1500, or 2048 or greater. To avoid fragmentation, the
Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT
exceed 1500, unless a peer MRU of 2048 or greater is specifically
negotiated.
Some Frame Relay switches are only capable of 262 octet frames. It
is not recommended that anyone deploy or use a switch which is
capable of less than 1600 octet frames. However, PPP implementations
MUST be configurable to limit the size of LCP packets which are sent
to 259 octets (which leaves room for the NLPID and Protocol fields),
until LCP negotiation is complete.
XID negotiation is not required to be supported for links which are
capable of PPP negotiation.
Inverse ARP is not required to be supported for PPP links. That
function is provided by PPP NCP negotiation.
Security Considerations
Security issues are not discussed in this memo.
References
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[2] CCITT Recommendation Q.922, "ISDN Data Link Layer Specification
for Frame Mode Bearer Services", International Telegraph and
Telephone Consultative Committee, 1992.
[3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51,
RFC 1662, July 1994.
[4] Bradley, T., Brown, C., and A. Malis, "Multiprotocol
Interconnect over Frame Relay", RFC 1490, July 1993.
[5] ISO/IEC TR 9577:1990(E), "Information technology -
Telecommunications and Information exchange between systems -
Protocol Identification in the network layer", 1990-10-15.
Acknowledgments
This design was inspired by the paper "Parameter Negotiation for the
Multiprotocol Interconnect", Keith Sklower and Clifford Frost,
University of California, Berkeley, 1992, unpublished.
Chair's Address
The working group can be contacted via the current chair:
Karl Fox
Ascend Communications
3518 Riverside Drive, Suite 101
Columbus, Ohio 43221
EMail: karl@ascend.com
Author's Address
Questions about this memo can also be directed to:
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
ISO Plain Language
On this page
§1What This Document Describes
The Point-to-Point Protocol provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the use of Frame Relay for framing PPP encapsulated packets.
The specification is intended for implementations that want to use the facilities defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication and compression. These capabilities require a point-to-point relationship between peers, and are not designed for multi-point or multi-access environments.
Frame Relay is a relative newcomer to the serial link community. Like X.25, the protocol was designed to provide virtual circuits for connections between stations attached to the same Frame Relay network. The improvement over X.25 is that Q.922 is restricted to delivery of packets, and dispenses with sequencing and flow control, simplifying the service immensely. PPP uses ISO 3309 HDLC as a basis for its framing.
When Frame Relay is configured as a point-to-point circuit, PPP can use Frame Relay as a framing mechanism, ignoring its other features. This is equivalent to the technique used to carry SNAP headers over Frame Relay.
At one time it had been hoped that PPP in HDLC-like frames and Frame Relay would co-exist on the same links. Unfortunately, the Q.922 method for expanding the address from 1 to 2 to 4 octets is not indistinguishable from the ISO 3309 method, due to the structure of its Data Link Connection Identifier subfields, so co-existence is precluded.
Frame Relay frames carry an address that grows in steps of one, two or four octets, and the steps look different from the ones used by HDLC-style framing. The two schemes therefore cannot share the same link, and PPP has to be carried on its own.
§2Physical Layer Requirements
PPP treats Frame Relay framing as a bit-synchronous link. The link MUST be full-duplex, but MAY be either dedicated, meaning permanent, or switched.
PPP presents an octet interface to the physical layer. There is no provision for sub-octets to be supplied or accepted. PPP does not impose any restrictions regarding transmission rate, other than that of the particular Frame Relay interface.
Implementation of Frame Relay requires the provision of control signals, which indicate when the link has become connected or disconnected. These in turn provide the Up and Down events to the LCP state machine. Because PPP does not normally require the use of control signals, the failure of such signals MUST NOT affect correct operation of PPP.
The definition of various encodings is the responsibility of the DTE and DCE equipment in use, and is outside the scope of this specification. While PPP operates without regard to the underlying representation of the bit stream, Frame Relay requires NRZ encoding.
The link has to run in both directions at once, and it may be a permanent line or a switched one. PPP hands the hardware whole octets at a time and does not care how the bits are represented on the wire, although Frame Relay requires a particular encoding.
§3.1The Frame Format
This specification uses the principles, terminology and frame structure described in Multiprotocol Interconnect over Frame Relay. The purpose of the specification is not to document what is already standardized there; instead it gives a concise summary and points out the specific options and features used by PPP.
As described there, the Q.922 header address and control fields are combined with the Network Layer Protocol Identifier, which identifies the encapsulation that follows, and the fields are transmitted from left to right. The frame carries a flag octet, the Q.922 address, a control octet, an NLPID octet whose value identifies the PPP encapsulation, and then the PPP Protocol field. The PPP Protocol field and the following Information and Padding fields are described in the Point-to-Point Protocol encapsulation document.
Each Frame Relay frame gets one extra octet that says what kind of payload follows, and PPP puts its own protocol field after that. The rest of the frame is the ordinary Frame Relay address and control octets.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
FLAG | Flag | 1 byte | Frame delimiter, value 0x7e. | |
ADDRESS | Q.922 Address | 2 bytes | 16 bits | Frame Relay address, expanded in steps as the frame crosses the network. |
CONTROL | Control | 1 byte | Q.922 control field. | |
NLPID | NLPID | 1 byte | 0xcf | Identifies the encapsulation that follows; 0xcf marks PPP. |
PROTOCOL | PPP Protocol | 2 bytes | The PPP protocol field, followed by Information and Padding. |
§3.2Modifications to the Basic Frame
The Link Control Protocol can negotiate modifications to the basic frame structure. However, modified frames will always be clearly distinguishable from standard frames.
Address-and-Control-Field-Compression. Because the Address and Control field values are not constant, and are modified as the frame is transported by the network switching fabric, Address-and-Control-Field-Compression MUST NOT be negotiated.
Protocol-Field-Compression. Unlike PPP in HDLC-like framing, the Frame Relay framing does not align the Information field on a 32-bit boundary. Alignment to a 32-bit boundary occurs when the NLPID is removed and the Protocol field is compressed to a single octet. When this improves throughput, Protocol-Field-Compression SHOULD be negotiated.
PPP can normally shrink its two-byte protocol number to one byte, and on Frame Relay that also puts the payload back on a 32-bit boundary, which saves copying. The address and control octets cannot be compressed, because the network rewrites them as the frame crosses each switch.
§4In-Band Protocol Demultiplexing
The PPP NLPID, whose value is CF in hex, and the PPP Protocol fields easily distinguish the PPP encapsulation from the other NLPID encapsulations. The joining of the PPP and NLPID number space has an added advantage, in that the LCP Protocol-Reject can be used to indicate NLPIDs that are not recognized, which can eliminate the black holes that occur when traffic is not supported.
For network-layer protocols that have no PPP Protocol assignment, or that have not yet been implemented under the PPP encapsulation, or that have not been successfully negotiated by a PPP NCP, another method of encapsulation defined for Frame Relay SHOULD be used.
Currently there are no conflicts between NLPID and PPP Protocol values. If a future implementation is configured to send an NLPID value that is the same as a compressed Protocol field, that Protocol field MUST NOT be sent compressed.
On reception, the first octet following the header is examined. If the octet is zero, it MUST be assumed that the packet is formatted according to the Frame Relay multiprotocol specification. PPP encapsulated packets always have a non-zero octet following the header. If the octet is not the PPP NLPID value, and Protocol-Field-Compression is enabled, and the associated NCP has been negotiated, then it is expected to be a compressed PPP Protocol value. Otherwise, it MUST be assumed that the packet is formatted according to the Frame Relay multiprotocol specification. The Protocol field value 0x00cf is not allowed, being reserved, to avoid ambiguity when Protocol-Field-Compression is enabled; the value MAY be treated as a PPP Protocol indicating that another PPP Protocol packet follows.
Initial LCP packets contain the sequence cf-c0-21 following the header. When a LCP Configure-Request packet is received and recognized, the PPP link enters the Link Establishment phase. The accidental connection of a link to feed a multipoint network or a multicast group SHOULD result in a misconfiguration indication, which can be detected by multiple responses to the LCP Configure-Request with the same Identifier, coming from different framing addresses.
Once PPP has entered the Link Establishment phase, packets with other NLPID values MUST NOT be sent, and on receipt such packets MUST be silently discarded, until the PPP link enters the Network-Layer Protocol phase. Once PPP has entered the Network-Layer Protocol phase and successfully negotiated a particular NCP for a PPP Protocol, if a frame arrives using another equivalent data encapsulation, the PPP link MUST re-enter the Link Establishment phase and send a new LCP Configure-Request. This prevents black holes that occur when the peer loses state. An implementation that requires PPP link configuration, and other PPP negotiated features such as authentication, MAY enter the Termination phase when configuration fails. Otherwise, when the Configure-Request sender reaches the Max-Configure limit, it MUST fall back to sending only frames encapsulated according to the Frame Relay multiprotocol specification.
Each end looks at the first octet after the Frame Relay header to decide what it has received. Zero means an ordinary Frame Relay payload; the PPP marker means PPP; anything else is either a compressed PPP protocol number or an ordinary payload, depending on what was negotiated. If a peer starts sending the wrong kind of frame, the link renegotiates rather than carrying traffic into a hole.
- The octet is zeroThe packet is formatted as an ordinary Frame Relay multiprotocol payload.
- The octet is 0xcfThe packet is PPP encapsulated.
- Anything elseA compressed PPP Protocol value, if compression is enabled and the NCP was negotiated; otherwise an ordinary Frame Relay payload.
- The value 0x00cfReserved, to avoid ambiguity when protocol field compression is enabled.
- cf-c0-21The sequence that follows the header in initial LCP packets; recognising it starts link establishment.
§5Out-of-Band Signalling
There is no generally agreed method of out-of-band signalling. Until such a method is universally available, an implementation MUST use In-Band Protocol Demultiplexing for both Permanent and Switched Virtual Circuits.
There is no separate signal on the wire that says a virtual circuit is carrying PPP, so the ends have to work it out from the packets themselves. This holds for both permanent and switched circuits.
§6Configuration Details
The document recommends the Magic Number and Protocol Field Compression configuration options, and says that the standard LCP configuration defaults apply to Frame Relay links except for the Maximum-Receive-Unit.
To ensure interoperability with existing Frame Relay implementations, the initial MRU is 1600 octets. This affects only the minimum required buffer space available for receiving packets, not the size of packets sent. The typical network feeding the link is likely to have an MRU of either 1500, or 2048 or greater, so to avoid fragmentation the Maximum-Transmission-Unit at the network layer SHOULD NOT exceed 1500, unless a peer MRU of 2048 or greater is specifically negotiated.
Some Frame Relay switches are only capable of 262 octet frames. It is not recommended that anyone deploy or use a switch which is capable of less than 1600 octet frames. However, PPP implementations MUST be configurable to limit the size of LCP packets which are sent to 259 octets, which leaves room for the NLPID and Protocol fields, until LCP negotiation is complete.
XID negotiation is not required to be supported for links which are capable of PPP negotiation, and Inverse ARP is not required to be supported for PPP links, because that function is provided by PPP NCP negotiation.
Before the two ends have agreed anything, they may still be using a small Frame Relay switch, so the link setup packets have to be kept small. Once the link is up, the receive buffer is set to 1600 octets, and the network layer is told not to send packets larger than 1500 unless both ends have negotiated a larger one.
- Magic NumberRecommended configuration option.
- Protocol Field CompressionRecommended configuration option.
- Initial MRU1600 octets, the minimum receive buffer, for interoperability with existing Frame Relay implementations.
- Network-layer MTUShould not exceed 1500 unless a peer MRU of 2048 or greater is negotiated.
- LCP packet sizeMust be configurable to 259 octets, which leaves room for the NLPID and Protocol fields.
- XID and Inverse ARPNot required to be supported, because PPP negotiation provides those functions.
§7Security Considerations
The document says that security issues are not discussed in this memo. The facilities it relies on for authentication are those of PPP itself, described in the Point-to-Point Protocol document.
This document says nothing about security. The authentication it can offer is the authentication PPP already provides, not anything new.