One document matched: draft-ietf-pppext-l2tp-mpls-02.txt

Differences from draft-ietf-pppext-l2tp-mpls-01.txt

INTERNET DRAFT                                             Pat R. Calhoun
Category: Informational                            Sun Microsystems, Inc.
Title: draft-ietf-pppext-l2tp-mpls-02.txt                      Ken Peirce
Date: February 1999                                      3Com Corporation



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



Status of this Memo

   This document is a submission by the PPP 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 [2] 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 August 1999                   [Page 1]





INTERNET DRAFT                                             February 1999


   L2TP Data Sessions to be assigned a Multi-Protocol Label.


Table of Contents

   1.0 Introduction
       1.1 Conventions
   2.0 Multi-Protocol Label Switching
       2.1 Multi-Protocol Label 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) [4] in any way. This document will describe how two
   L2TP peers can negotiate an Multi-Protocol Label (Mlabel) for an L2TP
   session. This will provide either the LNS or LAC with an Mlabel with
   which to initiate the creation of an MPLS Label Switched Path to the
   peer. The application of an MPLS should speed the forwarding of the
   L2TP packets by reducing the header analysis/lookup.

   This L2TP extension allows individual sessions within a tunnel to
   have their own Mlabel.

   Note that this document does not cover the negotiation of the LSP.
   This is a function of either the Label Distribution Protocol [5] or a
   routing protocol(like BGP)[6] with extensions. However, having the L3
   address and it's contextually meaningful Mlabel should provide the
   components needed to use an LSP regardless of the label distribution
   mechanism used.

   The mechanism defined in this document assumes that the Tunnel
   Initiator determines what the user's appropriate label is and sends
   the value in either the ICRQ or OCRQ messages.

   The Tunnel Terminator can respond to the message by stating what it
   believes is the user's appropriate label.

   In the case where the Tunnel Terminator does not propose ANY
   indicator (which is infered by the absence of the MPLS AVPs in either
   the ICRP or OCRP) the Tunnel Initiator will assume its Mlabel is
   acceptable or, if it did not send one in the ICRQ or OCRQ, that no
   Mlabel is assigned to the session.




Calhoun, Peirce           expires August 1999                   [Page 2]





INTERNET DRAFT                                             February 1999


   A tunnel peer which violates the negotiated label value is unlikely
   to successfully create an LSP.


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 Mlabel for a specific data channel or group of data
   channels.


2.1 Multi-Protocol Label AVP

   The Mlabel is an opaque object for an L2TP session used in a method
   similar to [5]. The following AVP holds the Mlabel without any
   knowledge of its composition.

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

   A tunnel peer which violates the negotiated label value is unlikely
   to successfully create an LSP.










Calhoun, Peirce           expires August 1999                   [Page 3]





INTERNET DRAFT                                             February 1999


       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              |  Multi-Protocol Label Value   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Multi-Protocol Label Value   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 Labels are to be used at the link
   layer.


2.2 Error Reporting

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

   If the Mlabel provided cannot be used by the peer, the Call-
   Disconnect-Notify message will include the Multi-Protocol Label 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)",
       draft-ietf-pppext-l2tp-13.txt, Work in Progress, January 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-03.txt, Work in Progress,
       March 1999.

   [3] E. Rosen, A. Viswanathan, R. Callon, "Multiprotocol Label
       Switching Architecture", draft-ietf-mpls-arch-04.txt,
       Work in Progress, February 1999.

   [4] R. Callon, P. Doolan, N. Feldman, A. Fredette, G. Swallow,
       A. Viswanathan, "A Framework for Multiprotocol Label
       Switching", draft-ietf-mpls-framework-02.txt, Work in
       Progress, November 1997.



Calhoun, Peirce           expires August 1999                   [Page 4]





INTERNET DRAFT                                             February 1999


   [5] Andersson, Doolan, Feldman, Fredette, Thomas, "LDP
       Specification", draft-ietf-mpls-ldp-03.txt. Work in
       Progress, January 1999.

   [6] Rekhter, Rosen, "Carrying Label Information in BGP-4",
       draft-ietf-mpls-bgp4-mpls-02.txt, Work in Progress,
       August 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
      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.com


      Ken Peirce
      3Com Corporation
      1800 Central Ave.
      Mount Prospect, Il, 60056

       Phone:  1-847-342-6894
         Fax:  1-847-222-2424
      E-mail:  Ken_Peirce@mw.3com.com












Calhoun, Peirce           expires August 1999                   [Page 5]