PPP Extension Group Manu Kaycee, Paradyne INTERNET DRAFT George Gross, Lucent Technologies Expires September 25, 1997 Arthur Lin, Cisco Systems Andrew Malis, Cascade Communications John Stephens, Cayman Systems March 25, 1997 PPP over AAL5 and FUNI 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) and Frame User Network Interface (FUNI) for framing PPP encapsulated packets. Applicability This specification is intended for those implementations which desire to use facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and Kaycee, et. al. Expires September 25, 1997 [Page 1] Internet Draft PPP over AAL5 and FUNI March 13, 1997 compression. These capabilities require a point-to-point relationship between peers, and are not designed for multi-point relationships which are available in ATM and other multi-access environments. 1. Introduction AAL5 and FUNI are relative newcomers to the serial link community. Like Frame Relay, these protocols were designed to provide virtual circuits for connections between stations attached to the same ATM network. These mechanisms are restricted to delivery of packets, and dispense with sequencing and flow control, simplifying the service immensely. Most 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 or FUNI as a framing mechanism, ignoring its other features. This is equivalent to the technique used to carry SNAP headers over AAL5 [4]. 2. Physical Layer Requirements PPP treats the ATM network as a bit-synchronous point-to-point link. The link, more appropriately the virtual connections, MUST be full-duplex, but MAY be either dedicated (permanent) or switched. Interface Format PPP presents an octet interface to the physical layer. There is no provision for sub-octets to be supplied or accepted. Transmission Rate PPP does not impose any restrictions regarding transmission rate. Control Signals Implementation of ATM requires the provision of control signals, which indicate when the link has become connected or disconnected. These in turn provide the Up and Down events to the LCP state machine [1]. 3. The Data Link Layer This specification uses the principles, terminology, and frame structure described in "Multiprotocol Interconnect over AAL5" [4]. Kaycee, et. al. Expires September 25, 1997 [Page 2] Internet Draft PPP over AAL5 and FUNI March 13, 1997 The purpose of this specification is not to document what is already standardized in [4]. Instead, this document specifies how mechanisms described in [4] are to be used in order to map PPP onto an AAL5 and/or FUNI-based ATM network. 3.1. PPP over AAL5 The AAL5 format is as follows: AAL5 CPCS-PDU Format +-------------------------------+ | . | | . | | CPCS-PDU Payload | | up to 2^16 - 1 octets) | | . | | . | +-------------------------------+ | PAD ( 0 - 47 octets) | +-------------------------------+ ------- | CPCS-UU (1 octet ) | +-------------------------------+ | CPI (1 octet ) | +-------------------------------+CPCS-PDU Trailer | Length (2 octets) | +-------------------------------| | CRC (4 octets) | +-------------------------------+ ------- The 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 multiprotocol 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. Kaycee, et. al. Expires September 25, 1997 [Page 3] Internet Draft PPP over AAL5 and FUNI March 13, 1997 PPP over AAL5 SHALL use the VC-multiplexing mechanism described in [4]. A PPP frame SHALL constitute the CPCS-PDU payload and is defined as: +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ Each of these fields are specifically defined in [1]. 3.2. PPP over FUNI The FUNI frame format [2] is as follows: +-------------------------------+ | Flag | +-------------------------------+--------- | FUNI Header | ^ +-------------------------------+ | | | | | | | | User SDU | FUNI PDU | | | | | | +-------------------------------+ | | FUNI FCS (4 octets) | v +-------------------------------+--------- | Flag | +-------------------------------+ The FUNI Header includes a 10-bit Frame Address (a.k.a. VPI/VCI bits), a Congestion Notification bit, a Congestion Loss Priority bit, and four Reserved bits. The User SDU field contains user information up to 4096 (optionally up to 64K) octets. The FCS field protects the entire FUNI PDU except for the FCS field itself. PPP over FUNI SHALL use NULL-multiplexing. As such, a PPP frame SHALL constitute the User SDU field and is defined as: +----------+-------------+---------+ | Protocol | Information | Padding | | 8/16 bits| * | * | +----------+-------------+---------+ Each of these fields are specifically defined in [1]. Kaycee, et. al. Expires September 25, 1997 [Page 4] Internet Draft PPP over AAL5 and FUNI March 13, 1997 Though v2 of the FUNI specification is out for straw ballot in the ATM Forum, this document is based on the currently approved FUNI v1 specification. This document will be updated as when the FUNI V2 specification is approved. 3.3. Modification of the Basic Frame The Link Control Protocol can negotiate modifications to the basic frame structure. However, any such modified frames MUST always be clearly distinguishable from standard frames. 4. In-Band Protocol Demultiplexing Initial LCP packets contain the sequence cf-c0-21. In the case of AAL5, this sequence constitute the first three octets of an AAL5 frame. In the case of FUNI, they follow the FUNI Header. 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. 5. Out-of-Band signaling Conforming implementations MUST use VC multiplexing, as specified in RFC 1483, Section 5. A VC multiplexed PPP virtual connection is setup through control plane procedures, and by definition, the first bytes of the frame's payload field will always contain a PPP header followed by a packet. For switched virtual circuits, at call set up time, the ITU Q.2931 B-LLI element user information layer 3 protocol field is required to select ISO/IEC TR 9577 [5] in octet 7, and explicitly specify PPP (IPI value 0xCF) in the extension octets. Kaycee, et. al. Expires September 25, 1997 [Page 5] Internet Draft PPP over AAL5 and FUNI March 13, 1997 6. Configuration Details The following Configuration Options are recommended: Magic Number Protocol Field Compression 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 (and/or FUNI) 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 TR 9577:1990(E), "Information technology - Telecommunications and Information exchange between systems - Protocol Identification in the network layer", 1990-10-15. 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. Kaycee, et. al. Expires September 25, 1997 [Page 6] Internet Draft PPP over AAL5 and FUNI March 13, 1997 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 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, et. al. Expires September 25, 1997 [Page 7]