Internet Draft
Network Working Group Eric C. Rosen
Internet Draft Bob Thomas
Expiration Date: September 2000 Lance Levine
Carol Iturralde
George Swallow
Cisco Systems, Inc.
March 2000
MPLS Profiles
draft-rosen-mpls-profiles-00.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
The MPLS protocol specifications provide a large number of options,
and it can be difficult to know exactly which protocol messages,
objects, and procedures must be supported in order to provide some
particular application of MPLS, or in order to interoperate with some
other implementation. This document specifies a number of MPLS
"Profiles". Each Profile is a subset of the full MPLS functionality,
specified in enough detail to ensure that two implementations of a
given Profile will interoperate. This document also specifies which
Profiles may be used for which purposes. In the future, it is hoped
that specifications for the applications of MPLS will specify the
Rosen, et al. [Page 1]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
Profiles that must be implemented in order to support the
application.
Table of Contents
1 Introduction ........................................... 2
2 Profile HH: Intra-Domain Hop-by-Hop LSP Setup .......... 3
2.1 Part 1: LDP: Discovery, Session Estab. & Maintenance ... 3
2.2 Part 2: Frame-Based LSRs ............................... 4
2.3 Part 3: ATM-LSRs ....................................... 4
3 Profile TE/RSVP: Explicit Path Setup ................... 5
3.1 Part 1: RSVP signalling and reliability extensions ..... 6
3.2 Part 2: IGP extensions for constraint-based routing .... 7
3.3 Part 3: RSVP Refresh Reduction ......................... 7
4 Profile BGP: BGP Label Distribution .................... 7
5 References ............................................. 8
6 Authors' Addresses ..................................... 8
1. Introduction
The MPLS protocol specifications provide a large number of options,
and it can be difficult to know exactly which protocol messages,
objects, and procedures must be supported in order to provide some
particular application of MPLS, or in order to interoperate with some
other implementation. This document specifies a number of MPLS
"Profiles". Each Profile is a subset of the full MPLS functionality,
specified in enough detail to ensure that two implementations of a
given Profile will interoperate. This document also specifies which
Profiles may be used for which purposes. In the future, it is hoped
that specifications for the applications of MPLS will specify the
Profiles that must be implemented in order to support the
application.
This document specifies three Profiles: a Hop-by-Hop Profile
("Profile HH"), a Traffic Engineering Profile ("Profile TE/RSVP"),
and a BGP label distribution Profile ("Profile BGP"). Some of these
Profiles have variants, which are also described.
Rosen, et al. [Page 2]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
2. Profile HH: Intra-Domain Hop-by-Hop LSP Setup
This Profile supports the basic LDP mechanisms that are needed for
setting up LSPs in a hop-by-hop manner [MPLS-LDP] within a single
routing domain.
This Profile consists of three parts:
- Part 1 consists of the basic LDP mechanisms for discovery,
session establishment, and session maintenance.
- Part 2 consists of messages and procedures which are to be used
by Frame-based LSRs.
- Part 3 consists of messages and procedures which are to be used
by ATM-LSRs.
Every implementation of this Profile will support Part 1. Every
implementation on a Frame-based LSR will support Part 2. Every
implementation on an ATM-LSR will support Part 3.
When it is stated that a particular implementation supports Profile
HH, it must be stated whether it supports Part 2, Part 3, or both.
2.1. Part 1: LDP: Discovery, Session Estab. & Maintenance
Part 1 of Profile 1 consists of the following:
- LDP Hello Message with:
* Common Hello Parameters TLV, including
+ T-bit, targeted Hello
+ R-bit, Request Send Targeted Hello
* Optional Parameters: Transport Address TLV
- LDP Initialization Message with:
* Common Session Parameters TLV, with support for all fields
* Optional Parameters: ATM Session Parameters TLV, with support
for all fields and support for all settings EXCEPT the
following settings of the M field:
+ VP Merge
+ VP & VC Merge
Rosen, et al. [Page 3]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
- LDP Keep Alive Message
- LDP Notification Message with Status TLV
- LDP Backoff Mechanism for session setup failures
- TCP MD5 Signature Option
2.2. Part 2: Frame-Based LSRs
A Frame-based LSR which supports Profile 1 will support Part 1 and
Part 2. Part 2 consists of the following.
- Unsolicited Downstream label distribution
- Independent Control
- Liberal Label Retention Mode
- LDP Address Message with Address List TLV
- LDP Address Withdraw Message with Address List TLV
- Label Mapping Message with:
* Prefix FEC for FEC TLV, address family IPv4
* Generic Label TLV
- Label Request Message with Prefix FEC for FEC TLV, address family
IPv4
- Label Withdraw Message with:
* Prefix FEC for FEC TLV, address family IPv4
* Generic Label TLV
- Label Release Message with:
* Prefix FEC for FEC TLV, address family IPv4
* Generic Label TLV
2.3. Part 3: ATM-LSRs
An ATM-LSR which supports Profile 1 will support Part 1 and Part 3.
Part 3 consists of the following.
Rosen, et al. [Page 4]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
- Downstream on Demand label distribution
- Ordered Control
- Conservative Label Retention
- Label Request Message with:
* Prefix FEC type for FEC TLV, address family IPv4
* HopCount TLV
* PathVector TLV (used only if Loop Detection is configured)
- Label Mapping Message with:
* Prefix FEC for FEC TLV, address family IPv4
* ATM Label TLV
* Label Request Message ID TLV
* HopCount TLV
* PathVector TLV (used only if Loop Detection is configured)
- Label Abort Request Message with:
* Prefix FEC for FEC TLV, address family IPv4
* Label Request Message ID TLV
- Label Withdraw Message with:
* Prefix FEC for FEC TLV, address family IPv4
* ATM Label TLV
- Label Release Message with:
* Prefix FEC for FEC TLV, address family IPv4
* ATM Label TLV
3. Profile TE/RSVP: Explicit Path Setup
This Profile is supported by systems which need to participate in LSP
setup for the purpose of traffic engineering.
Note that a system may support both Profile HH and Profile TE/RSVP if
some of its LSPs are traffic engineered, and some are set up hop-by-
hop.
This Profile has three Parts:
- Part 1 consists of RSVP extensions which are used to enable RSVP
to signal the LSP setup along an explicitly specified path.
- Part 2 consists of IGP extensions which are used to distribute
the information needed in order to support constraint-based
routing for OSPF [TE-OSPF] and/or the information needed in order
to support constraint-based routing for ISIS [TE-ISIS].
Rosen, et al. [Page 5]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
- Part 3 consists of RSVP extensions to reduce the "refresh
overhead" of RSVP.
Every implementation of Profile TE/RSVP will support Part 1.
If an implementation is to support constraint-based routing, then it
must implement Part 2; otherwise it need not.
Part 3 is optional, but recommended.
When stating that a particular implementation supports Profile
TE/RSVP, it must be stated whether it supports Parts 2 and/or 3. If
it supports Part 2, it must be stated whether it supports Part
2(OSPF) and/or Part 2(IS-IS).
3.1. Part 1: RSVP signalling and reliability extensions
The RSVP signalling extensions are defined in [MPLS-RSVP].
The following RSVP signalling extensions are supported:
- Shared Explicit (SE) Style reservations
- Processing received Fixed Filter (FF) Style reservations
- Handling Label objects in Resv messages
- Handling Label Request object:
* in Frame LSRs, without label range
* in ATM-LSRs, with ATM label range
- Explicit Route Object, with Strict and Loose IPv4 Prefix
Subobjects (Other subobjects propagated only.)
- Need not be able to add subobjects to ERO
- RRO
- Loop Detection
- Sender Template Object
- Filter Specification Object
Rosen, et al. [Page 6]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
- Reroute Procedure
- Session Attribute Object
This Part also includes the RSVP reliability extensions from [RSVP-
RFSH]. It does NOT, however, include the use of Bundle message or
the procedures for refresh reduction.
This Part also includes support for the Controlled Load Service
[CLOAD].
This Part also includes support for the Hello Protocol.
3.2. Part 2: IGP extensions for constraint-based routing
Part 2 has two variants: OSPF extensions and IS-IS extensions. Part
2(OSPF) is described in [TE-OSPF]. Part 2(IS-IS) is described in
[TE-ISIS]. A system may support either or both of these. Of course,
a system which supports only Part 2(IS-IS) will not be very useful in
an environment where OSPF is the routing algorithm.
3.3. Part 3: RSVP Refresh Reduction
An implementation which supports Part 3 supports [RSVP-RFSH] in its
entirety, with the exception that bundle messages are never
generated.
4. Profile BGP: BGP Label Distribution
The procedures for BGP label distribution are described in [MPLS-
BGP].
Profile BGP is really a family of profiles, one for each
pair. LSRs are not expected to support any of these profiles unless
they are intended to support an application which requires it.
When it is stated that a particular implementation supports Profile
BGP, AFI/SAFI pairs for which BGP label distribution is supported
must be specified.
As an example, systems which support the BGP/MPLS style of VPN
described in RFC 2745 should support Profile BGP with AFI=1 and
SAFI=128.
This Profile should generally be supported along with either Profile
Rosen, et al. [Page 7]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
HH or Profile TE/RSVP or both. If a system supports only Profile
BGP, it will only be able to distribute labels to BGP peers that are
directly adjacent to it, and this has very little utility.
5. References
[CLOAD] "Specification of the Controlled-Load Network Element
Service", RFC 2211, September 1997.
[MPLS-BGP] "Carrying Label Information in BGP-4", draft-ietf-mpls-
bgp4-mpls-04.txt, 1/00
[MPLS-LDP] "LDP Specification", draft-ietf-mpls-ldp-06.txt, 10/99
[MPLS-RSVP], "Extensions to RSVP for LSP Tunnels", Awduche, Berger,
Gan, Li, Swallow, Srinivasan, draft-ietf-mpls-rsvp-lsp-tunnel-04.txt,
9/99
[RSVP-RFSH], "RSVP Refresh Overhead Reduction Extensions", Berger,
Gan, Swallow, Pan, Tommasi, Molendini, draft-ietf-rsvp-refresh-
reduct-02.txt, 1/00
[TE-OSPF] "Traffic Engineering Extensions to OSPF", Katz, Yeung
draft-katz-yeung-ospf-traffic-01.txt, 10/99
[TE-ISIS] "IS-IS Extensions for Traffic Engineering",Smit, Li draft-
ietf-isis-traffic-01.txt, 6/99
6. Authors' Addresses
Eric C. Rosen
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: erosen@cisco.com
Bob Thomas
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: rhthomas@cisco.com
Rosen, et al. [Page 8]
Internet Draft draft-rosen-mpls-profiles-00.txt March 2000
Lance Levine
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: llevine@cisco.com
Carol Iturralde
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: cei@cisco.com
George Swallow
Cisco Systems, Inc.
250 Apollo Drive
Chelmsford, MA, 01824
E-mail: swallow@cisco.com
Rosen, et al. [Page 9]