Network Working Group W A Simpson Internet Draft Daydreamer expires in six months July 1993 PPP in Frame Relay Status of this Memo This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@ucdavis.edu mailing list. Distribution of this memo is unlimited. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' Please check the 1id-abstracts.txt listing contained in the internet-drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the current status of any Internet Draft. 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 datagrams. Simpson expires in six months [Page i] DRAFT PPP in Frame Relay July 1993 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]. At one time, it had been hoped that PPP HDLC 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. 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. Simpson expires in six months [Page 1] DRAFT PPP in Frame Relay July 1993 2. The Data Link Layer This specification uses the principles, terminology, and frame structure of the "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. 2.1. Frame Format The full Q.922 header is easily combined with the smaller HDLC header. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ NLPID This field contains a one octet Network Layer Protocol Identifier (NLPID), which identifies the network layer protocol encapsulated over the Frame Relay virtual circuit, in accordance with the Subsequent Protocol Identifier (SPI) in ISO/IEC TR 9577 [5]. The value used for PPP is CF hex. Protocol Field The Protocol field is two octets and its value identifies the protocol encapsulated in the Information field of the frame. The field is transmitted and received most significant octet first. 2.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. Simpson expires in six months [Page 2] DRAFT PPP in Frame Relay July 1993 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 When Protocol-Field-Compression is negotiated, both the NLPID and Protocol fields are compressed. On transmission, when the Protocol field is compressed to a single octet, the NLPID is omitted. On reception, the NLPID field is examined. If it is not the PPP NLPID value, then it is expected to be a valid PPP Protocol value. The Protocol field value 0x00cf is not allowed (reserved) to avoid ambiguity when Protocol-Field-Compression is enabled. 3. In-Band Frame Format Detection For Permanent Virtual Circuits (PVCs), the NLPID and PPP Protocol fields easily distinguish the PPP encapsulation. Initial LCP packets contain the sequence cf-c0-21 following the header. When a PPP LCP Configure-Request packet is received, the PPP link enters Link Establishment phase. When frames are detected which are not PPP encapsulation frames, they MUST be handled according to [4]. However, once PPP has entered the Link Establishment phase, such frames MUST NOT be sent, and on receipt such frames MUST be silently discarded, until the PPP link enters the Network-Layer Protocol phase. For those network-layer protocols which have no PPP Protocol assignment, or which have not yet been implemented under the PPP encapsulation, another method of encapsulation defined under [4] SHOULD be used. When Protocol-Field-Compression is negotiated, others methods of encapsulation defined under [4] MUST NOT be used. Simpson expires in six months [Page 3] DRAFT PPP in Frame Relay July 1993 4. 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 Frame Format Detection for both Permanent and Switched Virtual Circuits. 5. Configuration Details The accidental connection of a link to feed a Frame Relay multipoint network SHOULD result in a misconfiguration indication. The following Configurations Options are recommended: Magic Number Link Quality Monitoring Protocol Field Compression The standard LCP configuration defaults apply to Frame Relay links, except MRU. To ensure interoperability with existing Frame Relay implementations, the default Maximum-Receive-Unit (MRU) is 1600 octets [4]. The basic HDLC header is significantly shorter than the full-sized Frame Relay header, which may give additional leeway in buffer management. 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 early Frame Relay networks are only capable of 262 octet frames. In order to operate PPP over a Frame Relay link, the minimum PPP MRU of 1500 MUST be supported. To detect these inoperable links, the LCP Configure-Request packet MUST be padded to the full 1500 octet length. The padding MUST be a sequence of octets beginning with 1, and ending with the number of octets of padding. XID negotiation is not supported for PPP links. There is no need for Inverse ARP over PPP links. Simpson expires in six months [Page 4] DRAFT PPP in Frame Relay July 1993 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., "The Point-to-Point Protocol (PPP)", work in progress. [2] International Telegraph and Telephone Consultative Committee, CCITT Recommendation Q.922, "ISDN Data Link Layer Specification for Frame Mode Bearer Services", April 1991. [3] Simpson, W. A., "PPP HDLC Framing", work in progress. [4] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", RFC 1294, January 1992. [5] ISO/IEC TR 9577, "Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer", 1990 (E) 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. Simpson expires in six months [Page 5] DRAFT PPP in Frame Relay July 1993 Chair's Address The working group can be contacted via the current chair: Fred Baker Advanced Computer Communications 315 Bollay Drive Santa Barbara, California, 93111 EMail: fbaker@acc.com Author's Address Questions about this memo can also be directed to: William Allen Simpson Daydreamer Computer Systems Consulting Services P O Box 6205 East Lansing, MI 48826-6205 EMail: Bill.Simpson@um.cc.umich.edu Simpson expires in six months [Page 6] DRAFT PPP in Frame Relay July 1993 Table of Contents 1. Introduction .......................................... 1 2. The Data Link Layer ................................... 2 2.1 Frame Format .................................... 2 2.2 Modification of the Basic Frame ................. 2 3. In-Band Frame Format Detection ........................ 3 4. Out-of-Band signaling ................................. 4 5. Configuration Details ................................. 4 SECURITY CONSIDERATIONS ...................................... 5 REFERENCES ................................................... 5 ACKNOWLEDGEMENTS ............................................. 5 CHAIR'S ADDRESS .............................................. 6 AUTHOR'S ADDRESS ............................................. 6