MPLS WG Loa Andersson
Internet Draft Bilel Jamoussi
Expiration Date: February 2000 Nortel Networks Corp.
Muckai Girish
SBC Technology Resources Inc.
Tom Worster
Nokia
October 1999
MPLS Capability Set
draft-loa-mpls-cap-set-01.txt
Status of this Memo
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
Several protocols might be used for Label Distribution in an MPLS
network, e.g. Label Distribution Protocol (LDP), including the part
of LDP described in Constraint-Based LSP Setup using LDP, the BGP-4
and RSVP.
The functionality defined in those protocols are to some extent
overlapping, but also complementary. This document specifies a
number of MPLS Capability sets that can be used to define what is
needed from an MPLS implementation in order to interwork with other
implementations. The number of Capability sets might change in the
future.
Andersson, et. al. [Page 1]
Internet Draft MPlS Capability Set October, 1999
Table of Contents
Abstract ..........................................................1
Table of Contents .................................................2
1. Introduction ...................................................2
2. Overview .......................................................2
3. MPLS Capability set ............................................3
4. Protocol and functional components .............................3
5. Defined MPLS Capability set ....................................3
5.1 MPLS Capability set #1 ........................................4
5.2 MPLS Capability set #2 ........................................4
5.3 MPLS Capability set #3 ........................................4
5.4 MPLS Capability set #4 ........................................5
5.5 MPLS Capability set #5 ........................................5
5.6 MPLS Capability set #6 ........................................5
5.7 MPLS Capability set #7 ........................................5
5.8 MPLS Capability set #8 ........................................5
5.9 MPLS Capability set #9 ........................................5
5.10 MPLS Capability set #42 ......................................6
5.11 Future extensibility .........................................6
6. Security .......................................................6
7. Acknowledgements ...............................................6
8. References .....................................................6
1. Introduction
The set of documents that constitute the MPLS standard, as it is
being specified by the MPLS Working Group of IETF, offers several
ways of setting up Label Switched Paths (LSP) for a number of
applications, including support for traffic engineering and Virtual
Private Networks.
The Label Distribution Protocol (LDP) has been developed by the MPLS
WG for the explicit task of doing Label Distribution. Other
protocols, already in existence and originally developed for other
purposes, have been adapted or extended to support Label
Distribution.
This draft addresses unicast functionality only, multicast is for
further study.
2. Overview
It has been frequently noted that the functionality supported by the
most of the specifications of how you do Label Distribution, for
most applications, are richer than necessary. MPLS implementations
implementing parts of one specification or a mix of parts from
several specifications will be viable.
Andersson, et. al. February 2000 [Page 2]
Internet Draft MPlS Capability Set October, 1999
As all implementations won't support all of the specified mechanisms
for Label distribution specified in the MPLS standard. This
introduces the requirement of a tool for describing the compliance
between MPLS implementations.
3. MPLS Capability set
This draft introduces the MPLS Capability set as a method of
specifying the compliance of an implementation to the set of MPLS
specifications and to other implementations. This draft gives an
overview of what is needed, in terms of protocols and mechanism, to
support the MPLS capability sets.
4. Protocol and functional components
The following functional and protocol component are available in the
protocols developed for and/or extended to do label distribution,
[1], [2], [3] and [4]. All the specification listed below are worked
on by the MPLS WG, and is still work in progress.
Carrying Label Information in BGP-4 [1]
Defines mechanisms for:
- assigning labels to BGP routes
Constraint based routing with LDP (CR-LDP) [2]
Defines mechanisms for:
- explicit routed LSPs
- LSP set up with defined QoS
Label Distribution Protocol (LDP) [4]
Defines mechanisms for:
- basic LDP mechanisms
- LDP neighbor detection
- LDP session initiation, maintenance and termination
- loop detection
- modes of label distribution defined in [5]
- Downstream Unsolicited Independent Control
- Downstream Unsolicited Ordered Control
- Downstream On Demand Independent Control
- Downstream On Demand Ordered Control
Extensions to RSVP for LSP Tunnels [3]
Defines mechanisms for:
- explicit routed LSPs
- dynamic distribution of labels (hop-by-hop mechanism)
5. Defined MPLS Capability set
Andersson, et. al. February 2000 [Page 3]
Internet Draft MPlS Capability Set October, 1999
An MPLS Capability set defines the set of components that has to be
supported by an implementation claiming compatibility with the
capability set. Currently there are 10 Capability sets defined.
Although there sometimes/frequently is an obviously a relationship
between the Capability set and an intended use, this draft doesn't
state the intended use of or the application possible to support by
the capability set.
The intention is instead to give a reference framework that offers a
possibility to classify compatibility of MPLS implementations. The
Capability sets is atomic, i.e. it is not possible for an
application to be compliant to part of a capability set. However it
is possible for an application to be compliant with one or more
capability sets.
5.1 MPLS Capability set #1
MPLS Capability set #1 includes the following components:
- LDP basic mechanisms
- LDP neighbor detection
- LDP session initiation, maintenance and termination
- CR-LDP strict explicit routed LSPs
This Capability set supports explicit routed LSP set up, but does
not allow loosely routed segments on an explicit route. Note that
this capability set do not require the loop detection mechanism.
5.2 MPLS Capability set #2
MPLS Capability set #2 includes the following components:
- LDP basic mechanisms
- CR-LDP explicit routed LSPs
- modes of label distribution defined in [5]
- Downstream On Demand Ordered Control
This Capability set supports explicit routing and allows loosely
routed segments of an explicit route.
5.3 MPLS Capability set #3
MPLS Capability set #3 includes the following components:
- LDP basic mechanisms
- CR-LDP explicit routed LSPs
- CR-LDP LSP set up with QoS
- modes of label distribution defined in [5]
- Downstream On Demand Ordered Control
This Capability set supports explicit routing and allows loosely
routed segments of an explicit route.
Andersson, et. al. February 2000 [Page 4]
Internet Draft MPlS Capability Set October, 1999
5.4 MPLS Capability set #4
MPLS Capability set #4 includes the following components:
- LDP basic mechanisms
- All the modes of label distribution defined in [5]
This Capability set is label distribution as defined in [4].
5.5 MPLS Capability set #5
MPLS Capability set #5 includes the following components:
- LDP basic mechanisms
- All the modes of label distribution defined in [5]
- CR-LDP explicit routed LSPs
- CR-LDP LSP set up with QoS
This Capability set is label distribution as defined in [4] and
[2] combined.
5.6 MPLS Capability set #6
MPLS Capability set #6 includes the following components:
- LDP basic mechanisms
- Downstream unsolicited independent control
This Capability set emulates the behavior of a legacy best effort IP
network.
5.7 MPLS Capability set #7
MPLS Capability set #7 includes the following components:
- RSVP explicit routed LSPs
- RSVP based dynamic distribution of labels
This Capability set is label distribution as defined in [3].
5.8 MPLS Capability set #8
MPLS Capability set #8 includes the following components:
- RSVP explicit routed LSPs
- LDP basic mechanisms
- All the modes of label distribution defined in [5]
This Capability set gives explicit routed LSPs and a hop-by-hop
mechanism.
5.9 MPLS Capability set #9
MPLS Capability set #9 includes the following components:
- Assigning label to BGP routes as defined in [1].
Andersson, et. al. February 2000 [Page 5]
Internet Draft MPlS Capability Set October, 1999
This Capability set could be used with any of capability set 1
through 7, and will in that case give a possibility to support
network hierarchy. It could also be used alone.
5.10 MPLS Capability set #42
MPLS Capability set #42 includes all of the components listed in
section 4 of this draft.
An LSR claiming 42 compliance should, with proper configuration, be
able to inter work with any other LSR compliant with any of the
capability sets.
5.11 Future extensibility
The number or capability sets are not static, but might be increased
or reduced as required, e.g. if the number of protocols
specification that defines label distribution changes. If there is a
need for any Capability set that has not been specified here it will
be added. Likewise, if any of the defined Capabilities sets fall out
of use it will be removed.
6. Security
This draft does not introduce any new security issues to the various
label distribution protocols.
7. Acknowledgements
We would like to thank the members of the MPLS working group of the
IETF, whose input and scrutiny of this document has been invaluable.
8. References
1 Y. Rehkter and E. Rosen, "Carrying Label Information in BGP-4"
<draft-ietf-mpls-bgp4-mpls>, work in progress, August 1998.
2 B. Jamoussi et. al., "Constraint-Based LSP Setup using LDP"
<draft-ietf-mpls-cr-ldp> work in progress, October 1999.
3 D. Awduche, L. Berger, D. Gan, T. Li, G. Swallow,
V Srinivasan, "Extensions to RSVP for LSP Tunnels", < draft-ietf-
mpls-rsvp-lsp-tunnel>, work in progress, October 1999.
4 L. Andersson et al., "LDP specification",
<draft-ietf-mpls-ldp>, work in progress, October 1999.
5 E. Rosen, A. Viswanathan, R. Callon,"Multiprotocol Label Switching
Architecture", < draft-ietf-mpls-arch>, work in progress, September
1999.
Andersson, et. al. February 2000 [Page 6]
Internet Draft MPlS Capability Set October, 1999
9. Author's Addresses
Loa Andersson Muckai K Girish
Nortel Networks Corp. SBC Technology Resources,
S:t Eriksgatan 115 4698 Willow Road
PO Box 6701 Pleasanton, CA 94588
113 85 Stockholm Phone: (925) 598-1263
Tel: +46 8 508 835 00 Fax: (925) 598-1321
Fax: +46 8 508 835 01 Mgirish@tri.sbc.com
Loa_andersson@nortelnetworks.com
Tom Worster Bilel Jamoussi
Nokia Nortel Networks Corp.
3 Burlington Woods Dr. 600 Technology Park Drive
Suite 250 Billerica, MA 01821
Burlington MA 01803 USA USA
+1 617 247 2624 phone: +1 978-288-4506
Tom.worster@nokia.com Jamoussi@nortelnetworks.com
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Andersson, et. al. February 2000 [Page 7]