One document matched: draft-ietf-pppext-l2tp-mpls-01.txt
Differences from draft-ietf-pppext-l2tp-mpls-00.txt
PPP Working Group Pat R. Calhoun
INTERNET DRAFT Sun Microsystems, Inc.
Category: Informational Ken Peirce
Title: draft-ietf-pppext-l2tp-mpls-01.txt 3Com Corporation
Date: July 1998
Layer Two Tunneling Protocol "L2TP"
Multi-Protocol Label Switching Extension
<draft-ietf-pppext-l2tp-mpls-01.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 ftp.ietf.org, 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
Calhoun, Peirce expires January 1999 [Page 1]
INTERNET DRAFT July 1998
2.0 Multi-Protocol Label Switching
2.1 Multi-Protocol Label AVP
2.2 Error Reporting
3.0 References
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.
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 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
Calhoun, Peirce expires January 1999 [Page 2]
INTERNET DRAFT July 1998
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.
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
Calhoun, Peirce expires January 1999 [Page 3]
INTERNET DRAFT July 1998
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] 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
[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
Calhoun, Peirce expires January 1999 [Page 4]
INTERNET DRAFT July 1998
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-6794
Fax: 1-847-222-2424
E-mail: Ken_Peirce@mw.3com.com
Calhoun, Peirce expires January 1999 [Page 5]
| PAFTECH AB 2003-2026 | 2026-04-23 05:59:43 |