Network Working Group W A Simpson Internet Draft Daydreamer expires in six months July 1993 PPP in X.25 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 X.25 for framing PPP encapsulated datagrams. Simpson expires in six months [Page i] DRAFT PPP in X.25 July 1993 1. Introduction CCITT recommendation X.25 [2] describes a network layer protocol providing error-free, sequenced, flow controlled, virtual circuits. X.25 includes a data link layer, X.25 LAPB, which uses ISO 3309, 4335 and 6256. The capabilities that are provided by X.25 are considered unnecessary and overly complex. PPP also uses ISO 3309 HDLC as a basis for its framing [3]. At one time, it had been hoped that PPP HDLC frames and X.25 frames would co-exist on the same links. Equipment could gradually be converted to PPP. Subsequently, it has been learned that some switches actually remove the X.25 header, transport packets to another switch using a different protocol such as Frame Relay, and reconstruct the X.25 header at the final hop. Co-existance and gradual migration are precluded. There are still ISO-lated pockets of existing X.25 links, and some interest in bringing the advantages of the PPP multiprotocol datagram service to this venue. When X.25 is configured as a point-to-point circuit, PPP can use X.25 as a framing mechanism, ignoring its other features. This is equivalent to the technique used to carry SNAP headers over X.25. Simpson expires in six months [Page 1] DRAFT PPP in X.25 July 1993 2. The Data Link Layer This specification uses the principles, terminology, and frame structure of the "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode" [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 Since both PPP and X.25 use ISO 3309 as a basis for framing, the full X.25 header is easily substituted for 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address | Control |D|Q| SVC# (hi) | SVC# (lo) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |p(r) |M|p(s) |0| 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 X.25 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 Simpson expires in six months [Page 2] DRAFT PPP in X.25 July 1993 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 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 link enters Link Establishment phase. Older implementations might contain the NLPID value CC hex, which is used for IP. Other ISO conformant implementations might contain other NLPID values, such as 80 hex (SNAP), or 81 hex (CLNP). Such values indicate that the link is not properly configured for PPP operation. 4. Out-of-Band signaling Support for Switched Virtual Circuit (SVC) call setup and clearing is not required. The first octet in the Call User Data (CUD) Field (the first data octet in the Call Request packet) is used for protocol demultiplexing, in accordance with the Subsequent Protocol Identifier Simpson expires in six months [Page 3] DRAFT PPP in X.25 July 1993 (SPI) in ISO/IEC TR 9577 [5]. This field contains a one octet Network Layer Protocol Identifier (NLPID), which identifies the network layer protocol encapsulated over the X.25 virtual circuit. The CUD field MAY contain more than one octet of information, and receivers MUST ignore all extraneous octets in the field. The PPP encapsulation MUST be indicated by a value of CF hex. Other values of the CUD are beyond the scope of this specification. 5. Configuration Details The accidental connection of a link to feed an X.25 multipoint network SHOULD result in a misconfiguration indication. The following Configuration Options are recommended: Magic Number Link Quality Monitoring Protocol Field Compression The standard LCP configuration defaults apply to X.25 links, except MRU. To ensure interoperability with existing X.25 implementations, the default Maximum-Receive-Unit (MRU) is 1600 octets [4]. The basic HDLC header is significantly shorter than the full-sized X.25 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. The X.25 packet size is not directly related to the MRU. Instead, Protocol Data Units (PDUs) are sent as X.25 "complete packet sequences". That is, PDUs begin on X.25 data packet boundaries and the M bit ("more data") is used to fragment PDUs that are larger than one X.25 data packet in length. Simpson expires in six months [Page 4] DRAFT PPP in X.25 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] CCITT Recommendation X.25, "Interface Between Data Terminal Equipment (DTE) and Data Circuit Terminating Equipment (DCE) for Terminals Operating in the Packet Mode on Public Data Networks", Vol. VIII, Fascicle VIII.2, Rec. X.25. [3] Simpson, W. A., "PPP HDLC Framing", work in progress. [4] Malis, A., Robinson, D., Ullman R., "Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode", RFC 1356, August 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 X.25 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 X.25 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 ................................. 3 5. Configuration Details ................................. 4 SECURITY CONSIDERATIONS ...................................... 5 REFERENCES ................................................... 5 ACKNOWLEDGEMENTS ............................................. 5 CHAIR'S ADDRESS .............................................. 6 AUTHOR'S ADDRESS ............................................. 6