Network Working Group W. Mark Townsley Internet-Draft cisco Systems Category: Standards Track June 2002 HDLC Frames Over L2TPv3 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 and expires December 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract Simple HDLC frame transport over L2TPv3 is described in this document. This mechanism may be used in the creation of pseudowires to transport HDLC PDUs over an IP network. Townsley Standards Track [Page 1] INTERNET DRAFT HDLC Frames Over L2TPv3 February 2002 Contents Status of this Memo.......................................... 1 1. Introduction.............................................. 2 1.1 Abbreviations......................................... 2 2. PE-PE Control Connection Establishment.................... 3 3. HDLC Circuit Status Notification and Session Establishment 3 3.1 PE-PE Session Establishment........................... 3 3.2 PE-PE Session Teardown................................ 5 3.3 PE-PE Session Maintenance............................. 5 3.3 Use of Circuit Status AVP for HDLC.................... 5 4. Encapsulation............................................. 6 4.1 Data Packet Sequencing................................ 6 5. Security Considerations................................... 6 6. IANA Considerations....................................... 6 7. Acknowledgments........................................... 6 8. References................................................ 6 9. Contacts.................................................. 7 1. Introduction This document describes the specifics of how to use L2TPv3 for simple HDLC-Framed Pseudowires. L2TPv3 is used in the creation, deletion, and maintenance of the pseudowire which carries HDLC formatted PDUs. All HDLC framed data and control packets are carried over the PW, offering emulated transport for HDLC and HDLC-like links over L2TP. 1.1 Abbreviations CE Customer Edge HDLC PW HDLC Pseudo-Wire LCCE L2TP Control Connection Endpoint (See [L2TPv3]) PE Provider Edge (typically also the LCCE). PSN Packet Switched Network PW Pseudo-Wire PWE3 Pseudo-Wire Emulation Edge to Edge (Working Group) Townsley Standards Track [Page 2] INTERNET DRAFT HDLC Frames Over L2TPv3 February 2002 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 [L2TPv3]. The SCCRQ and corresponding SCCRP MUST include the HDLC 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 in support of HDLC Pseudo-Wires (HDLC PWs). 3. HDLC Circuit Status Notification and Session Establishment This section specifies how the status of an HDLC interface is reported between two PEs, and the associated L2TP session creation and deletion that occurs. 3.1 PE-PE Session Establishment Associating an HDLC serial interface with a PW and its transition to "Ready" or "Up" results in the establishment of an L2TP session via the standard three-way handshake described in section 3.4.1 of [L2TPv3]. For purposes of this discussion, the action of locally associating an interface running HDLC with a PW by local configuration or otherwise is referred to as "Provisioning" the HDLC interface. The transition of the interface to "Ready" or "Up" will be referred to as the interface becoming ACTIVE. The transition of the interface to "Not-Ready" or "Down" will be referred to as the interfacing becoming INACTIVE. An LCCE MAY initiate the session immediately upon association with an HDLC interface, or wait until the interface becomes ACTIVE before attempting to establish an L2TP session. The Circuit Status AVP (see Section 4) MUST be present in the ICRQ, ICRP messages and MAY be present in the SLI message for HDLC PWs. Following is an example of the L2TP messages exchanged for establishing an HDLC PW L2TP session. Townsley Standards Track [Page 3] INTERNET DRAFT HDLC Frames Over L2TPv3 February 2002 PE (LAC) A PE (LAC) B ------------------ ------------------ HDLC Interface Provisioned HDLC Interface Provisioned HDLC Interface ACTIVE ICRQ (status = 0x03) ----> HDLC Interface 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 HDLC interface is provisioned and becomes ACTIVE. The Circuit Status AVP indicates that this interface is ACTIVE and New (0x03). The End Identifier AVP MUST be present in the ICRQ in order to identify the interface to attach the L2TP session to. The End Identifier AVP defined in [L2TPv3] is of opaque form, though HDLC PW implementations MAY simply use a four- octet value that is known to both PEs (either by direct configuration, or some other means such as a directory lookup). 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 HDLC interface transitions to ACTIVE. If PE B had not been provisioned for the interface identified in the ICRQ, a CDN would have been immediately returned indicating that the interface 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 and have an exponential backoff. An Implementation MAY send an ICRQ or ICRP before an interface is ACTIVE, as long as the Circuit Status AVP reflects that the interface is INACTIVE and an SLI is sent when the interface 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 bi- directional traffic. Townsley Standards Track [Page 4] INTERNET DRAFT HDLC Frames Over L2TPv3 February 2002 3.2 PE-PE Session Teardown In the event an interface is removed (unprovisioned) at either PE, the associated L2TP session MUST be torn down via the CDN message defined in Section 3.4.3 of [L2TPv3]. 3.3 PE-PE Session Maintenance HDLC PW over L2TP makes use of the Set Link Info (SLI) control message defined in [L2TPv3] to signal HDLC link status notifications between PEs. The SLI message is a single message that is sent over the L2TP control channel, signaling the interface state change. The SLI message MUST be sent any time there is a status change of 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. 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 facility defined in [L2TPv3] for session keepalive. This gives all sessions basic dead peer and path detection between PEs. 3.3 Use of Circuit Status AVP for HDLC HDLC reports Circuit Status with the Circuit Status AVP defined in [L2TPv3]. For reference, this AVP is shown below: 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 HDLC interface is ACTIVE (1) or INACTIVE (0). The N (New) bit SHOULD be set to one (1) if this is the first time this interface has transitioned to ACTIVE, zero (0) otherwise. Townsley Standards Track [Page 5] INTERNET DRAFT HDLC Frames Over L2TPv3 February 2002 4. Encapsulation HDLC PWs use the default encapsulations defined in [L2TPv3] for demultiplexing, sequencing, and flags. The HDLC PW Type over L2TP is intended to operate in an "interface to interface" or "port to port" fashion, passing all HDLC data and control PDUs over the PW. The HDLC PDU is stripped of flags and trailing FCS, bit/byte unstuffing is performed, and the remaining data, including the address, control and protocol fields, transported over the PW. End-to-end HDLC control traffic over the PW MAY be tagged with the L2TPv3 P (Priority) bit if the Default L2-Specific Sublayer is present. Since all packets are passed in a largely transparent manner over the HDLC PW, any protocol which has HDLC-like framing may utilize the HDLC PW mode, including PPP, Frame-Relay, X.25, etc. Exceptions include cases where direct access to the HDLC interface is required, or modes which operate on the flags, FCS, or bit/byte unstuffing that is performed before sending the HDLC PDU over the PW. An example of this is PPP ACCM negotiation. 4.1 Data Packet Sequencing Data Packet Sequencing MAY be enabled for HDLC PWs. The sequencing mechanisms described in [L2TPv3] MUST be used for signaling sequencing support. HDLC PW 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 HDLC PWs, this document will eventually refer to documents from the PWE3 WG. L2TP-specific Security Considerations are TBD. 6. IANA Considerations The signaling mechanisms defined in this document rely upon the assignment of an HDLC Pseudowire Type. IANA assignment of this value should take place within the PWE3 WG. 7. Acknowledgments Thanks to Sudhir Rustogi and George Wilkie for valuable input. 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. Townsley Standards Track [Page 6] INTERNET DRAFT HDLC Frames Over L2TPv3 February 2002 "L2TPv3," work in progress, draft-ietf-l2tpext-l2tp-base-03.txt, June 2002. [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. [L2TP-IANA] Townsley, W., "L2TP IANA Considerations Update", Internet Draft, draft-ietf-l2tpext-rfc2661-iana-00.txt, April 2002 9. Contacts W. Mark Townsley cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709 mark@townsley.net Townsley Standards Track [Page 7]