Point-to-Point Protocol Extensions Working Group J. Sadler Internet Draft K. Mooney Document: draft-sadler-pppext-lapd-00.txt Tellabs Category: Standards Track Expiration Date: May 2001 November 2001 PPP over LAP-D draft-sadler-pppext-lapd-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. This document describes the method to use for transporting PPP packets in LAP-D. 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. Sadler PPPEXT WG - August 2001 1 draft-sadler-pppext-lapd-00.txt August 2001 3. Motivation Work has been progressing in the Multi-protocol Label Switching (MPLS) working group on the application of MPLS technology to non- packet switching networks. Specifically, development of the Generalized MPLS (GMPLS) signaling draft [1] has allowed for Optical, SONET/SDH, and spatial switching to be controlled using IP protocols. Three scenarios have been offered [2] for carrying signaling messages between GMPLS enabled devices. They are as follows: o In-band: signaling messages are carried over a control-channel embedded in the transport link between peering GMPLS LSRs. o Out-of-band, in-fiber: signaling messages are carried over a control-channel embedded in the physical link but outside the transport link of the peering GMPLS LSRs. o Out-of-band, out-of-fiber: signaling messages are carried over a separate control network that is not embedded in the physical link. In the case of In-band signaling over SONET/SDH transport, two control-channels exist: the Line Data Communication Channel (LDCC) and the Section Data Communication Channel (SDCC). These channels have previously been standardized by [3] and [4] to use LAP-D as the data link, and to use the methods defined in ISO 9577 for identifying the Network Layer Protocols operating over the link. However, unlike PPP, LAP-D does not allow for negotiation of Link or Network parameters. This can lead to operational issues caused by inconsistent configuration of the two end points of the data link. Further, because the Maximum Transmission Unit size for LAP-D over the SONET DCC has been standardized as a "minimum of 512-bytes" neighboring systems that can support MTU sizes of larger than 512 bytes are unable to use the larger frame sizes because they donĘt know the supported size of the other endpoint. Consequently, it is valuable to be able to operate PPP [5] over LAP-D. Previously, the PPP working group defined how to operate PPP over LAP-B [6]. While this approach could be used as the basis for operating PPP over LAP-D, it is not consistent with the use of ISO 9577 as required by [3] and [4]. Since ISO 9577 is also used when operating over Frame Relay data links, this document is based on the methodology defined in RFC 1973 [7]. Sadler PPPEXT WG - August 2001 2 draft-sadler-pppext-lapd-00.txt August 2001 4. Lower Layer Requirements LAP-D [8] is a framed bit-synchronous link layer based on HDLC [9]. Since no additional framing or bit/byte-stuffing is necessary when encapsulating PPP in LAP-D frames, PPP will present an octet- oriented interface to LAP-D. The LAP-D data link MUST be full-duplex, and MUST provide an Unacknowledged Information Transport Service. The LAP-D data link MAY be operating over a point-to-point physical link or a point-to-multipoint physical link. The LAP-D Service user is insulated from this detail as the delivered service appears as a point-to-point link. As a result, LCP Link events are traceable to the status of the supporting LAP-D connection. 5. Data Link Layer 5.1 Basic Frame Format The LAP-D header defined in Q.921 [8] consists of a flag followed by an address and a control field. The address field is subdivided into the Subnetwork Attachment Point Identifier (SAPI) and the Terminal Endpoint Identifier (TEI). The TEI is used to identify a specific device located on a point-to-multipoint connection. Originally developed for addressing devices on a multidrop bus at the ISDN S/T reference point, this is not used when LAP-D is used in a point-to-point connection. The SAPI is used to identify a specific application on that device. SAPIs exist for ISDN call control (00), X.25 (16), and SONET management (62). As specified in ISO 9577 [10], the client of the Data Link Layer is identified by the Initial Protocol Identifier (IPI) which is located in the first byte of the Data Link Layer payload. This field is identical to the NLPID field used in Frame Relay. The IPI/NLPID for PPP is 0xCF. The resulting PPP in LAP-D PDU is as follows: 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SAPI |C|0| TEI |1| Control | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPI (0xcf) | PPP Protocol | Data . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sadler PPPEXT WG - August 2001 3 draft-sadler-pppext-lapd-00.txt August 2001 The fields are defined as follows: SAPI Subnetwork Attachment Point Identifier C Command/Response Field TEI Terminal Endpoint Identifier Control Control word IPI Initial Protocol Identifier Protocol PPP Protocol field LAP-D is a connection oriented protocol, with information frames (Control = I or Control = UI) only being transmitted after a LAP-D connection has been established with the remote endpoint. Once the connection is established, LAP-D allows for two modes of service: Acknowledged Information Transport Service (AITS) and Unacknowledged Information Transport Service (UITS). When the LAP-D connection is successfully established, PPP MUST be given a Link-Up event to start LCP negotiation. While PPP is designed to operate over unreliable connections, LAP-D UITS mode is optional according to Q.921. As a result, PPP MUST negotiate LCP options utilizing AITS mode. A new LCP option is used to identify the mode of service to be used on the connection after completing the LCP phase. The resulting LCP option looks like: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LCPOpt (0xXX) | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length field is 2. Presence of this option signifies that the system is capable of supporting UITS mode. If both endpoints are capable of UITS, then the link MUST start using UITS to carry PPP packets once LCP negotiation is complete. The LAP-D connection MAY allow for other LAP-D service users (identified by different IPI values) to utilize the same LAP-D connection. Their use of UITS or AITS service is independent of whether PPP is using UITS or AITS mode. 5.2 Modification of the Basic Frame The Link Control Protocol can negotiate modifications to the basic frame structure. However, modified frames will need to be clearly distinguishable from standard frames. Address-and-Control-Field-Compression Because the Address and Control field values will not be the same from one LAP-D frame to the next, Address-and-Control-Field- Compression MUST NOT be negotiated. Sadler PPPEXT WG - August 2001 4 draft-sadler-pppext-lapd-00.txt August 2001 6. In-Band Protocol Demultiplexing The PPP IPI (CF hex) easily distinguishes the PPP encapsulation from the other encapsulations allowed in [10]. 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 [10] SHOULD be used. On reception, the PPP Protocol field is examined. If this field is zero, it MUST be assumed that the packet is mis-formatted and the packet is to be discarded. 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. Packets with other IPI values MAY be sent and received at the same time as PPP. Processing of these packets MAY continue as long as the corresponding PPP NCP for the protocol has not been successfully established. 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 [10], the PPP Link MUST reset the state of the NCP and send a new NCP 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 other methods defined in [10]. 7. Configuration Details The following Configuration Options are recommended: Magic Number The standard LCP configuration defaults apply to LAP-D links, except Maximum-Receive-Unit (MRU). To ensure interoperability with existing LAP-D 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. Sadler PPPEXT WG - August 2001 5 draft-sadler-pppext-lapd-00.txt August 2001 The typical network feeding the link is likely to have a MRU of 1500, 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 LAP-D implementations are only capable of 262 octet frames. It is not recommended that anyone deploy or use a LAP-D 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 IPI and Protocol fields), until LCP negotiation is complete. Because the Address and Control fields are important to the proper operation of LAP-D, Address and Control Field Compression (ACFC) must not be negotiated. 8. Security Considerations This draft introduces no new security considerations. 9. References 1 P. Ashwood-Smith, et al., "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized- signaling-06.txt, Work in progress. October 2001. 2 D.Papadimitriou, et al., "Optical Network-to-Network Interface, Framework and Signaling Requirements", Internet Draft, draft- papadimitriou-onni-frame-01.txt, Work in progress, November 2000. 3 American National Standards Institute, "Synchronous Optical Network (SONET) ū Data Communication Channel Protocol and Architectures", ANSI T1.105.04-1995 4 ITU-T Recommendation G.784, "Synchronous digital hierarchy (SDH) management ", ITU Geneva 1999. 5 Simpson, W., "The Point-to-Point Protocol", RFC 1661, July 1994. 6 Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994. 7 Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996. 8 ITU-T Recommendation Q.921, "ISDN user-network interface - Data link layer specification", ITU Geneva 1997. 9 ISO 3309, "Information technology -- Telecommunications and information exchange between systems -- High-level data link control (HDLC) procedures -- Frame structure", International Standards Organization 1993. Sadler PPPEXT WG - August 2001 6 draft-sadler-pppext-lapd-00.txt August 2001 10 ISO 9577, "Information technology -- Protocol identification in the network layer", International Standards Organization 1999. 10. Acknowledgments The Authors would like to acknowledge Ben Mack-Crane for his assistance in developing this document. 11. Author's Addresses Jonathan Sadler Tellabs Operations, Inc. 27555 Diehl Rd Warrenville, IL 60555 Phone: +1 630-848-7741 Email: Jonathan.Sadler@tellabs.com Kevin Mooney Tellabs Operations, Inc. 4951 Indiana Avenue Lisle, IL 60532 Phone: +1 630-512-7269 Email: Kevin.Mooney@tellabs.com Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into Sadler PPPEXT WG - August 2001 7