[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07 RFC 4349

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-

   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

   The list of Internet-Draft Shadow Directories can be accessed at

   The distribution of this memo is unlimited.  It is filed as <draft-
   townsley-l2tp-pwe3-hdlc-00.txt> and expires December 2002.

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.


   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


   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

   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

   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

Townsley                    Standards Track                     [Page 7]

Html markup produced by rfcmarkup 1.111, available from https://tools.ietf.org/tools/rfcmarkup/