Request for Comments: 4124 Cisco Systems, Inc.
Category: Standards Track June 2005
Protocol Extensions for Support of
Diffserv-aware MPLS Traffic Engineering
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document specifies the protocol extensions for support of
Diffserv-aware MPLS Traffic Engineering (DS-TE). This includes
generalization of the semantics of a number of Interior Gateway
Protocol (IGP) extensions already defined for existing MPLS Traffic
Engineering in RFC 3630, RFC 3784, and additional IGP extensions
beyond those. This also includes extensions to RSVP-TE signaling
beyond those already specified in RFC 3209 for existing MPLS Traffic
Engineering. These extensions address the requirements for DS-TE
spelled out in RFC 3564.
Table of Contents
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
2. Contributing Authors ............................................4
3. Definitions .....................................................5
4. Configurable Parameters .........................................5
4.1. Link Parameters ............................................5
4.1.1. Bandwidth Constraints (BCs) .........................5
4.1.2. Overbooking .........................................6
4.2. LSR Parameters .............................................7
4.2.1. TE-Class Mapping ....................................7
4.3. LSP Parameters .............................................8
4.3.1. Class-Type ..........................................8
4.3.2. Setup and Holding Preemption Priorities .............8
4.3.3. Class-Type/Preemption Relationship ..................8
4.4. Examples of Parameters Configuration .......................9
4.4.1. Example 1 ...........................................9
4.4.2. Example 2 ...........................................9
4.4.3. Example 3 ..........................................10
4.4.4. Example 4 ..........................................11
4.4.5. Example 5 ..........................................11
5. IGP Extensions for DS-TE .......................................12
5.1. Bandwidth Constraints .....................................12
5.2. Unreserved Bandwidth ......................................14
6. RSVP-TE Extensions for DS-TE ...................................15
6.1. DS-TE-Related RSVP Messages Format ........................15
6.1.1. Path Message Format ................................16
6.2. CLASSTYPE Object ..........................................16
6.2.1. CLASSTYPE object ...................................16
6.3. Handling CLASSTYPE Object .................................17
6.4. Non-support of the CLASSTYPE Object .......................20
6.5. Error Codes for Diffserv-aware TE .........................20
7. DS-TE Support with MPLS Extensions .............................21
7.1. DS-TE Support and References to Preemption Priority .......22
7.2. DS-TE Support and References to Maximum Reservable
Bandwidth .................................................22
8. Constraint-Based Routing .......................................22
9. Diffserv Scheduling ............................................23
10. Existing TE as a Particular Case of DS-TE .....................23
11. Computing "Unreserved TE-Class [i]" and Admission
Control Rules .................................................23
11.1. Computing "Unreserved TE-Class [i]" .....................23
11.2. Admission Control Rules .................................24
12. Security Considerations .......................................24
13. IANA Considerations ...........................................25
13.1. A New Name Space for Bandwidth Constraints Model
Identifiers .............................................25
13.2. A New Name Space for Error Values under the
"Diffserv-aware TE ......................................25
13.3. Assignments Made in This Document .......................26
13.3.1. Bandwidth Constraints sub-TLV for
OSPF Version 2 ..................................26
13.3.2. Bandwidth Constraints sub-TLV for ISIS ..........26
13.3.3. CLASSTYPE Object for RSVP .......................26
13.3.4. "Diffserv-aware TE Error" Error Code ............27
13.3.5. Error Values for "Diffserv-aware TE Error" ......27
14. Acknowledgements ..............................................28
Appendix A: Prediction for Multiple Path Computation ..............29
Appendix B: Solution Evaluation ...................................29
Appendix C: Interoperability with non DS-TE capable LSRs ..........31
Normative References ..............................................34
Informative References ............................................35
1. Introduction
[DSTE-REQ] presents the Service Provider requirements for support of
Differentiated-Service (Diffserv)-aware MPLS Traffic Engineering
(DS-TE). This includes the fundamental requirement to be able to
enforce different bandwidth constraints for different classes of
traffic.
This document specifies the IGP and RSVP-TE signaling extensions
(beyond those already specified for existing MPLS Traffic Engineering
[OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements
spelled out in [DSTE-REQ] including environments relying on
distributed Constraint-Based Routing (e.g., path computation
involving head-end Label Switching Routers).
[DSTE-REQ] provides a definition and examples of Bandwidth
Constraints models. The present document does not specify nor assume
a particular Bandwidth Constraints model. Specific Bandwidth
Constraints models are outside the scope of this document. Although
the extensions for DS-TE specified in this document may not be
sufficient to support all the conceivable Bandwidth Constraints
models, they do support the Russian Dolls Model specified in
[DSTE-RDM], the Maximum Allocation Model specified in [DSTE-MAM], and
the Maximum Allocation with Reservation Model specified in
[DSTE-MAR].
There may be differences between the quality of service expressed and
obtained with Diffserv without DS-TE and with DS-TE. Because DS-TE
uses Constraint-Based Routing, and because of the type of admission
control capabilities it adds to Diffserv, DS-TE has capabilities for
traffic that Diffserv does not: Diffserv does not indicate
preemption, by intent, whereas DS-TE describes multiple levels of
preemption for its Class-Types. Also, Diffserv does not support any
means of explicitly controlling overbooking, while DS-TE allows this.
When considering a complete quality of service environment, with
Diffserv routers and DS-TE, it is important to consider these
differences carefully.
1.1. Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Contributing Authors
This document was the collective work of several authors. The text
and content were contributed by the editor and the co-authors listed
below. (The contact information for the editor appears in the
Editor’s Address section.)
Jim Boyle Kireeti Kompella
Protocol Driven Networks, Inc. Juniper Networks, Inc.
1381 Kildaire Farm Road #288 1194 N. Mathilda Ave.
Cary, NC 27511, USA Sunnyvale, CA 94099
Phone: (919) 852-5160 EMail: kireeti@juniper.net
EMail: jboyle@pdnets.com
William Townsend Thomas D. Nadeau
Tenor Networks Cisco Systems, Inc.
100 Nagog Park 250 Apollo Drive
Acton, MA 01720 Chelmsford, MA 01824
Phone: +1-978-264-4900 Phone: +1-978-244-3051
EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Darek Skalecki
Nortel Networks
3500 Carling Ave,
Nepean K2H 8E9
Phone: +1-613-765-2252
EMail: dareks@nortelnetworks.com
3. Definitions
For readability, a number of definitions from [DSTE-REQ] are repeated
here:
Traffic Trunk: an aggregation of traffic flows of the same class
(i.e., treated equivalently from the DS-TE
perspective), which is placed inside a Label
Switched Path (LSP).
Class-Type (CT): the set of Traffic Trunks crossing a link that is
governed by a specific set of bandwidth constraints.
CT is used for the purposes of link bandwidth
allocation, constraint-based routing and admission
control. A given Traffic Trunk belongs to the same
CT on all links.
TE-Class: A pair of:
i. a Class-Type
ii. a preemption priority allowed for that Class-
Type. This means that an LSP transporting a Traffic
Trunk from that Class-Type can use that preemption
priority as the setup priority, the holding
priority, or both.
Definitions for a number of MPLS terms are not repeated here. They
can be found in [MPLS-ARCH].
4. Configurable Parameters
This section only discusses the differences with the configurable
parameters supported for MPLS Traffic Engineering as per [TE-REQ],
[ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are
unchanged.
4.1. Link Parameters
4.1.1. Bandwidth Constraints (BCs)
[DSTE-REQ] states that "Regardless of the Bandwidth Constraints
Model, the DS-TE solution MUST allow support for up to 8 BCs."
For DS-TE, the existing "Maximum Reservable link bandwidth" parameter
is retained, but its semantics is generalized and interpreted as the
aggregate bandwidth constraint across all Class-Types, so that,
independently of the Bandwidth Constraints Model in use:
SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
where the SUM is across all values of "c" in the range 0 <= c <= 7.
Additionally, on every link, a DS-TE implementation MUST provide for
configuration of up to 8 additional link parameters which are the
eight potential BCs, i.e., BC0, BC1, ... BC7. The LSR MUST interpret
these BCs in accordance with the supported Bandwidth Constraints
Model (i.e., what BC applies to what Class-Type, and how).
Where the Bandwidth Constraints Model imposes some relationship among
the values to be configured for these BCs, the LSR MUST enforce those
at configuration time. For example, when the Russian Dolls Bandwidth
Constraints Model ([DSTE-RDM]) is used, the LSR MUST ensure that BCi
is configured smaller than or equal to BCj, where i is greater than
j, and ensure that BC0 is equal to the Maximum Reservable Bandwidth.
As another example, when the Maximum Allocation Model ([DSTE-MAM]) is
used, the LSR MUST ensure that all BCi are configured smaller or
equal to the Maximum Reservable Bandwidth.
4.1.2. Overbooking
DS-TE enables a network administrator to apply different overbooking
(or underbooking) ratios for different CTs.
The principal methods to achieve this are the same as those
historically used in existing TE deployment:
(i) To take into account the overbooking/underbooking ratio
appropriate for the Ordered Aggregate (OA) or CT associated
with the considered LSP at the time of establishing the
bandwidth size of a given LSP. We refer to this method as the
"LSP Size Overbooking" method. AND/OR
(ii) To take into account the overbooking/underbooking ratio at the
time of configuring the Maximum Reservable Bandwidth/BCs and
use values that are larger (overbooking) or smaller
(underbooking) than those actually supported by the link. We
refer to this method as the "Link Size Overbooking" method.
The "LSP Size Overbooking" and "Link Size Overbooking" methods are
expected to be sufficient in many DS-TE environments and require no
additional configurable parameters. Other overbooking methods may
involve such additional configurable parameters, but are beyond the
scope of this document.
4.2. LSR Parameters
4.2.1. TE-Class Mapping
In line with [DSTE-REQ], the preemption attributes defined in
[TE-REQ] are retained with DS-TE and applicable within, and across,
all CTs. The preemption attributes of setup priority and holding
priority retain existing semantics, and in particular these semantics
are not affected by the LSP CT. This means that if LSP1 contends
with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a higher
setup preemption priority (i.e., lower numerical priority value) than
LSP2 holding preemption priority, regardless of LSP1 CT and LSP2 CT.
DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the
Class-Type and preemption level are configured for each of (up to) 8
TE-Classes.
This mapping is referred to as :
TE-Class[i] <--> < CTc , preemption p >
where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
Two TE-Classes MUST NOT be identical (i.e., have both the same
Class-Type and the same preemption priority).
There are no other restrictions on how any of the 8 Class-Types can
be paired up with any of the 8 preemption priorities to form a TE-
Class. In particular, one given preemption priority can be paired up
with two (or more) different Class-Types to form two (or more) TE-
Classes. Similarly, one Class-Type can be paired up with two (or
more) different preemption priorities to form two (or more) TE-
Classes. Also, there is no mandatory ordering relationship between
the TE-Class index (i.e., "i" above) and the Class-Type (i.e., "c"
above) or the preemption priority (i.e., "p" above) of the TE-Class.
Where the network administrator uses less than 8 TE-Classes, the DS-
TE LSR MUST allow remaining ones to be configured as "Unused". Note
that configuring all the 8 TE-Classes as "Unused" effectively results
in disabling TE/DS-TE since no TE/DS-TE LSP can be established (nor
even configured, since as described in Section 4.3.3 below, the CT
and preemption priorities configured for an LSP MUST form one of the
configured TE-Classes).
To ensure coherent DS-TE operation, the network administrator MUST
configure exactly the same TE-Class mapping on all LSRs of the DS-TE
domain.
When the TE-Class mapping needs to be modified in the DS-TE domain,
care ought to be exercised during the transient period of
reconfiguration during which some DS-TE LSRs may be configured with
the new TE-Class mapping while others are still configured with the
old TE-Class mapping. It is recommended that active tunnels do not
use any of the TE-Classes that are being modified during such a
transient reconfiguration period.
4.3. LSP Parameters
4.3.1. Class-Type
With DS-TE, LSRs MUST support, for every LSP, an additional
configurable parameter that indicates the Class-Type of the Traffic
Trunk transported by the LSP.
There is one and only one Class-Type configured per LSP.
The configured Class-Type indicates, in accordance with the supported
Bandwidth Constraints Model, the BCs that MUST be enforced for that
LSP.
4.3.2. Setup and Holding Preemption Priorities
As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be
configured with a setup and holding priority, each with a value
between 0 and 7.
4.3.3. Class-Type/Preemption Relationship
With DS-TE, the preemption priority configured for the setup priority
of a given LSP and the Class-Type configured for that LSP MUST be
such that, together, they form one of the (up to) 8 TE-Classes
configured in the TE-Class mapping specified in Section 4.2.1 above.
The preemption priority configured for the holding priority of a
given LSP and the Class-Type configured for that LSP MUST also be
such that, together, they form one of the (up to) 8 TE-Classes
configured in the TE-Class mapping specified in Section 4.2.1 above.
The LSR MUST enforce these two rules at configuration time.
4.4. Examples of Parameters Configuration
For illustration purposes, we now present a few examples of how these
configurable parameters may be used. All these examples assume that
different BCs need to be enforced for different sets of Traffic
Trunks (e.g., for Voice and for Data) so that two or more Class-Types
need to be used.
4.4.1. Example 1
The network administrator of a first network using two CTs (CT1 for
Voice and CT0 for Data) may elect to configure the following TE-Class
mapping to ensure that Voice LSPs are never driven away from their
shortest path because of Data LSPs:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7
Voice LSPs would then be configured with:
CT = CT1, setup priority = 0, holding priority = 0
Data LSPs would then be configured with:
CT = CT0, setup priority = 1, holding priority = 1
A new Voice LSP would then be able to preempt an existing Data LSP in
case they contend for resources. A Data LSP would never preempt a
Voice LSP. A Voice LSP would never preempt another Voice LSP. A
Data LSP would never preempt another Data LSP.
4.4.2. Example 2
The network administrator of another network may elect to configure
the following TE-Class mapping in order to optimize global network
resource utilization by favoring placement of large LSPs closer to
their shortest path:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[2] <--> < CT1 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 1, holding priority = 1
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 2, holding priority = 2
Small-size Data LSPs could be configured with:
CT = CT0, setup priority = 3, holding priority = 3
A new large-size Voice LSP would then be able to preempt a small-size
Voice LSP or any Data LSP in case they contend for resources. A new
large-size Data LSP would then be able to preempt a small-size Data
LSP or a small-size Voice LSP in case they contend for resources, but
it would not be able to preempt a large-size Voice LSP.
4.4.3. Example 3
The network administrator of another network may elect to configure
the following TE-Class mapping in order to ensure that Voice LSPs are
never driven away from their shortest path because of Data LSPs.
This also achieves some optimization of global network resource
utilization by favoring placement of large LSPs closer to their
shortest path:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7
Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0.
Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 1, holding priority = 1.
Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 2, holding priority = 2.
Small-size Data LSPs could be configured with:
CT=CT0, setup priority = 3, holding priority = 3.
A Voice LSP could preempt a Data LSP if they contend for resources.
A Data LSP would never preempt a Voice LSP. A large-size Voice LSP
could preempt a small-size Voice LSP if they contend for resources.
A large-size Data LSP could preempt a small-size Data LSP if they
contend for resources.
4.4.4. Example 4
The network administrator of another network may elect to configure
the following TE-Class mapping in order to ensure that no preemption
occurs in the DS-TE domain:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 0 >
TE-Class[i] <--> unused, for 2 <= i <= 7
Voice LSPs would then be configured with:
CT = CT1, setup priority =0, holding priority = 0
Data LSPs would then be configured with:
CT = CT0, setup priority = 0, holding priority = 0
No LSP would then be able to preempt any other LSP.
4.4.5. Example 5
The network administrator of another network may elect to configure
the following TE-Class mapping in view of increased network stability
through a more limited use of preemption:
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 1 >
TE-Class[3] <--> < CT0 , preemption 2 >
TE-Class[i] <--> unused, for 4 <= i <= 7
Large-size Voice LSPs could be configured with: CT = CT1, setup
priority = 0, holding priority = 0.
Small-size Voice LSPs could be configured with: CT = CT1, setup
priority = 1, holding priority = 0.
Large-size Data LSPs could be configured with: CT = CT0, setup
priority = 2, holding priority = 1.
Small-size Data LSPs could be configured with: CT = CT0, setup
priority = 2, holding priority = 2.
A new large-size Voice LSP would be able to preempt a Data LSP in
case they contend for resources, but it would not be able to preempt
any Voice LSP even a small-size Voice LSP.
A new small-size Voice LSP would be able to preempt a small-size Data
LSP in case they contend for resources, but it would not be able to
preempt a large-size Data LSP or any Voice LSP.
A Data LSP would not be able to preempt any other LSP.
5. IGP Extensions for DS-TE
This section only discusses the differences with the IGP
advertisement supported for (aggregate) MPLS Traffic Engineering as
per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is
unchanged.
5.1. Bandwidth Constraints
As detailed above in Section 4.1.1, up to 8 BCs (BCb, 0 <= b <= 7)
are configurable on any given link.
With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV
([OSPF-TE], [ISIS-TE]) is retained with a generalized semantics so