Internet Draft PPP Extensions Working Group Manu Kaycee, Paradyne INTERNET DRAFT George Gross, Lucent Technologies Expires January 25, 1998 Arthur Lin, Cisco Systems Andrew Malis, Cascade Communications John Stephens, Cayman Systems July 9, 1997 PPP Over AAL5 <draft-ietf-pppext-aal5-01.txt> Status Of This Memo 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 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this memo is unlimited. 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 ATM Adaptation Layer 5 (AAL5) for framing PPP encapsulated packets. Applicability Kaycee, Gross, et al Expires January 1997 [Page 1] Internet Draft PPP Over ATM AAL5 July 8th 1997 This specification is intended for those implementations which desire to use the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between the peers, and are not designed for multi-point relationships which are available in ATM and other multi-access environments. 1. Introduction ATM AAL5 protocol is designed to provide virtual circuit connections between end stations attached to the same network. These connections offer a best effort packet delivery service that includes error detection, but does not do error correction or flow control. These restrictions simplify the AAL5 service immensely. Most existing implementations of PPP use ISO 3309 HDLC as a basis for their framing [3]. When an ATM network is configured with point-to-point connections, PPP can use AAL5 as a framing mechanism, ignoring its other features. This is equivalent to the technique used to carry LLC/SNAP headers over AAL5 [4]. 2. AAL5 Adaptation Layer Service Interface The PPP layer treats the underlying ATM adaptation layer service as a bit-synchronous point-to-point link. In this context, the PPP link corresponds to an ATM AAL5 virtual circuit connection (VCC). The VCC MUST be full-duplex, point to point, and it MAY be either dedicated (i.e. permanent, set up by provisioning) or switched (set up on demand). In addition, the PPP/ATM AAL service interface boundary MUST meet the following requirements: Interface Format - The PPP/AAL layer boundary presents an octet service interface to the ATM AAL layer. There is no provision for sub-octets to be supplied or accepted. Transmission Rate - The PPP layer does not impose any restrictions regarding transmission rate. Control Signals - The ATM AAL layer must provide control signals to the PPP layer which indicate when the VCC link has become connected or disconnected. These provide the "Up" and "Down" events to the LCP state machine [1] within the PPP layer. 3. Multi-Protocol Encapsulation This specification uses the principles, terminology, and frame structure Kaycee, Gross, et al Expires January 1997 [Page 2] Internet Draft PPP Over ATM AAL5 July 8th 1997 described in "Multiprotocol Encapsulation over ATM Adaptation Layer 5" [4]. The purpose of this specification is not to document what is already standardized in [4], but to specify how the mechanisms described in [4] are to be used to map PPP onto an AAL5-based ATM network. Section 1 within [4] defines the two mechanisms for identifying the Protocol Data Unit (PDU) payload field's protocol type: virtual circuit based multiplexing, and Logical Link Control (LLC) encapsulation. In the former technique, the payload's protocol type is implicitly agreed to by the end points for each virtual circuit using provisioning or control plane procedures. When using the LLC encapsulation technique, the payload's protocol type is explicitly identified on a per PDU basis by an in-band LLC header, followed by the payload data. When transporting a PPP payload over AAL5, an implementation: 1. MUST support virtual circuit multiplexed PPP payloads as described in section 4. This technique is referred to as "VC- multiplexed PPP". 2. MAY use LLC encapsulated PPP payloads on PVCs as described in section 5 below by mutual configuration of both end points. This technique is referred to as "LLC encapsulated PPP". 3. If an implementation is connecting though a Frame Relay/ATM FRF.8 service inter-working unit to an RFC 1973 [6] end point, then it MUST support LLC encapsulated PPP payloads. 4. For SVC set up, an implementation MUST negotiate using the Q.2931 Annex C procedure, encoding the Broadband Lower Layer Interface (B-LLI) information element to signal either VC- multiplexed PPP or LLC encapsulated PPP. The details of this control plane procedure are described in section 6. 4. Virtual Circuit Multiplexed PPP Over AAL5 The AAL5 PDU format is shown in figure 1: AAL5 CPCS-PDU Format +-------------------------------+ | . | | . | | CPCS-PDU Payload | | up to 2^16 - 1 octets) | | . | Kaycee, Gross, et al Expires January 1997 [Page 3] Internet Draft PPP Over ATM AAL5 July 8th 1997 | . | +-------------------------------+ | PAD ( 0 - 47 octets) | +-------------------------------+ ------- | CPCS-UU (1 octet ) | +-------------------------------+ | CPI (1 octet ) | +-------------------------------+CPCS-PDU Trailer | Length (2 octets) | +-------------------------------| | CRC (4 octets) | +-------------------------------+ ------- Figure 1 The CPCS-PDU Payload field contains user information up to 2^16 - 1 octets. The PAD field pads the CPCS-PDU to fit exactly into the ATM cells such that the last 48 octet cell payload created by the SAR sublayer will have the CPCS-PDU Trailer right justified in the cell. The CPCS-UU (User-to-User indication) field is used to transparently transfer CPCS user to user information. The field has no function under the multi-protocol ATM encapsulation described in this memo and can be set to any value. The CPI (Common Part Indicator) field aligns the CPCS-PDU trailer to 64 bits. Possible additional functions are for further study in ITU-T. When only the 64 bit alignment function is used, this field shall be coded as 0x00. The Length field indicates the length, in octets, of the Payload field. The maximum value for the Length field is 65535 octets. A Length field coded as 0x00 is used for the abort function. The CRC field protects the entire CPCS-PDU except the CRC field itself. A VC-multiplexed PPP frame SHALL constitute the CPCS-PDU payload and is defined as: +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ Figure 2 Each of these fields are specifically defined in [1]. Kaycee, Gross, et al Expires January 1997 [Page 4] Internet Draft PPP Over ATM AAL5 July 8th 1997 5. LLC Encapsulated PPP Over AAL5 LLC encapsulated PPP over AAL5 is the alternative technique to VC- multiplexed PPP over AAL5. LLC encapsulated PPP minimizes the ATM/Frame Relay inter-working translation complexity that occurs when a VCC is connected to an RFC 1973 compliant end point. The AAL5 CPCS-PDU payload field is encoded as shown in figure 3: +-------------------------+ -------- | Source SAP (0xFE) | ^ +-------------------------+ | | Destination SAP (0xFE) | LLC header +-------------------------+ | | Frame Type = UI (0x03) | V +-------------------------+ -------- | NLPID = PPP (0xCF) | +-------------------------+ -------- | Protocol Identifier | ^ | (8 or 16 bits) | | +-------------------------+ PPP payload | . | | | . | | | PPP information field | | | . | | | . | V +-------------------------+ -------- Figure 3 The fields in the above diagram are: 1. LLC header: 2 bytes encoded to specify a source SAP and destination SAP of non-OSI routed PDU (values 0xFE 0xFE), followed by an Un-numbered Information (UI) frame type (value 0x03). 2. Network Layer Protocol IDentifier (NLPID) representing PPP, (value 0xCF). 3. the PPP protocol identifier field, which can be either 1 or 2 octets long. 4. followed by the PPP information field. 6. Out-Of-Band Control Plane Signaling When originating a switched virtual circuit AAL5 connection, the caller MUST request in the SETUP message either one or else both of the RFC1483 Kaycee, Gross, et al Expires January 1997 [Page 5] Internet Draft PPP Over ATM AAL5 July 8th 1997 protocol encapsulation techniques for PPP payload transport. When a caller is offering both techniques, the two BLLI IEs are encoded within a Broadband Repeat Indicator IE in the order of their preferance. The called implementation MUST be able to an accept incoming call that offers VC-multiplexed PPP in the caller's request. The called implementation MAY reject a call set up request that only offers LLC encapsulated PPP. Implementations originating a call offering both protocol encapsulation techniques MUST be able to negotiate to the fall back position of VC-multiplexed PPP and still inter-operate. When originating a virtual circuit multiplexed call that is to carry a PPP payload, the ITU Q.2931 B-LLI element user information layer 3 protocol field is encoded to select ISO/IEC TR 9577 [5] in octet 7. The extension octets specify an IPI value of PPP (0xCF). By definition, the first bytes of the AAL5 frame's payload field will always contain a PPP header followed by a packet. When originating an LLC encapsulated call that is to carry a PPP payload, the ITU Q.2931 B-LLI element user information layer 2 protocol field is encoded to select LAN Logical Link Control (ISO/IEC8802-2) in octet 6. See RFC1755, appendix A. By definition, the first bytes of the AAL5 frame's payload field will contain an LLC header, followed by a NLPID and the PPP payload. 7. PPP Link Control Protocol Phase Transitions Initial LCP packets contain the sequence cf-c0-21. In the case of VC- multiplexed PPP, this sequence constitute the first three octets of an AAL5 frame. When a LCP Configure-Request packet is received and recognized, the PPP link enters Link Establishment phase. Configuration requests received over multi-point connections SHOULD result in (a) misconfiguration indication(s). This can be detected by multiple responses to the LCP Configure-Request with the same Identifier, coming from different framing addresses. Some implementations might be physically unable to either log or report such information. Once PPP has entered the Network-layer Protocol phase, and successfully negotiated a particular NCP for a PPP Protocol, if a frame arrives using an alternate but equivalent data encapsulation defined in [4], the PPP Link MUST re-enter Link Establishment phase and send a new LCP 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. Kaycee, Gross, et al Expires January 1997 [Page 6] Internet Draft PPP Over ATM AAL5 July 8th 1997 8. Configuration Options The following Configuration Options are recommended: Magic Number Protocol Field Compression 9. Security Considerations Generally, ATM networks are virtual circuit based, and security is implicit in the public data networking service provider's administration of Permanent Virtual Circuits (PVCs) between the network boundaries. The probability of a security breach caused by mis-routed ATM cells is considered to be negligible. When a public ATM network supports Switched Virtual Circuits, the protocol model becomes analogous to traditional voice band modem dial up over the Public Telephone Switched Network (PTSN). The same PAP/CHAP authentication protocols that are already widely in use for Internet dial up access are leveraged. As a consequence, PPP over AAL5 security is at parity with those practices already established by the existing Internet infrastructure. Those applications that require stronger security are encouraged to use authentication headers or encrypted payloads. References [1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [2] The ATM Forum, "Frame based User-to-Network Interface (FUNI) Specification v1", September 1995 [3] Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC 1662, July 1994. [4] Hienanan, J., "Multiprotocol Interconnect over AAL5 ", RFC 1483, July 1993. [5] ISO/IEC DTR 9577.2, "Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer", 1995-08-16. Kaycee, Gross, et al Expires January 1997 [Page 7] Internet Draft PPP Over ATM AAL5 July 8th 1997 [6] Simpson, W., "PPP in Frame Relay", RFC 1973, June 1996. 10. Acknowledgments This design is based on work performed in ADSL Forum's Packet Mode Working Group. It is inspired by "PPP in Frame Relay", RFC 1973, by William Simpson, which we have used gratuitously. Chair's Address The working group can be contacted via the current chair: Karl Fox Ascend Communications 3518 Riverside Drive, Suite 101 Columbus, Ohio 43221 EMail: karl@ascend.com Author's Address Questions about this memo can also be directed to: Manu Kaycee Paradyne Corporation 100 Shultz Drive Red Bank, NJ 07701 Tel: +1.908.345.7664 Email: mjk@nj.paradyne.com George Gross Lucent Technologies, Inc 184 Liberty Corner Road Warren, NJ 07059 Tel: +1.908.580.4589 Email: gmg@garage.lucent.com Arthur Lin Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Tel: +1.408.526.8260 Email: alin@cisco.com Andrew Malis Cascade Communications Corporation 5 Carlisle Road Westford, MA 01886 Kaycee, Gross, et al Expires January 1997 [Page 8] Internet Draft PPP Over ATM AAL5 July 8th 1997 Tel: +1.508.952.7414 Email: malis@casc.com John Stephens Cayman Systems, Inc. 100 Maple Street Stoneham, MA 02180 Tel: +1.617.279.1101 Email: john@cayman.com Kaycee, Gross, et al Expires January 1997 [Page 9]