[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

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

Network Working Group                                   W. Mark Townsley
Internet-Draft                                             George Wilkie
Category: Standards Track                                     Skip Booth
<draft-ietf-l2tpext-pwe3-fr-01.txt>                              Jed Lau
June 2002                                                 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-01.txt> and expires December 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 [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             February 2002


   PVC creation, deletion, and line status change notification.


















































Townsley, et al.            Standards Track                     [Page 2]

INTERNET DRAFT           L2TP PWE3 Frame Relay             February 2002


   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             February 2002


   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             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 Circuit 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 [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             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 [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             February 2002


    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             February 2002


   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             February 2002


   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             February 2002


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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/