Network Working Group W A Simpson Internet Draft Daydreamer expires in six months March 1993 PPP over Frame Relay Status of this Memo This memo is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments on this memo 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 of encapsulating Network Layer protocol information over point-to-point links. This document defines a method for using PPP to transport multi- protocol datagrams over Frame Relay circuits. Simpson expires in six months [Page i] DRAFT PPP over Frame Relay March 1993 1. Introduction PPP has three main components: 1. A method for encapsulating datagrams over serial links. 2. A Link Control Protocol (LCP) for establishing, configuring, and testing the data link connection. 3. A family of Network Control Protocols (NCPs) for establishing and configuring different network layer protocols. PPP was designed as a standard method of communicating over point- to-point links. Initial deployment has been over short local lines, leased lines, and plain-old-telephone-service (POTS) using modems. As new packet services and higher speed lines are introduced, PPP is easily deployed in these environments as well. One protocol to carry them all. One protocol to mind them. One protocol to link them all, and in the network bind them. Frame Relay is a relative newcomer to the serial link community. The protocol was designed as a virtual circuit network. There has been some interest in bringing the advantages of the PPP multi-protocol datagram service to this venue. When Frame Relay emulates a point- to-point circuit, PPP is well suited to use over Frame Relay. 2. Encapsulation PPP provides an encapsulation protocol over both bit-oriented synchronous links and asynchronous links with 8 bits of data and no parity. These links MUST be full-duplex, but MAY be either dedicated or circuit-switched. This fits the Frame Relay model. PPP uses HDLC [2] as a basis for the default encapsulation. Frame Relay is also in the family of HDLC derivatives, and the Frame Relay header may be easily substituted for the smaller HDLC header. Simpson expires in six months [Page 1] DRAFT PPP over Frame Relay March 1993 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 | Pad (0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PPP Protocol | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Unfortunately, the Frame Relay header is 3 octets in length. Therefore, a single octet of zero padding is used to align the header to a more convenient boundary. The use of this zero padding is conformant with both the ISO Network Layer Protocol Identifier (NLPID) Null Network layer, and the PPP protocol field extension mechanism. LCP negotiation MUST permit the Pad and Protocol fields to be compressed to a single octet. This will bring the header to the same size as the standard PPP HDLC header. 3. In-Band Protocol Detection When Out-of-Band signaling is not used to configure call setup for the circuit, or the Null encapsulation is indicated, the PPP Protocol field may be easily distinguished from other NLPID values. Initial LCP packets will contain the sequence 00-c0-21 following the header. Older implementations [3] might contain the NLPID value CC hex. Other ISO conformant implementations might contain other NLPID values, such as 80 hex (SNAP), or 81 hex (CLNP). Such packets indicate that the link is not properly configured for PPP operation, and MUST generate a Protocol-Reject. 4. Out-of-Band signaling There is no generally available method of out-of-band signalling. 5. Configuration Details The standard LCP configuration defaults apply to Frame Relay links. The following Configurations Options are recommended: Simpson expires in six months [Page 2] DRAFT PPP over Frame Relay March 1993 Magic Number Link Quality Monitoring Address and Control Field Compression Protocol Field Compression 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 3] DRAFT PPP over Frame Relay March 1993 Security Considerations Security issues are not discussed in this memo. References [1] Simpson, W. A., "The Point-to-Point Protocol", RFC 1331, May 1992. [2] International Organization For Standardization, ISO Standard 3309-1979, "Data communication - High-level data link control procedures - Frame structure", 1979. [3] Bradley, T., Brown, C., and Malis, A., "Multiprotocol Interconnect over Frame Relay", RFC 1294, January 1992. Acknowledgments Chair's Address The working group can be contacted via the current chair: Brian Lloyd B.P. Lloyd & Associates 3420 Sudbury Road Cameron Park, California 95682 Phone: (916) 676-1147 EMail: brian@lloyd.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 4] DRAFT PPP over Frame Relay March 1993 Table of Contents 1. Introduction .......................................... 1 2. Encapsulation ......................................... 1 3. In-Band Protocol Detection ............................ 2 4. Out-of-Band signaling ................................. 2 5. Configuration Details ................................. 2 SECURITY CONSIDERATIONS ...................................... 4 REFERENCES ................................................... 4 ACKNOWLEDGEMENTS ............................................. 4 CHAIR'S ADDRESS .............................................. 4 AUTHOR'S ADDRESS ............................................. 4 Bill.Simpson@um.cc.umich.edu