One document matched: draft-ietf-l2tpext-mpls-00.txt

INTERNET DRAFT                                            Pat R. Calhoun
Category: Informational                           Sun Microsystems, Inc.
Title: draft-ietf-l2tpext-mpls-00.txt                         Ken Peirce
Date: March 2000                                   Malibu Networks, Inc.



                  Layer Two Tunneling Protocol "L2TP"
                Multi-Protocol Label Switching Extension



Status of this Memo

   This document is a submission by the L2TP Extensions Working Group of
   the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the l2tp@ipsec.org mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft and is in full conformance with
   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/ietf/1id-abstracts.txt

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

      http://www.ietf.org/shadow.html.


Abstract

   The L2TP document [1] defines the base protocol which describes the
   method of tunneling PPP data. The L2TP base protocol does not address
   any MPLS extensions.

   The goal of MPLS is to speed forwarding of packets by reducing the
   lookup required in routing. This draft proposes a method to allow



Calhoun, Peirce         expires September 2000                  [Page 1]





INTERNET DRAFT                                                March 2000


   L2TP Data Sessions to be assigned an MPLS Label Switched Path Id
   (LSPID)[3] for an explicit route (ER). Assignment of such an ER is
   necessary for traffic engineering.


Table of Contents

   1.0 Introduction
       1.1 Conventions
   2.0 Multi-Protocol Label Switching
       2.1 Multi-Protocol LSPID AVP
       2.2 Error Reporting
   3.0 References
   4.0 Acknowledgements
   5.0 Authors' Addresses


1.0 Introduction

   The L2TP protocol specification does not discuss Multi-Protocol Label
   Switching (MPLS)[5] in any way. This document will describe how two
   L2TP peers can negotiate an LSPID for an L2TP over MPLS session. This
   will provide either the LNS or LAC with an LSPID with which to select
   an explicit MPLS Label Switched Path to the peer. The application of
   an LSPID should speed the forwarding of the L2TP packets by reducing
   the header analysis/lookup and permit effective traffic engineering.

   Note that this document does not cover the creation of the LSPID.
   This is a function of the Label Distribution Protocol[4].

   MPLS explicit routes are uni-directional. Thus LSPIDs may be used to
   specify ERs in either or both the LAC-to-LNS and the LNS-to-LAC
   directions. The mechanism defined in this document assumes that the
   Tunnel Initiator SHALL determine what the user's appropriate LSPID is
   for LNS-to-LAC traffic and send that information in either the ICRQ
   or OCRQ messages.

   The Tunnel Terminator SHALL determine the appropriate LSPID for LAC-
   to-LNS traffic by including this information in the ICRP or OCRP.

   In the case where either one or both peers do not propose ANY LSPIDs,
   (which is inferred by the absence of the LSPID AVPs in the respective
   request and or response, it is assumed that the sending peer has no
   preference for the routing of the session traffic.

   A peer which fails to use an accepted LSPID in the routing of traffic
   MAY have its sessions(s) dropped.




Calhoun, Peirce         expires September 2000                  [Page 2]





INTERNET DRAFT                                                March 2000


1.1 Conventions

   The following language conventions are used in the items of
   specification in this document:

      o  MUST, SHALL, or MANDATORY -- This item is an absolute
         requirement of the specification.

      o  SHOULD or RECOMMEND -- This item should generally be followed
         for all but exceptional circumstances.

      o  MAY or OPTIONAL -- This item is truly optional and may be
         followed or ignored according to the needs of the implementor.


2.0 Multi-Protocol Label Switching

   This section will define the new AVP which is required for the MPLS
   label distribution extension of the L2TP protocol. The AVP allows the
   designation of an LSPID for a specific data channel or group of data
   channels.


2.1 Multi-Protocol LSPID AVP

   The LSPID is an opaque object for an L2TP session used in a method
   similar to [3]. The LSPID is defined in [3]. The following AVP holds
   the LSPID without any knowledge of its composition. The reader should
   note that the format of the LSPID is that of an MPLS TLV. However,
   that MPLS TLV is to be strictly treated as an opaque object by L2TP.

   The Multi-Protocol LSPID AVP MAY be present in ICRQ, ICRP, OCRQ and
   OCRP. This message is used to inform the tunnel peer that a specific
   MPLS ER SHOULD be used for all packets related to the data channel
   associated with the Tunnel and Call Identifiers in the L2TP header
   [1].

   A peer which violates the routing of traffic in accordance with an
   accepted LSPID MAY have its sessions(s) dropped.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |1|1|0|0|        Length         |              43               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                1              |  LSPID TLV[see 3] Value  ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




Calhoun, Peirce         expires September 2000                  [Page 3]





INTERNET DRAFT                                                March 2000


   This AVP MAY be present in the messages shown above. It is encoded
   with a Vendor ID of 43 (3Com Corporation) with the attribute set to
   2, marked as optional, with the indicator value as data. This AVP
   SHOULD NOT be hidden and is optional. When present, the L2TP peer is
   indicating that Multi-Protocol LSPIDs are to be used.


2.2 Error Reporting

   In the event that the peer did not accept the LSPID provided, or is
   unable to support MPLS a Call-Disconnect-Notify is returned to the
   peer.

   If the LSPID provided cannot be used by the peer, the Call-
   Disconnect-Notify message will include the Multi-Protocol LSPID AVP
   as provided in the message that caused the Call-Disconnect-Notify.


3.0 References

     [1] W.M. Townsley, A. J. Valencia, A. Rubens, G.S. Pall, G. Zorn,
         B. Palter. "Layer Two Tunneling Protocol (L2TP)", RFC 2661.
         August 1999.
     [2] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow, T.
         Li, A. Conta. "MPLS Label Stack Encoding", draft-ietf-mpls-
         label-encaps-07.txt, IETF Work in Progress.  September 1999.
     [3] Jamoussi et al. "Constraint-Based LSP Setup using LDP", draft-
         ietf-mpls-cr-ldp-03.txt, IETF Work in Progress. September 1999.
     [4] L. Andersson, P. Doolan, N. Feldman, A. Fredette, B. Thomas.
         "LDP Specification", draft-ietf-mpls-ldp-06.txt, IETF Work in
         Progress. October 1999.
     [5] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow, A.
         Viswanathan. "A Framework for Multiprotocol Label Switching",
         draft-ietf-mpls-framework-05.txt, IETF Work in Progress.
         September 1999.


4.0 Acknowledgements

   The Authors would like to acknowledge John Shriver for his useful
   comments to an earlier version of this document.


5.0 Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun



Calhoun, Peirce         expires September 2000                  [Page 4]





INTERNET DRAFT                                                March 2000


      Network and Security Research Center, Sun Labs
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-650-786-7733
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@eng.sun.comt



      Ken Peirce
      Malibu Networks
      1035 Suncast Lane, Suite 130
      El Dorado Hills, CA, 95762

      Phone:  1-916-941-8814
      Fax:    1-916-941-8850
      E-mail: Ken@malibunetworks.com































Calhoun, Peirce         expires September 2000                  [Page 5]