[Docs] [txt|pdf] [Tracker] [WG] [Email] [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-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]


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