PPP in Frame Relay
Extracted elements (25)
Joining the PPP and NLPID number space allows the LCP Protocol-Reject to indicate unrecognized NLPIDs, eliminating 'black-holes' that occur when traffic is not supported. Currently no conflicts exist between NLPID and PPP Protocol values.
PPP uses Frame Relay purely as a framing mechanism on point-to-point circuits, ignoring Frame Relay's virtual-circuit features. This is equivalent to the technique used to carry SNAP headers over Frame Relay (RFC 1490).
Unlike PPP in HDLC-like framing, Frame Relay framing does not align the Information field on a 32-bit boundary; alignment occurs only when the NLPID is removed and the Protocol field is compressed to a single octet, motivating Protocol-Field-Compression negotiation.
PPP in HDLC-like frames and Frame Relay cannot co-exist on the same links because the Q.922 method for expanding the address from 1 to 2 to 4 octets is not distinguishable from the ISO 3309 method due to the structure of DLCI subfields.
Accidental connection to a multipoint network or multicast group SHOULD result in a misconfiguration indication, detectable by multiple responses to an LCP Configure-Request with the same Identifier from different framing addresses.
Address-and-Control-Field-Compression MUST NOT be negotiated, because the Address and Control field values are not constant and are modified as the frame is transported by the network switching fabric.
Because PPP does not normally require the use of control signals, the failure of such signals MUST NOT affect correct operation of PPP.
For network-layer protocols without a PPP Protocol assignment, not yet implemented under PPP encapsulation, or not successfully negotiated by a PPP NCP, another method of encapsulation defined under RFC 1490 SHOULD be used.
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, to avoid ambiguity.
On reception, if the first octet following the header is zero, it MUST be assumed that the packet is formatted according to RFC 1490 (not PPP encapsulation).
Once in the Network-Layer Protocol phase, if a frame arrives using another equivalent data encapsulation defined in RFC 1490, the PPP Link MUST re-enter Link Establishment phase and send a new LCP Configure-Request, preventing black-holes when the peer loses state.
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.
PPP implementations MUST be configurable to limit the size of LCP packets sent to 259 octets (leaving room for the NLPID and Protocol fields) until LCP negotiation is complete, to accommodate Frame Relay switches only capable of 262-octet frames.
Protocol-Field-Compression SHOULD be negotiated when it improves throughput, since removing the NLPID and compressing the Protocol field to a single octet achieves 32-bit alignment of the Information field.
The Frame Relay link MUST be full-duplex, but MAY be either dedicated (permanent) or switched.
The Maximum-Transmission-Unit (MTU) at the network layer SHOULD NOT exceed 1500, unless a peer MRU of 2048 or greater is specifically negotiated, to avoid fragmentation.
To ensure interoperability with existing Frame Relay implementations, the initial Maximum-Receive-Unit (MRU) is 1600 octets, overriding the standard LCP configuration default. This affects minimum required buffer space for receiving, not the size of packets sent.
Until a universally agreed out-of-band signaling method is available, an implementation MUST use In-Band Protocol Demultiplexing for both Permanent and Switched Virtual Circuits.
When the Configure-Request sender reaches the Max-Configure limit without completing PPP link configuration, it MUST fall back to send only frames encapsulated according to RFC 1490.
Recommended LCP Configuration Options for Frame Relay links are Magic Number and Protocol Field Compression. XID negotiation is not required, and Inverse ARP is not required since that function is provided by PPP NCP negotiation.
The Network Layer Protocol Identifier (NLPID) value 0xcf (CF hex) identifies PPP encapsulation within the Frame Relay frame, combining with the Q.922 header address and control fields as described in RFC 1490.
The Protocol field value 0x00cf is reserved (not allowed) 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.
The document explicitly states that security issues are not discussed in this memo, providing no authentication, confidentiality, or integrity mechanisms specific to PPP-over-Frame-Relay beyond those available from PPP itself.
Initial LCP packets contain the sequence cf-c0-21 following the header. When a LCP Configure-Request is received and recognized, the PPP link enters Link Establishment phase; on NCP success it enters Network-Layer Protocol phase; on Max-Configure failure it MAY enter Termination phase or fall back to RFC 1490 encapsulation.
The PPP-in-Frame-Relay frame begins with a Flag (0x7e), followed by a 2-octet Q.922 Address field, a 1-octet Control field, NLPID (0xcf), and then the PPP Protocol field followed by PPP Information and Padding. Fields are transmitted left to right.