Internet-Draft Danny McPherson Ravi Bail Bhat Andy Koscinski Chi Fai Ho Amber Networks draft-mcpherson-l2tp-es-01.txt June 2000 L2TP Circuit Emulation Services Extension 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. Abstract The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism for tunneling PPP sessions. This document proposes mechanisms by which the L2TP tunneling scheme can be used to provide circuit emulation support for layer 2 circuits (i.e. Frame Relay or ATM), as well as TDM circuits (i.e. DS1 or DS3). L2TP is used to provide tunneling support and each circuit is encapsulated over a session inside the Tunnel. An Encapsulation Services Protocol [RefESP] is used on top of the individual L2TP sessions to support the circuit emulation of layer 2 VCs or TDM circuits. The purpose of this document is to explain the L2TP modifications done to facilitate support of circuit emulation services, as well as to define the additional AVPs that can be used to provide the service. Specification of Requirements 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 [RFC2119]. Table of Contents 1. Introduction 2. Topology Model 2.1. Modified L2TP Topology Model 3. Protocol Overview 4. Proposed Protocol Operation 4.1. Service Type AVP Format 4.2. Proposed Sub-Address in ICRQ 5. Quality of Service Considerations 6. Security Considerations 7. Intellectual Property Considerations 8. Acknowledgements 9. References 10. Authors' Addresses 1. Introduction The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a mechanism for tunneling PPP sessions. This document describes mechanisms by which L2TP tunneling scheme can be used to provide circuit emulation support for layer 2 circuits (i.e. Frame Relay or ATM), as well as TDM circuits (i.e. DS1 or DS3). L2TP is used to provide tunneling support and each circuit is encapsulated over a session inside the Tunnel. An Encapsulation Services Protocol [RefESP] is used on top of the individual L2TP sessions to support the circuit emulation of layer 2 Virtual Circuits or TDM circuits. The purpose of this document is to explain the L2TP modifications done to facilitate support of circuit emulation services, as well as to define the additional AVPs required to provide the service. 2. Topology Model The current L2TP model assumes a client/server architecture between the LAC and LNS. To support encapsulations services, a symmetric LAC-to-LAC model is proposed. In this model, a tunnel (with one or more sessions) can be established between two LACs. A tunnel is setup for a particular service or set of services (e.g. FR_GOLD) between a pair of LACs that support circuit emulation services. The Service Type is sent to the peer LAC via a newly defined vendor- specific AVP. Then for each connection within the service group (e.g. FR_GOLD), a session is initiated (possible from either side). The connection identifiers for the two legs of the connection (e.g. the Frame Relay interface and the Frame-Relay DLCI) are sent in the Sub-Address AVP. 2.1. Modified L2TP Topology Model (LAC/LAC) The following diagram depicts a typical L2TP LAC/LAC scenario. The goal is to tunnel lower-layer (layer 1 or layer 2) frames from the one LAC to the another LAC. FR-------+ +-------------+ +---- FR |---- | | ----| LAC1 ---| Internet |--- LAC2 |---- | | ----| TDM------+ +-------------+ +---- TDM | | LAC3 | | ---+ +--- | | | | FR TDM 3. Protocol Overview As shown in the figure below, the L2TP packet structure is modified to carry any protocol (Note: The current specification identifies support only for PPP frames). An encapsulation protocol with both data and control messages is carried over L2TP protocol. +---------------------------------------+ | L2TP Payload | | (Any Control/Data | | Message Any Protocol) | +---------------------------------------+ +-----------------------+ | L2TP Data Messages | | L2TP Control Messages | +---------------------------------------+ +-----------------------+ | L2TP Data Channel | | L2TP Control Channel | | (unreliable) | | (reliable) | +------------------------------------------------------------------+ | Packet Transport (UDP, FR, ATM, etc.) | +------------------------------------------------------------------+ The protcols running on top of L2TP will use the services of L2TP control protocol to open/close and manage L2TP tunnel and sessions. 4. Proposed Protocol Operation Encapsulation Services (ES) enable an IP network to support emulation of connection-oriented networks such as FR and ATM, as well as TDM circuit emulation. ES supports different Emulation Types and also supports multiple service profiles. The Emulation Type and the Service Type are represented by an optional AVP "Service Type". For Encapsulation Services, the AVP MUST be present in both SCCRQ and SCCRP messages and MUST match one another, otherwise the tunnel is dropped. At least one L2TP tunnel is opened for every Emulation Type between a pair of L2TP peers. Multiple tunnels may be opened for each Emulation Type if different Service Types are needed. Each circuit (e.g. DLCI in FR) is mapped into an L2TP session and carried transparently to the other end. During the session request, the endpoint connection identifiers are transported in the Sub-Address AVP. Once the L2TP session is established, the upper layer encapsulation protocol MAY exchange additional information to complete the circuit. Once the L2TP session is established, the upper layer encapsulation protocol MAY exchange additional information to complete the circuit emulation establishment. After that, the LACs start to transmit encapsulation potocol data between one another. 4.1. Service Type AVP Format The Service Type AVP MUST be present in SCCRQ and SCCRP message. If the tunnel is torn down due to unacceptable Service Type information (including no information) from the peer, the Service Type AVP MUST be present in the StopCCN as well. This AVP is used to inform the tunnel peer that a specific Service Type (e.g. FR_GOLD) is used. Vendor ID = 4741 Attribute Type = 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|0|0| Length | 4741 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 |Service Type (arbitrary length)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This AVP is encoded as a Vendor ID of 4741, which reflects Amber Networks, the initial developer of this specification. The Vendor ID SHOULD be changed to "0" and an official attribute value chosen, if this specification advances on the standard tracks. The Attribute Type is the 16 bit quantity "1". The L2TP peer is indicating that resources adequate for the Service Type identified by the AVP are required. In the event that the peer does not accept the requested Service Type, a StopCCN is returned to the originator. Such StopCCN message MUST include the Service Type AVP as provided in the message that caused the StopCCN. This AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 octets plus the length of the Service Type string. 4.2. Proposed Sub-Address in ICRQ The Sub-Address AVP, Attribute Type 23, encodes additional connection identifier information. The Attribute Value field for this AVP has the following format: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sub-Address ... (arbitrary number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Sub-Address is an opaque sequence of octets transmitted transparently by the network. The tunnel end points MUST, a priori, understand the meaning of the value for Encapsulation Services in this AVP. The general format of the information in this AVP is: 1. Calling party Sub-Address (iterations of: InfoType, Length, Connection Information, e.g. interface and DLCI for FR); 2. Called party Sub-Address (iterations of: InfoType, Length, Connection Information, e.g. interface and DLCI for FR); This AVP MAY be hidden (the H-bit may be 0 or 1). The M-bit for this AVP MUST be set to 1. The Length (before hiding) of this AVP is 6 octets plus the length of the Sub-Address. 5. Quality of Service Considerations Quality of Service (QoS) is a necessity for circuit emulation applications. The QoS mechanisms such as those proposed for L2TP in [L2TP-DS] and [L2TP-MPLS] should be considered. Additional discussion of this topic is beyond the scope of this document. 6. Security Considerations This document does not introduce security considerations beyond those listed in [RFC2661]. 7. Intellectual Property Considerations Amber Networks may seek patent or other intellectual property protection for some of all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Amber Networks, Amber intends to disclose those patents and license them on reasonable and non-discriminatory terms. 8. Acknowledgements The authors would like to acknowledge Nishit Vasavada for providing a considerable amount of valuable input to this document. 9. References [RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall, G. Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)", RFC 2661, August 1999. [RefESP] McPherson, D., et al., "Encapsulation Services Protocol (ESP)", "Work in Progress". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [L2TP-DS] Calhoun, P., Peirce, K., "Layer Two Tunneling Protocol "L2TP" IP Diferentiated Services Extension", "Work in Progress". [L2TP-MPLS] Calhoun, P., Peirce, K., "Layer Two Tunneling Protocol "L2TP" Multi-Protocol Label Switching Extension", "Work in Progress". 10. Authors' Addresses Danny McPherson Amber Networks 2465 Augustine Drive Santa Clara, CA 95054 Phone: +1 408.486.6336 Email: danny@ambernetworks.com Ravi Bail Bhat Amber Networks 2465 Augustine Drive Santa Clara, CA 95054 Phone: +1 408.845.5597 Email: rbhat@ambernetworks.com Andy Koscinski Amber Networks 2465 Augustine Drive Santa Clara, CA 95054 Phone: +1 408.845.5536 Email: andyk@ambernetworks.com Chi Fai Ho Amber Networks 2465 Augustine Drive Santa Clara, CA 95054 Phone: +1 408.845.5547 Email: ho@ambernetworks.com