Network Working Group W. Mark Townsley Internet-Draft George Wilkie Category: Standards Track Skip Booth <draft-ietf-l2tpext-pwe3-fr-02.txt> Jed Lau June 2003 Stewart Bryant cisco Systems Nishit Vasavada Nokia Serge Maskalik iVMG, Inc. Frame-Relay Pseudo-Wire Extensions for L2TP Status of this Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html The distribution of this memo is unlimited. It is filed as <draft- ietf-l2tpext-pwe3-fr-02.txt> and expires December 2003. Please send comments to the L2TP mailing list (l2tpext@ietf.org). Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract The Layer 2 Tunneling Protocol [L2TPv3] defines an extensible tunneling protocol suitable for Pseudowire Emulation Edge to Edge (PWE3) applications. This document describes the specifics of how to use the L2TP control plane for Frame-Relay Pseudo-Wires, including Townsley, et al. Standards Track [Page 1]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 PVC creation, deletion, and line status change notification. Townsley, et al. Standards Track [Page 2]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 3 1.1 Abbreviations......................................... 3 2. PE-PE Control Connection Establishment.................... 4 3. PVC Status Notification and Session Establishment......... 4 3.1 PE-PE Session Establishment........................... 4 3.2 PE-PE Session Teardown................................ 6 3.3 PE-PE Session Maintenance............................. 6 3.4 Use of the Circuit Status AVP for Frame-Relay......... 6 4. Encapsulation............................................. 7 4.1 Data Packet Encapsulation............................. 7 4.2 Data Packet Sequencing................................ 8 5. Security Considerations................................... 8 6. IANA Considerations....................................... 8 7. Acknowledgments........................................... 8 8. References................................................ 9 9. Contacts.................................................. 10 1. Introduction This document describes the specifics of how to use the L2TP for Frame-Relay Pseudo-Wires, including encapsulation, PVC creation, deletion, and line status change notification. Any Frame-Relay- specific AVPs or other L2TP constructs for Frame-Relay Pseudo-Wire (FRPW) support will be defined here as well. Support for Switched Virtual Circuits (SVC) and Switched/soft Permanent Virtual Circuits (SPVC) are for further study. 1.1 Abbreviations CE Customer Edge FR Frame-Relay FRPW Frame-Relay Pseudo-Wire LCCE L2TP Control Connection Endpoint (See [L2TPv3]) PE Provider Edge (typically also the LCCE). PSN Packet Switched Network PVC Permanent virtual circuit Townsley, et al. Standards Track [Page 3]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 PW Pseudo-Wire PWE3 Pseudo-Wire Emulation Edge to Edge (Working Group) VC Virtual circuit 2. PE-PE Control Connection Establishment Two PEs that wish to establish Pseudo-Wires with L2TP must first establish an L2TP Control Connection as described in Section 3.3 of [L2TPv3]. The SCCRQ and corresponding SCCRP MUST include the Frame- Relay PW Type of TBD (See IANA Considerations Section), in the Pseudo Wire Capabilities List as defined in 5.4.3 of [L2TPv3]. This identifies the control connection as able to establish L2TP sessions to support Frame-Relay Pseudo-Wires (FRPWs). 3. PVC Status Notification and Session Establishment This section specifies how the status of a PVC is reported between two PEs. This includes what should happen when a PVC is created, deleted or when it changes state between ACTIVE and INACTIVE. 3.1 PE-PE Session Establishment PVC creation (provisioning) results in establishment of an L2TP session via the standard three-way handshake described in section 3.4.1 of [L2TPv3]. An LCCE MAY initiate the session immediately upon PVC creation, or wait until the PVC state transitions to ACTIVE before attempting to establish a session for the PVC. Waiting until the PVC transitions to ACTIVE is the preferred method of operation, as it does not needlessly waste L2TP resources. The Circuit Status AVP (see Section 4) MUST be present in the ICRQ and ICRP messages, and MAY be present in the SLI message for FRPWs. Following is an example of the L2TP messages exchanged for an FRPW which is initiated after a new PVC is provisioned and becomes ACTIVE. Townsley, et al. Standards Track [Page 4]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 PE (LAC) A PE (LAC) B ------------------ ------------------ FR PVC Provisioned FR PVC Provisioned FR PVC ACTIVE ICRQ (status = 0x03) ----> FR PVC ACTIVE <---- ICRP (status = 0x03) L2TP session established, OK to send data into tunnel ICCN -----> L2TP session established, OK to send data into tunnel In the example above, an ICRQ is sent after the PVC is created and becomes ACTIVE. The Circuit Status AVP indicates that this PVC is ACTIVE and New (0x03). The Remote End Identifier AVP must be present in the ICRQ in order to identify the PVC to attach the L2TP session to. The Remote End Identifier AVP defined in [L2TPv3] is of opaque form, though FRPW implementions MAY simply use a four-octet value that is known to both PEs (either by direct configuration, or some other means). The exact method of how this value is configured, retrieved, discovered, or otherwise determined at each PE is outside the scope of this document. As with the ICRQ, the ICRP is sent only after the FR PVC transitions to ACTIVE as well. If PE B had not been provisioned for the PVC identified in the ICRQ, a CDN would have been immediately returned indicating that the circuit was not provisioned or available at this PE. PE A should then exhibit a periodic retry mechanism. Specifics of the retry algorithm is left to the implementation, but SHOULD be configurable. An Implementation MAY send an ICRQ or ICRP before a PVC is ACTIVE, as long as the Circuit Status AVP reflects that the PVC is INACTIVE and an SLI is sent when the PVC becomes ACTIVE (see Section 3.3). The ICCN is the final stage in the session establishment, confirming the receipt of the ICRP with acceptable parameters to allow bidirectional traffic. Townsley, et al. Standards Track [Page 5]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 3.2 PE-PE Session Teardown In the event a PVC is deleted (unprovisioned) at either PE, the associated L2TP session MUST be torn down via the CDN message defined in Section 3.4.3 of [L2TPv3]. General Result Codes regarding L2TP session establishment are defined in [L2TPv3]. Additional Frame-Relay result codes are defined as follows (TBD indicates that both of these values needs to be assigned by IANA): TBD: PVC was deleted permanently (no longer provisioned) TBD: PVC has been INACTIVE for an extended period of time 3.3 PE-PE Session Maintenance FRPW over L2TP makes use of the Set Link Info (SLI) control message defined in [L2TPv3] to signal Frame-Relay link status notifications between PEs. This includes ACTIVE or INACTIVE notifications of the VC, or any other parameters that may need to be shared between the tunnel endpoints or PEs in order to provide proper PW emulation. The SLI message is a single message that is sent over the L2TP control channel signaling the state change. Since the message is delivered reliably, there is no additional response or action required of the PW subsytem to ensure that the state change notification was received by the tunnel peer. The SLI message MUST be sent any time there is a line status change which may be reported by any values identified in the Circuit Status AVP. The only exception to this is the initial ICRQ, ICRP and CDN messages which establish and teardown the L2TP session itself when the PVC is created or deleted. The SLI message may be sent from either PE at any time after the first ICRQ is sent (and perhaps before an ICRP is received, requiring the peer to perform a reverse Session ID lookup). All sessions established by a given control connection utilize the L2TP Hello factility defined in Section 4.4 of [L2TPv3] for session keepalive. This gives all sessions basic dead peer and path detection between PEs. 3.4 Use of the Circuit Status AVP for Frame-Relay Frame-relay line status is reported via the Circuit Status AVP defined in [L2TPv3]. For reference, this AVP is shown below: Townsley, et al. Standards Track [Page 6]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved |A|N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Value is a 16 bit mask with the two least significant bits defined and the remaining bits reserved for future use. Reserved bits MUST be set to 0 when sending, and ignored upon receipt. The A (Active) bit indicates whether the FR PVC is ACTIVE (1) or INACTIVE (0). The N (New) bit indicates whether the circuit status indication is for a new FR PVC (1) or an existing FR PVC (0). 4. Encapsulation 4.1 Data Packet Encapsulation The FR PDU is transported in its entirety, excluding only the opening and closing HDLC flags and the FCS. Bit stuffing is undone. No intermediate headers are required between the L2TP header and the start of the FR PDU. The start of the FR PDU is therefore contiguous with the end of the L2TP header. This approach conforms to the Principle of Minimum Intervention [LAYER], and concurs with [MARTINI]. The NSP function [LAYER] in some PW PEs may need to modify the FR header. The FR header is defined in [Q922], however the notation used differs from that used in IETF specifications. For reference the FR header in IETF notation is: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C|0|lo dlci|F|B|D|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Two-octet FR Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C|0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Townsley, et al. Standards Track [Page 7]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 Four-octet FR Header C/R (bit 6) FR frame C/R (command/response) bit [Q922]. F - FECN (bit 12): FR FECN (Forward Explicit Congestion Notification) bit [Q922]. B - BECN (bit 13): FR BECN (Backward Explicit Congestion Notification) bit [Q922]. D - DE (bit 14) FR DE bit indicates the discard eligibility [Q922]. 4.2 Data Packet Sequencing Data Packet Sequencing MAY be enabled for FRPWs. The sequencing mechanisms described in [L2TPv3] MUST be used for signaling sequencing support. FRPW over L2TP MUST request the presence of the L2TPv3 Default L2-Specific Sublayer when sequencing is enabled, and MAY request its presence at all times. 5. Security Considerations For generic security issues regarding PWs and FRPWs, this document will eventually refer to documents from the PWE3 WG. 6. IANA Considerations The signaling mechanisms defined in this document rely upon the assignment of a Frame Relay Pseudowire Type. IANA assignment of this value should take place within the PWE3 WG. This document specifies one additional AVP Attribute to be defined by IANA as described in section 9.1 of [L2TP-IANA]. This document defines two L2TP Result Codes in section 3.2 which will be defined by IANA as described in section 9.1 of [L2TP-IANA]. 7. Acknowledgments The first Frame Relay over L2TP document was published as "Frame Relay Service Type for L2TP," draft-vasavada-l2tpext-fr-svctype- 00.txt in Feburary of 2001 by Nishit Vasavada, Jim Boyle, Chris Garner, Serge Maskalik, and Vijay Gill. This document is substantially different, but the basic concept of carrying Frame Relay over L2TP is the same. Townsley, et al. Standards Track [Page 8]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 Thanks to Lloyd Wood for a razor-sharp review. 8. References [L2TPv3] J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Pall, A. Rubens, B. Palter, Layer Two Tunneling Protocol a.k.a. "L2TPv3," work in progress, draft-ietf-l2tpext-l2tp-base-02.txt, February 2002. [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification for Frame Mode Bearer Services, Geneva, October 1995. [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2000. [FRF2] FRF.2.1, Frame relay PVC NNI Implementation Agreement, Frame Relay Forum, July 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2661] Townsley, Valencia, Rubens, Pall, Zorn, Palter, "Layer Two Tunneling Protocol 'L2TP'", RFC 2661, June 1999. [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3193] B. Patel, B. Aboba, W. Dixon, G. Zorn, S. Booth, "Securing L2TP Using IPsec," RFC 3193, November 2001 [L2TP-IANA] Townsley, W., "L2TP IANA Considerations Update", Internet Draft, draft-ietf-l2tpext-rfc2661-iana-00.txt, April 2002 [LAYER] Bryant, et al. Protocol Layering in PWE3, draft-pwe3-protocol-layer-00.txt, May 2002, work in progress. [MARTINI] Martini, et al. Frame Relay Encapsulation over Pseudo-Wires, draft-martini-frame-encap-mpls-01.txt, June 2002, work in progress. Townsley, et al. Standards Track [Page 9]
INTERNET DRAFT L2TP PWE3 Frame Relay June 2003 9. Contacts W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 mark@townsley.net George Wilkie cisco Systems Edinburgh, EH6 6LX United Kingdom gwilkie@cisco.com Jed Lau cisco Systems 170 W. Tasman Drive San Jose, CA 95134 jedlau@cisco.com Skip Booth cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 ebooth@cisco.com Stewart Bryant cisco Systems Uxbridge UB11 1BL United Kingdom stbryant@cisco.com Nishit Vasavada Nokia 545 Whisman Dr Mountain View, CA 94043 nishit.vasavada@nokia.com Serge Maskalik iVMG, Inc. 1020 Rincon Circle San Jose, CA 95131 serge@ivmg.net Townsley, et al. Standards Track [Page 10]
