Network Working Group W. Mark Townsley Internet-Draft George Wilkie Category: Standards Track Skip Booth <draft-ietf-l2tpext-pwe3-fr-00.txt> Jed Lau February 2002 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-00.txt> and expires August 2002. 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 [L2TP] 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 PVC creation, deletion, and line status change notification. Townsley, et al. Standards Track [Page 1]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 1.1 Abbreviations......................................... 2 2. PE-PE Control Connection Establishment.................... 3 3. Frame-Relay PVC Status Notification....................... 3 3.1 PE-PE Session Establishment........................... 3 3.2 PE-PE Session Teardown................................ 5 3.3 PE-PE Session Maintenance............................. 5 4. Frame-Relay Specific AVPs................................. 5 5. Security Considerations................................... 6 6. IANA Considerations....................................... 6 7. Acknowledgments........................................... 7 8. References................................................ 7 9. Contacts.................................................. 8 1. Introduction This document describes the specifics of how to use the L2TP control plane for Frame-Relay Pseudo-Wires, including 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. This document should eventually reference a single PWE3 Working Group document that defines the common Frame-Relay encapsulation method, circuit emulation requirements, and faithfulness statement regarding Frame-Relay over a Packet Switched Network (PSN). The next revision of this document will revisit what is necessary to be updated based on the output of the PWE3 Working Group at that time. 1.1 Abbreviations CE Customer Edge FR Frame-Relay FRPW Frame-Relay Pseudo-Wire Townsley, et al. Standards Track [Page 2]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 LCCE L2TP Control Connection Endpoint (See [L2TP]) PE Provider Edge (typically also the LCCE). PSN Packet Switched Network PVC Permanent virtual circuit 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 [L2TP]. 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 [L2TP]. This identifies the control connection as able to establish L2TP sessions to support Frame-Relay Pseudo-Wires (FRPWs). 3. Frame-Relay PVC Status Notification 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 [L2TP]. 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 Frame-Relay Circuit Status AVP (defined in Section 4) MUST be present in the ICRQ and ICRP messages. 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 3]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 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 Frame-Relay Status AVP indicates that this PVC is ACTIVE and New (0x03). The End Identifier AVP must be present in the ICRQ in order to identify the PVC to attach the L2TP session to. The End Identifier AVP defined in [L2TP] is of opaque form, though FRPW implementions SHOULD 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 Frame-Relay 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 4]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 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 [L2TP]. General Result Codes regarding L2TP session establishment are defined in [L2TP]. 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 [L2TP] 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 "fire and forget" 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 is sent with the required AVPs defined in [L2TP], and one additional Frame-Relay Specific AVP as defined in Section 4. Note that 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). The SLI message MUST be sent any time there is a status change of any values identified in the Frame-Relay 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. All sessions established by a given control connection utilize the L2TP Hello factility defined in Section 4.4 of [L2TP] for session keepalive. This gives all sessions basic dead peer and path detection between PEs. 4. Frame-Relay Specific AVPs This section defines all Frame-Relay Specific AVPs necessary for FRPW. There is currently only one new AVP defined beyond those Townsley, et al. Standards Track [Page 5]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 specified in [L2TP]. Frame-Relay Circuit Status AVP Frame-Relay Circuit Status AVP, Attribute Type TBD (see IANA Considerations Section), indicates the current Frame-Relay PVC state for the associated session of the sender of this AVP. This AVP is for use only on Frame-Relay Pseudo-Wire sessions, and MUST be present in the ICRQ, ICRP, and SLI messages. The Attribute Value field for this AVP has the following format: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|N| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Value is a 16 bit mask with the first two bits defined and the remaining bits reserved for future use (See IANA Considerations Section). Reserved bits MUST be set to 0 when sending, and ignored upon receipt. The A (Active) bit indicates whether the PVC is ACTIVE (1) or INACTIVE (0). The N (New) bit indicates whether the circuit status indication is for a new PVC (1) or an existing PVC (0). All L2TP AVPs have an M (Mandatory) bit, H (Hidden) bit, Length, and Vendor ID in the generic AVP format as decribed in Section 5.1 of [L2TP]. This AVP may be hidden (the H bit may be 0 or 1). The M bit for this AVP SHOULD be set to 1. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0. 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 signalling 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. Townsley, et al. Standards Track [Page 6]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 This document specifies one additional AVP Attribute to be defined by IANA as described in section 9.1 of [L2TP]. This document defines a bitmask of 16 bits in section 4. Two of these bits are defined in this document. The remaining bits are available for assignment via IETF Consensus [RFC2434]. 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]. 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. Thanks to Lloyd Wood for a razor-sharp review. 8. References [L2TP] 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. [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. [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 Townsley, et al. Standards Track [Page 7]
INTERNET DRAFT L2TP PWE3 Frame Relay February 2002 L2TP Using IPsec," RFC 3193, November 2001 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 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 8]
