PPP Extension Group Nagraj Arunkumar, 3Com INTERNET DRAFT Manu Kaycee, Paradyne Expires September 25, 1997 Tim Kwok, Microsoft Arthur Lin, Cisco Systems March 25, 1997 Layer Two Tunneling Protocol (L2TP) 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 Layer Two Tunneling Protocol describes a mechanism to tunnel PPP sessions. The protocol has been designed to be independent of the media it runs over. The base specification describes how it should be implemented to run over UDP and IP. This document describes how the Layer Two Tunneling Protocol MUST be implemented over ATM (AAL5 and FUNI). Applicability This specification is intended for those implementations which desire to use facilities which are defined for L2TP. These capabilities require a point-to-point relationship between peers, and are not Arunkumar, et. al. Expires September 25, 1997 [Page 1] Internet Draft L2TP over AAL5 and FUNI March 13, 1997 designed for multi-point relationships which are available in ATM and other multi-access environments. 1. Introduction L2TP is a protocol that makes a PPP session appear at a location other than the physical point at which it was received. The base protocol specification illustrates how L2TP may be used in IP environments. This document specifies how L2TP can be used in an ATM environment, over AAL5 and/or FUNI. The format of the AAL5 CPCS-PDU is given below: 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 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. The Length field indicates the length, in octets, of the Payload field. The maximum value for the Length field is 65535 octets. The CRC field protects the entire CPCS-PDU except the CRC field itself. Arunkumar, et. al. Expires September 25, 1997 [Page 2] Internet Draft L2TP over AAL5 and FUNI March 13, 1997 The FUNI frame format [4] is as follows: +-------------------------------+ | Flag | +-------------------------------+--------- | FUNI Header | ^ +-------------------------------+ | | | | | | | | User SDU | FUNI PDU | | | | | | +-------------------------------+ | | FUNI FCS (2 or 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. 2. Encapsulation and Packet Formats 2.1 Encapsulation over AAL5 To run L2TP over AAL5, L2TP packets will be sent as the payload of AAL5 PDUs. This is sometimes called "VC multiplexing" [2] or NULL encapsulation. It is assumed that the Virtual Connections used to transfer L2TP packets are point-to-point and bidirectional. The Virtual Circuits themselves may be Permanent Virtual Connections (PVCs) or Switched Virtual Connections (SVCs). Arunkumar, et. al. Expires September 25, 1997 [Page 3] Internet Draft L2TP over AAL5 and FUNI March 13, 1997 The actual encapsulation of the L2TP packets will be done via NULL encapsulation. i.e. the Virtual Connection will be used exclusively for L2TP packets. Format for L2TP PDUs +-------------------------------+ ------- | L2TP header | | (up to N octets, N < 19 ) | +-------------------------------+ | . | L2TP packet | L2TP Payload | | (up to 2^16 - N octets) | | . | +-------------------------------+ ------- | PAD ( 0 - 47 octets) | +-------------------------------+ ------- | CPCS-UU (1 octet ) | +-------------------------------+ | CPI (1 octet ) | +-------------------------------+ CPCS-PDU Trailer | Length (2 octets) | +-------------------------------| | CRC (4 octets) | +-------------------------------+ ------- When using L2TP over PVCs it is assumed that the end stations have been administratively configured to use the PVCs for L2TP. For SVCs, a new code point (to be determined) will used as part of SVC signalling to indicate that the VC will be used for L2TP with NULL encapsulation. All L2TP packets will contain the I and C bit to allow multiple tunnels per VC as well as multiple calls per tunnel. 2.2 Encapsulation over FUNI To run L2TP over FUNI, L2TP packets will be sent as the User SDU of FUNI PDUs. This is termed as NULL encapsulation and is similar to "VC multiplexing", as specified in [2]. Aside from syntactical framing differences between FUNI and AAL5, all attributes that apply to AAL5 (as discussed in Section 2.1.) also apply when running L2TP over FUNI. Arunkumar, et. al. Expires September 25, 1997 [Page 4] Internet Draft L2TP over AAL5 and FUNI March 13, 1997 The corresponding frame format is: +-------------------------------+ | Flag | +-------------------------------+--------- | FUNI Header | ^ +-------------------------------+ | | | | | | | | User SDU (PPP Frame) | FUNI PDU | | | | | | +-------------------------------+ | | FUNI FCS (2 or 4 octets) | v +-------------------------------+--------- | Flag | +-------------------------------+ PPP SHALL use VC multiplexing over FUNI. 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 [5]. 3. MTU Considerations L2TP requires that the tunnel support a minimum payload of 1500 octets, along with 18 octets of L2TP headers. To carry a MAC frame of 1518 bytes (such as Ethernet), with the PPP headers of up to 10 octets, and the L2TP header of up to 18 octets, L2TP implementations over AAL5/FUNI must support a minimum of 1546 octets. 4. Quality of Service Considerations To provide QoS an implementation MAY choose to open more than one Virtual Connection between a LAC and LNS. An implementation MAY also choose to open more than one Tunnel between a LAC and LNS. If a new tunnel is required, as dictated by some higher layer and policy, such a tunnel be set up and them mapped onto a new SVC, or existing PVC (or SVC). A tunnel is initially created over a VC. A subsequent call to the LAC may require that the LAC open a new VC to satisfy QoS requirements of that call. The additional VC is used purely for data and does not need a second tunnel control channel to be associated to that tunnel. Arunkumar, et. al. Expires September 25, 1997 [Page 5] Internet Draft L2TP over AAL5 and FUNI March 13, 1997 A LNS or LAC should be able to indicate the QoS parameters for a particular call. To do this a new AVP is proposed. %%% This AVP is to be included in the Call Setup messages? %%% %%% AVP for QoS parameters here %%% 5. Security Considerations Security may be administered using one or more of the following: - PAP/CHAP and PPP encryption - security attributes, if applicable and provided by the underlying ATM signalling subsystem - IP Security protocols between consenting end stations 7. References [1] Kory Hamzeh, Tim Kolar, et al., "Layer 2 Tunneling Protocol", Internet draft, December 1996. [2] Juha Heinanan, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993. [3] M. Laubach, "Classical IP over ATM", RFC 1577, January '94. [4] The ATM Forum, "Frame based User-to-Network Interface (FUNI) Specification v1", September 1995 [5] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 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 Arunkumar, et. al. Expires September 25, 1997 [Page 6] Internet Draft L2TP over AAL5 and FUNI March 13, 1997 Author's Address Questions about this memo can also be directed to: Nagaraj Arunkumar 3Com Corporation 5400 Bayfront Plaza Santa Clara, CA 95052 Tel: +1.408.764.5104 Email: nak@3com.com Manu Kaycee Paradyne Corporation 100 Shultz Drive Red Bank, NJ 07701 Tel: +1.908.345.7664 Email: mjk@nj.paradyne.com Tim Kwok One Microsoft Way Microsoft Corporation Redmond, WA 98052 Tel. +1.206.936.6755 Email: timkwok@microsoft.com Arthur Lin Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Tel: +1.408.526.8260 Email: alin@cisco.com Arunkumar, et. al. Expires September 25, 1997 [Page 7]