Network Working Group Nishit Vasavada INTERNET DRAFT Amber Networks, Inc. Jim Boyle Level 3 Communications, LLC. Chris Garner Qwest Communications Serge Maskalik iVMG, Inc. Vijay Gill Metromedia Fiber Network, Inc. February 2001 Frame Relay Service Type for L2TP 1. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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. 2. Abstract The Layer Two Tunneling Protocol (L2TP) [1] provides a standard method for tunneling PPP [2] packets. In accordance with the L2TP Service Type specification [3], this document provides a solution for transporting Frame Relay (FR) [4] over a session in an L2TP tunnel. 3. 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 RFC 2119 [5]. 4. Introduction The Layer Two Tunneling Protocol (L2TP) [1] provides a standard method for tunneling PPP [2] packets. The L2TP Service Type [3] Vasavada, et al. [Page 1] INTERNET DRAFT February 2001 allows layer 1 and layer 2 traffic to be tunneled through an L2TP tunnel. This document presents a solution to carry the ever popular Frame Relay circuit traffic over the IP network through the features offered by L2TP and the Service Type attribute. It talks about the use of [3] for setting up an L2TP tunnel and session containing FR traffic, and the signaling of some of the Frame Relay parameters. 5. FR Service Type A FR Service Type value of [TBD] MUST be used. The encoding of the Service Type AVP remains as specified in [3]. 6. Tunnel Establishment The basic tunnel establishment procedures defined in [1] and [3] are unchanged. The FR Service Type value [TBD] MUST be included in the Service Capabilities List AVP. 7. Session Establishment The basic call establishment procedures defined in [1] and [3] remain unchanged. The FR Service Type value [TBD] MUST be used in the Service Type AVP of an ICRQ or OCRQ. 7.1. Use of the Sub-Address AVP As specified in [1], the Sub-Address AVP, Attribute Type 23, is included in ICRQ or OCRQ and is used to encode additional dialing information. For the purpose of this specification, the Sub-Address AVP will be used to encode the source and destination DLCI numbers, and interface information. Additional non-addressing information is discussed in the following sections. The Sub-Address AVP is encoded 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|H| rsvd | Length | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 23 | Attribute Value... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [until Length is reached]... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The attribute value may be a simple ASCII string. For example, a source interface serial 1/1 and DLCI 100, and a destination interface serial 1/1 with DLCI 200 could be represented as "serial 1/1 DLCI 100, serial 1/1 DLCI 200". The format of the information contained Vasavada, et al. [Page 2] INTERNET DRAFT February 2001 in this AVP should be agreed on by the administrators at the two L2TP peers. When employing the Sub-Address AVP for this purpose, the AVP is mandatory (the M-bit MUST be set to 1). The AVP MAY be hidden (the H-bit set to 0 or 1). 7.2. FR Payload Message Format The L2TP payload header format defined in [1] remains unchanged while carrying data for a Frame Relay circuit. Entire Frame Relay PDU will be carried, subject to the following requirements: When transporting FR frames over an L2TP session the following rules MUST be followed: o All the Frame Relay packets will be preceded by a four byte code [TBD] in the L2TP payload packet. This code will allow L2TP to de-multiplex if additional functionality has to be added in future for signaling (please see the signaling and LMI sections). o The beginning and ending FR 'Flag' fields (one octet each) MUST be removed from the FR frame before it is encapsulated as L2TP payload. The destination LAC/LNS MUST insert new flags when reconstructing the FR frame for transmission to the FRAD. o The FCS field MUST be removed from the FR frame before it is carried in L2TP It MUST be recalculated at the other end. This does create a potential problem since L2TP does not offer checksum, and UDP checksum is optional. Work is needed in this area to guarantee integrity of the packet on the remote side. The encapsulated Frame Relay packet looks like this: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|L|x|x|S|x|O|P|x|x|x|x| Ver | Length (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel ID | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ns (opt) | Nr (opt) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset Size (opt) | Offset pad... (opt) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Four byte code [TBD] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FR Header +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FR Payload... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vasavada, et al. [Page 3] INTERNET DRAFT February 2001 As is true for the PPP traffic carried by L2TP, the frame size should consider the MTU and the additional headers to avoid IP fragmentation. 7.3. FR Local Management Interface (LMI) This draft does not discuss the LMI implications. Future work is necessary in this area. 8. Effects on Standard AVPs If FR frames are being tunneled in accordance with this document, then the following Call Management AVPs MAY be ignored: Bearer Type Framing Type Called Number Calling Number Initial Received LCP CONFREQ Last Sent LCP CONFREQ Last Received LCP CONFREQ Proxy Authen Type Proxy Authen Name Proxy Authen Challenge Proxy Authen ID Proxy Authen Response ACCM 9. Future work This section provides a list of things we need work on: o Signaling: The interface and DLCI information is conveyed through L2TP control packets. However, the frame parameters such as CIR, Be, and Bc related information is not covered. o LMI through the network o Data integrity (as mentioned in FR Payload Message Format section, currently there is no way to verify the data integrity due to lack of FR FCS, L2TP checksum, and optional UDP checksum. 10. Security Considerations All the underlying L2TP Security considerations remain, though no 'new' ones are introduced? 11. IANA Considerations To be completed. 12. Acknowledgments Many thanks to Danny McPherson, Chi Fai Ho and Himansu Sahu for their help in reviewing this draft. Vasavada, et al. [Page 4] INTERNET DRAFT February 2001 13. References [1] Townsley, et. al., "Layer Two Tunneling Protocol L2TP", RFC 2661, February 1999. [2] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [3] McPherson D., Nanji S., "L2TP Service Type", "Work in Progress", August 2000. [4] Frame Relay, ANSI T1.618 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 14. Authors' Addresses Nishit Vasavada Amber Networks, Inc. 48664 Milmont Drive Fremont, CA 94538 Phone: +1 510.683.8698 Email: nishit@ambernetworks.com Jim Boyle Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 Phone: +1 720.888.1192 Email: jboyle@level3.net Serge Maskalik iVMG, Inc. 1020 Rincon Circle San Jose, CA 95131 Phone: +1 408.468.0480 Email: serge@ivmg.net Chris Garner Qwest Communications 950 Seventeenth Street, 21 Floor Denver, CO 80202 Email: cgarner@qwest.net Vijay Gill Metromedia Fiber Network, Inc. 8075 Leesburg Pike Vienna, VA 22182 Phone: +1 410.262.0660 Email: vgill@mfnx.net Vasavada, et al. [Page 5]