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

PPP Working Group                                          Pat R. Calhoun
INTERNET DRAFT                                     Sun Microsystems, Inc.
Category: Internet Draft                                       Ken Peirce
Title: draft-ietf-pppext-l2tp-mpls-00.txt                3Com Corporation
Date: March 1998



                         Layer Two Tunneling Protocol "L2TP"
                       Multi-Protocol Label Switching Extension
                         <draft-ietf-pppext-l2tp-mpls-00.txt>


Status of this Memo

   This  document  is  an  Internet-Draft.  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.
   Internet-Drafts  may  be  updated,  replaced,  or  obsoleted  by other
   documents at any time.  It is not appropriate to  use  Internet-Drafts
   as  reference  material  or  to  cite  them  other than as a ``working
   draft'' or ``work in progress.''

   To learn the current status of any Internet-Draft,  please  check  the
   1id-abstracts.txt  listing  contained  in  the  Internet-Drafts Shadow
   Directories on ds.internic.net,  nic.nordu.net,  ftp.nisc.sri.com,  or
   munnari.oz.au.


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 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
      3.0 References


Calhoun, Peirce              expires September 1998              [Page 1]



INTERNET DRAFT                                                 March 1998


      4.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.

   Note that this document does not cover the  negotiation  of  the  LSP.
   This  is  a  function of the Label Distribution Protocol which has not
   yet  been  determined.  However,  having  the  L3  address  and   it's
   contextually meaningful Mlabel should provide the components needed to
   create the LSP regardless of the final LDP design.

   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.

   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  specifi-
   cation 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.



Calhoun, Peirce              expires September 1998              [Page 2]



INTERNET DRAFT                                                 March 1998


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.


       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.


3.0 References

   [1] K. Hamzeh, T. Kolar, M. Littlewood, G. Singh Pall, J. Taarud,
       A. J. Valencia, W. Verthein, W.M. Townsley, B. Palter,
       A. Rubens "Layer Two Tunneling Protocol (L2TP)",
       Internet draft, October 1997



Calhoun, Peirce              expires September 1998              [Page 3]



INTERNET DRAFT                                                 March 1998


   [2] E. Rosen, Y. Rekhter, D. Tappan, D. Farinacci, G. Fedorkow,
       T. Li, A. Conta, "MPLS Label Stack Encoding",
        draft-ietf-mpls-label-encaps-01.txt, February 1998.

   [3] E. Rosen, A. Viswanathan, R. Callon, "A Proposed Architecture
       for MPLS", draft-ietf-mpls-arch-00.txt, August 1997.

   [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, November 1997.

   [5] B. Davie, Y. Rekhter, E. Rosen, A. Viswanathan, V, Srinivasan,
       "Use of Label Switching With RSVP", draft-davie-mpls-rsvp-01.txt,
        November 1997.

4.0 Authors' Addresses

   Questions about this memo can be directed to:

      Pat R. Calhoun
      Technology Development
      Sun Microsystems, Inc.
      15 Network Circle
      Menlo Park, California, 94025
      USA

       Phone:  1-847-548-9587
         Fax:  1-650-786-6445
      E-mail:  pcalhoun@toast.net


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

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













Calhoun, Peirce              expires September 1998              [Page 4]