< draft-ietf-tewg-diff-te-proto-07.txt   draft-ietf-tewg-diff-te-proto-08.txt >
TEWG TEWG
Internet Draft Francois Le Faucheur Internet Draft Francois Le Faucheur
Editor Editor
Document: draft-ietf-tewg-diff-te-proto-07.txt Cisco Systems, Document: draft-ietf-tewg-diff-te-proto-08.txt Cisco Systems,
Inc. Inc.
Expires: September 20024 March 2004 Expires: June 2005 December 2004
Protocol extensions for support of Protocol extensions for support of
Differentiated-Service-aware MPLS Traffic Engineering Differentiated-Service-aware MPLS Traffic Engineering
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. Internet-Drafts are of section 3 of RFC 3667. By submitting this Internet-Draft, each
Working documents of the Internet Engineering Task Force (IETF), its author represents that any applicable patent or other IPR claims of
areas, and its working groups. Note that other groups may also which he or she is aware have been or will be disclosed, and any of
distribute working documents as Internet-Drafts. which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 13, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document specifies the protocol extensions for support of This document specifies the protocol extensions for support of
Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This Differentiated-Service-aware MPLS Traffic Engineering (DS-TE). This
includes generalization of the semantic of a number of IGP extensions includes generalization of the semantic of a number of IGP extensions
Protocols for Diffserv-aware TE December 2004
already defined for existing MPLS Traffic Engineering in RFC3630 and already defined for existing MPLS Traffic Engineering in RFC3630 and
RFC-TBD as well as additional IGP extensions beyond those. This also RFC-TBD as well as additional IGP extensions beyond those. This also
includes extensions to RSVP-TE signaling beyond those already includes extensions to RSVP-TE signaling beyond those already
specified in RFC3209 for existing MPLS Traffic Engineering. These specified in RFC3209 for existing MPLS Traffic Engineering. These
extensions address the Requirements for DS-TE spelt out in RFC3564. extensions address the Requirements for DS-TE spelt out in RFC3564.
<RFC-Editor-note> To be removed by the RFC editor at the time of <RFC-Editor-note> To be removed by the RFC editor at the time of
publication: Please replace "TBD" above by the actual RFC publication: Please replace "TBD" above by the actual RFC
number when number when
Protocols for Diffserv-aware TE March 2004
an RFC number is allocated to [ISIS-TE] an RFC number is allocated to [ISIS-TE]
</RFC-Editor-note> </RFC-Editor-note>
Specification of Requirements Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction...................................................3 1. Introduction...................................................3
2. Contributing Authors...........................................4 2. Contributing Authors...........................................4
3. Definitions....................................................4 3. Definitions....................................................5
4. Configurable Parameters........................................5 4. Configurable Parameters........................................5
4.1.1. Link Parameters 5 4.1. Link Parameters...........................................5
4.1.2. Bandwidth Constraints (BCs) 5 4.1.1. Bandwidth Constraints (BCs) 5
4.1.3. Overbooking6 4.1.2. Overbooking6
4.2. LSR Parameters............................................6 4.2. LSR Parameters............................................6
4.2.1. TE-Class Mapping 6 4.2.1. TE-Class Mapping 7
4.3. LSP Parameters............................................7 4.3. LSP Parameters............................................8
4.3.1. Class-Type 7 4.3.1. Class-Type 8
4.3.2. Setup and Holding Preemption Priorities 8 4.3.2. Setup and Holding Preemption Priorities 8
4.3.3. Class-Type/Preemption Relationship 8 4.3.3. Class-Type/Preemption Relationship 8
4.4. Examples of Parameters Configuration......................8 4.4. Examples of Parameters Configuration......................8
4.4.1. Example 1 8 4.4.1. Example 1 8
4.4.2. Example 2 9 4.4.2. Example 2 9
4.4.3. Example 3 9 4.4.3. Example 3 10
4.4.4. Example 4 10 4.4.4. Example 4 10
4.4.5. Example 5 10 4.4.5. Example 5 11
5. IGP Extensions for DS-TE......................................11 5. IGP Extensions for DS-TE......................................11
5.1. Bandwidth Constraints....................................11 5.1. Bandwidth Constraints....................................11
5.2. Unreserved Bandwidth.....................................13 5.2. Unreserved Bandwidth.....................................14
6. RSVP-TE Extensions for DS-TE..................................14 6. RSVP-TE Extensions for DS-TE..................................15
6.1. DS-TE related RSVP Messages Format.......................15 6.1. DS-TE related RSVP Messages Format.......................15
6.1.1. Path Message Format 15 6.1.1. Path Message Format 15
6.2. CLASSTYPE Object.........................................15 6.2. CLASSTYPE Object.........................................16
6.2.1. CLASSTYPE object 16 6.2.1. CLASSTYPE object 16
6.3. Handling CLASSTYPE Object................................16 6.3. Handling CLASSTYPE Object................................16
6.4. Non-support of the CLASSTYPE Object......................19 6.4. Non-support of the CLASSTYPE Object......................19
Protocols for Diffserv-aware TE December 2004
6.5. Error Codes For Diff-Serv-aware TE.......................19 6.5. Error Codes For Diff-Serv-aware TE.......................19
7. DS-TE support with MPLS extensions............................20 7. DS-TE support with MPLS extensions............................20
7.1. DS-TE support and references to preemption priority......20 7.1. DS-TE support and references to preemption priority......21
7.2. DS-TE support and references to Maximum Reservable Bandwidth 7.2. DS-TE support and references to Maximum Reservable Bandwidth
..............................................................20 ..............................................................21
8. Constraint Based Routing......................................21 8. Constraint Based Routing......................................21
9. Diff-Serv scheduling..........................................21 9. Diff-Serv scheduling..........................................22
10. Existing TE as a Particular Case of DS-TE....................21 10. Existing TE as a Particular Case of DS-TE....................22
Protocols for Diffserv-aware TE March 2004
11. Computing "Unreserved TE-Class [i]" and Admission Control Rules22 11. Computing "Unreserved TE-Class [i]" and Admission Control Rules22
11.1. Computing "Unreserved TE-Class [i]".....................22 11.1. Computing "Unreserved TE-Class [i]".....................23
11.2. Admission Control Rules.................................23 11.2. Admission Control Rules.................................23
12. Security Considerations......................................23 12. Security Considerations......................................24
13. Acknowledgments..............................................23 13. Acknowledgments..............................................24
14. IANA Considerations..........................................24 14. IANA Considerations..........................................24
14.1. A new name space for Bandwidth Constraints Model Identifiers 14.1. A new name space for Bandwidth Constraints Model Identifiers
..............................................................24 ..............................................................24
14.2. A new name space for Error Values under the "Diff-Serv-aware 14.2. A new name space for Error Values under the "Diff-Serv-aware
TE Error".....................................................24 TE Error".....................................................24
14.3. Assignments made in this Document.......................24 14.3. Assignments made in this Document.......................25
14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 24 14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 25
14.3.2. Bandwidth Constraints sub-TLV for ISIS 25 14.3.2. Bandwidth Constraints sub-TLV for ISIS 25
14.3.3. CLASSTYPE object for RSVP25 14.3.3. CLASSTYPE object for RSVP26
14.3.4. "Diff-Serv-aware TE Error" Error Code26 14.3.4. "Diff-Serv-aware TE Error" Error Code26
14.3.5. Error Values for "Diff-Serv-aware TE Error"26 14.3.5. Error Values for "Diff-Serv-aware TE Error"26
15. Intellectual Property Considerations.........................27 15. Intellectual Property Considerations.........................27
16. Normative References.........................................27 16. Normative References.........................................28
17. Informative References.......................................28 17. Informative References.......................................28
18. Editor's Address:............................................28 18. Editor's Address:............................................29
19. Full Copyright Statement.....................................29 19. Full Copyright Statement.....................................29
Appendix A - Prediction for Multiple Path Computation............29 Appendix A - Prediction for Multiple Path Computation............30
Appendix B - Solution Evaluation.................................30 Appendix B - Solution Evaluation.................................31
Appendix C - Interoperability with non DS-TE capable LSRs........32 Appendix C - Interoperability with non DS-TE capable LSRs........32
Disclaimer of Validity...........................................35
Copyright Statement..............................................35
Acknowledgment...................................................35
1. Introduction 1.Introduction
[DSTE-REQ] presents the Service Providers requirements for support of [DSTE-REQ] presents the Service Providers requirements for support of
Differentiated-Service (Diff-Serv)-aware MPLS Traffic Engineering Differentiated-Service (Diff-Serv)-aware MPLS Traffic Engineering
(DS-TE). This includes the fundamental requirement to be able to (DS-TE). This includes the fundamental requirement to be able to
enforce different bandwidth constraints for different classes of enforce different bandwidth constraints for different classes of
traffic. traffic.
This document specifies the IGP and RSVP-TE signaling extensions This document specifies the IGP and RSVP-TE signaling extensions
(beyond those already specified for existing MPLS Traffic Engineering (beyond those already specified for existing MPLS Traffic Engineering
[OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements [OSPF-TE][ISIS-TE][RSVP-TE]) for support of the DS-TE requirements
spelt out in [DSTE-REQ] including environments relying on distributed spelled out in [DSTE-REQ] including environments relying on
Constraint Based Routing (e.g. path computation involving Head-end
LSRs). Protocols for Diffserv-aware TE December 2004
distributed Constraint Based Routing (e.g. path computation involving
Head-end LSRs).
[DSTE-REQ] provides a definition and examples of Bandwidth [DSTE-REQ] provides a definition and examples of Bandwidth
Constraints Models. The present document does not specify nor assume Constraints Models. The present document does not specify nor assume
a particular Bandwidth Constraints model. Specific Bandwidth a particular Bandwidth Constraints model. Specific Bandwidth
Constraints model are outside the scope of this document. While the Constraints model are outside the scope of this document. While the
extensions for DS-TE specified in this document may not be sufficient extensions for DS-TE specified in this document may not be sufficient
to support all the conceivable Bandwidth Constraints models, they do to support all the conceivable Bandwidth Constraints models, they do
support the "Russian Dolls" Model specified in [DSTE-RDM], the support the "Russian Dolls" Model specified in [DSTE-RDM], the
Protocols for Diffserv-aware TE March 2004
"Maximum Allocation" Model specified in [DSTE-MAM] and the "Maximum "Maximum Allocation" Model specified in [DSTE-MAM] and the "Maximum
Allocation with Reservation" Model specified in [DSTE-MAR]. Allocation with Reservation" Model specified in [DSTE-MAR].
2. Contributing Authors 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.
2.Contributing Authors
This document was the collective work of several. The text and This document was the collective work of several. The text and
content of this document was contributed by the editor and the co- content of this document was contributed by the editor and the co-
authors listed below. (The contact information for the editor appears authors listed below. (The contact information for the editor appears
in Section 18, and is not repeated below.) in Section 18, and is not repeated below.)
Jim Boyle Kireeti Kompella Jim Boyle Kireeti Kompella
Protocol Driven Networks, Inc. Juniper Networks, Inc. Protocol Driven Networks, Inc. Juniper Networks, Inc.
1381 Kildaire Farm Road #288 1194 N. Mathilda Ave. 1381 Kildaire Farm Road #288 1194 N. Mathilda Ave.
Cary, NC 27511, USA Sunnyvale, CA 94099 Cary, NC 27511, USA Sunnyvale, CA 94099
skipping to change at page 4, line 34 skipping to change at page 5, line 4
William Townsend Thomas D. Nadeau William Townsend Thomas D. Nadeau
Tenor Networks Cisco Systems, Inc. Tenor Networks Cisco Systems, Inc.
100 Nagog Park 250 Apollo Drive 100 Nagog Park 250 Apollo Drive
Acton, MA 01720 Chelmsford, MA 01824 Acton, MA 01720 Chelmsford, MA 01824
Phone: +1-978-264-4900 Phone: +1-978-244-3051 Phone: +1-978-264-4900 Phone: +1-978-244-3051
Email: Email: tnadeau@cisco.com Email: Email: tnadeau@cisco.com
btownsend@tenornetworks.com btownsend@tenornetworks.com
Darek Skalecki Darek Skalecki
Nortel Networks Nortel Networks
Protocols for Diffserv-aware TE December 2004
3500 Carling Ave, 3500 Carling Ave,
Nepean K2H 8E9 Nepean K2H 8E9
Phone: +1-613-765-2252 Phone: +1-613-765-2252
Email: dareks@nortelnetworks.com Email: dareks@nortelnetworks.com
3. Definitions 3.Definitions
For readability a number of definitions from [DSTE-REQ] are repeated For readability a number of definitions from [DSTE-REQ] are repeated
here: here:
Traffic Trunk: an aggregation of traffic flows of the same class Traffic Trunk: an aggregation of traffic flows of the same class
[i.e. which are to be treated equivalently from the DS-TE [i.e. which are to be treated equivalently from the DS-TE
perspective] which are placed inside a Label Switched Path. perspective] which are placed inside a Label Switched Path.
Class-Type (CT): the set of Traffic Trunks crossing a link that is 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 governed by a specific set of Bandwidth constraints. CT is used for
the purposes of link bandwidth allocation, constraint based routing the purposes of link bandwidth allocation, constraint based routing
and admission control. A given Traffic Trunk belongs to the same CT and admission control. A given Traffic Trunk belongs to the same CT
on all links. on all links.
Protocols for Diffserv-aware TE March 2004
TE-Class: A pair of: TE-Class: A pair of:
i. a Class-Type i. a Class-Type
ii. a preemption priority allowed for that Class-Type. This ii. a preemption priority allowed for that Class-Type. This
means that an LSP transporting a Traffic Trunk from means that an LSP transporting a Traffic Trunk from
that Class-Type can use that preemption priority as the that Class-Type can use that preemption priority as the
set-up priority, as the holding priority or both. set-up priority, as the holding priority or both.
Definitions for a number of MPLS terms are not repeated here. Those Definitions for a number of MPLS terms are not repeated here. Those
can be found in [MPLS-ARCH]. can be found in [MPLS-ARCH].
4. Configurable Parameters 4.Configurable Parameters
This section only discusses the differences with the configurable This section only discusses the differences with the configurable
parameters supported for MPLS Traffic Engineering as per [TE-REQ], parameters supported for MPLS Traffic Engineering as per [TE-REQ],
[ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are [ISIS-TE], [OSPF-TE], and [RSVP-TE]. All other parameters are
unchanged. unchanged.
4.1.1. Link Parameters 4.1.Link Parameters
4.1.2. Bandwidth Constraints (BCs) 4.1.1.Bandwidth Constraints (BCs)
[DSTE-REQ] states that "Regardless of the Bandwidth Constraints [DSTE-REQ] states that "Regardless of the Bandwidth Constraints
Model, the DS-TE solution MUST allow support for up to 8 BCs." Model, the DS-TE solution MUST allow support for up to 8 BCs."
For DS-TE, the existing "Maximum Reservable link bandwidth" parameter For DS-TE, the existing "Maximum Reservable link bandwidth" parameter
is retained but its semantic is generalized and interpreted as the is retained but its semantic is generalized and interpreted as the
Protocols for Diffserv-aware TE December 2004
aggregate bandwidth constraints across all Class-Types, so that, aggregate bandwidth constraints across all Class-Types, so that,
independently of the Bandwidth Constraints Model in use: independently of the Bandwidth Constraints Model in use:
SUM (Reserved (CTc)) <= Max Reservable Bandwidth, SUM (Reserved (CTc)) <= Max Reservable Bandwidth,
where the SUM is across all values of "c" in the range 0 <= c <= 7. 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 Additionally, on every link, a DS-TE implementation MUST provide for
configuration of up to 8 additional link parameters which are the configuration of up to 8 additional link parameters which are the
eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The eight potential Bandwidth Constraints i.e. BC0, BC1 , ... BC7. The
LSR MUST interpret these Bandwidth Constraints in accordance with the LSR MUST interpret these Bandwidth Constraints in accordance with the
supported Bandwidth Constraints Model (i.e. what bandwidth constraint supported Bandwidth Constraints Model (i.e. what bandwidth constraint
applies to what Class-Type and how). applies to what Class-Type and how).
Where the Bandwidth Constraints Model imposes some relationship among Where the Bandwidth Constraints Model imposes some relationship among
the values to be configured for these Bandwidth Constraints, the LSR the values to be configured for these Bandwidth Constraints, the LSR
MUST enforce those at configuration time. For example, when the MUST enforce those at configuration time. For example, when the
"Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the "Russian Doll" Bandwidth Constraints Model ([DSTE-RDM]) is used, the
LSR must ensure that BCi is configured smaller or equal to BCj, where LSR MUST ensure that BCi is configured smaller or equal to BCj, where
i is greater than j, and ensure that BC0 is equal to the Maximum i is greater than j, and ensure that BC0 is equal to the Maximum
Reservable Bandwidth. As another example, when the Maximum Allocation Reservable Bandwidth. As another example, when the Maximum Allocation
Model ([DSTE-MAM]) is used, the LSR must ensure that all BCi are Model ([DSTE-MAM]) is used, the LSR MUST ensure that all BCi are
configured smaller or equal to the Maximum Reservable Bandwidth. configured smaller or equal to the Maximum Reservable Bandwidth.
Protocols for Diffserv-aware TE March 2004 4.1.2.Overbooking
4.1.3. Overbooking
DS-TE enables a network administrator to apply different overbooking DS-TE enables a network administrator to apply different overbooking
(or underbooking) ratios for different CTs. (or underbooking) ratios for different CTs.
The principal methods to achieve this are the same as historically The principal methods to achieve this are the same as historically
used in existing TE deployment, which are : used in existing TE deployment, which are :
(i) To take into account the overbooking/underbooking ratio (i) To take into account the overbooking/underbooking ratio
appropriate for the OA/CT associated with the considered LSP appropriate for the OA/CT associated with the considered LSP
at the time of establishing the bandwidth size of a given at the time of establishing the bandwidth size of a given
LSP. We refer to this method as the "LSP Size Overbooking LSP. We refer to this method as the "LSP Size Overbooking
skipping to change at page 6, line 32 skipping to change at page 6, line 54
larger(overbooking) or smaller(underbooking) than actually larger(overbooking) or smaller(underbooking) than actually
supported by the link. We refer to this method as the "Link supported by the link. We refer to this method as the "Link
Size Overbooking method". Size Overbooking method".
The "LSP Size Overbooking" method and the "Link Size Overbooking" The "LSP Size Overbooking" method and the "Link Size Overbooking"
method are expected to be sufficient in many DS-TE environments and method are expected to be sufficient in many DS-TE environments and
require no additional configurable parameters. Other overbooking require no additional configurable parameters. Other overbooking
methods may involve such additional configurable parameters but are methods may involve such additional configurable parameters but are
beyond the scope of this document. beyond the scope of this document.
4.2. LSR Parameters 4.2.LSR Parameters
4.2.1. TE-Class Mapping Protocols for Diffserv-aware TE December 2004
4.2.1.TE-Class Mapping
In line with [DSTE-REQ], the preemption attributes defined in [TE- In line with [DSTE-REQ], the preemption attributes defined in [TE-
REQ] are retained with DS-TE and applicable within, and across, all REQ] are retained with DS-TE and applicable within, and across, all
Class Types. The preemption attributes of setup priority and holding Class Types. The preemption attributes of setup priority and holding
priority retain existing semantics, and in particular these semantics priority retain existing semantics, and in particular these semantics
are not affected by the LSP Class Type. This means that if LSP1 are not affected by the LSP Class Type. This means that if LSP1
contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a contends with LSP2 for resources, LSP1 may preempt LSP2 if LSP1 has a
higher set-up preemption priority (i.e. lower numerical priority higher set-up preemption priority (i.e. lower numerical priority
value) than LSP2 holding preemption priority regardless of LSP1 CT value) than LSP2 holding preemption priority regardless of LSP1 CT
and LSP2 CT. and LSP2 CT.
skipping to change at page 7, line 5 skipping to change at page 7, line 29
DS-TE LSRs MUST allow configuration of a TE-Class mapping whereby the 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 Class-Type and preemption level are configured for each of (up to) 8
TE-Classes. TE-Classes.
This mapping is referred to as : This mapping is referred to as :
TE-Class[i] <--> < CTc , preemption p > TE-Class[i] <--> < CTc , preemption p >
Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7 Where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7
Protocols for Diffserv-aware TE March 2004 Two TE-Classes MUST NOT be identical (i.e. have both the same Class-
Two TE-Classes must not be identical (i.e. have both the same Class-
Type and the same preemption priority). Type and the same preemption priority).
There are no other restrictions on how any of the 8 Class-Types can 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- 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 class. In particular, one given preemption priority can be paired up
with two (or more) different Class-Types to form two (or more) TE- 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 classes. Similarly, one Class-Type can be paired up with two (or
more) different preemption priorities to form two (or more) TE- more) different preemption priorities to form two (or more) TE-
Classes. Also, there is no mandatory ordering relationship between Classes. Also, there is no mandatory ordering relationship between
the TE-Class index (i.e. "i" above) and the Class-Type (i.e. "c" 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. 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- Where the network administrator uses less than 8 TE-Classes, the DS-
TE LSR MUST allow remaining ones to be configured as "Unused". Note TE LSR MUST allow remaining ones to be configured as "Unused". Note
that "Configuring all the 8 TE-Classes as "Unused" effectively that "Configuring all the 8 TE-Classes as "Unused" effectively
results in disabling TE/DS-TE since no TE/DS-TE LSP can be 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 established (nor even configured, since as described in section 4.3.3
below, the CT and preemption priorities configured for an LSP must below, the CT and preemption priorities configured for an LSP MUST
form one of the configured TE-Classes)". form one of the configured TE-Classes)".
To ensure coherent DS-TE operation, the network administrator MUST To ensure coherent DS-TE operation, the network administrator MUST
configure exactly the same TE-Class Mapping on all LSRs of the DS-TE configure exactly the same TE-Class Mapping on all LSRs of the DS-TE
domain. domain.
When the TE-class mapping needs to be modified in the DS-TE domain, When the TE-class mapping needs to be modified in the DS-TE domain,
care must be exercised during the transient period of reconfiguration care ought to be exercised during the transient period of
during which some DS-TE LSRs may be configured with the new TE-class reconfiguration during which some DS-TE LSRs may be configured with
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 which are being modified during such a transient
reconfiguration period.
4.3. LSP Parameters Protocols for Diffserv-aware TE December 2004
4.3.1. Class-Type 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 which 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 With DS-TE, LSRs MUST support, for every LSP, an additional
configurable parameter which indicates the Class-Type of the Traffic configurable parameter which indicates the Class-Type of the Traffic
Trunk transported by the LSP. Trunk transported by the LSP.
There is one and only one Class-Type configured per LSP. There is one and only one Class-Type configured per LSP.
The configured Class-Type indicates, in accordance with the supported The configured Class-Type indicates, in accordance with the supported
Bandwidth Constraints Model, the Bandwidth Constraints that MUST be Bandwidth Constraints Model, the Bandwidth Constraints that MUST be
enforced for that LSP. enforced for that LSP.
Protocols for Diffserv-aware TE March 2004 4.3.2.Setup and Holding Preemption Priorities
4.3.2. Setup and Holding Preemption Priorities
As per existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be 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 configured with a setup and holding priority, each with a value
between 0 and 7. between 0 and 7.
4.3.3. Class-Type/Preemption Relationship 4.3.3.Class-Type/Preemption Relationship
With DS-TE, the preemption priority configured for the setup priority 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 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 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. configured in the TE-Class Mapping specified in section 4.2.1 above.
The preemption priority configured for the holding priority of a The preemption priority configured for the holding priority of a
given LSP and the Class-Type configured for that LSP must also be 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 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. configured in the TE-Class Mapping specified in section 4.2.1 above.
The LSR MUST enforce these two rules at configuration time. The LSR MUST enforce these two rules at configuration time.
4.4. Examples of Parameters Configuration 4.4.Examples of Parameters Configuration
For illustrative purposes, we now present a few examples of how these For illustrative purposes, we now present a few examples of how these
configurable parameters may be used. All these examples assume that configurable parameters may be used. All these examples assume that
different bandwidth constraints need to be enforced for different different bandwidth constraints need to be enforced for different
sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or sets of Traffic Trunks (e.g. for Voice and for Data) so that two, or
more, Class-Types need to be used. more, Class-Types need to be used.
4.4.1. Example 1 4.4.1.Example 1
Protocols for Diffserv-aware TE December 2004
The Network Administrator of a first network using two Class Types The Network Administrator of a first network using two Class Types
(CT1 for Voice and CT0 for Data), may elect to configure the (CT1 for Voice and CT0 for Data), may elect to configure the
following TE-Class Mapping to ensure that Voice LSPs are never driven following TE-Class Mapping to ensure that Voice LSPs are never driven
away from their shortest path because of Data LSPs: away from their shortest path because of Data LSPs:
TE-Class[0] <--> < CT1 , preemption 0 > TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 > TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7 TE-Class[i] <--> unused, for 2 <= i <= 7
skipping to change at page 9, line 5 skipping to change at page 9, line 27
- CT=CT1, set-up priority =0, holding priority=0 - CT=CT1, set-up priority =0, holding priority=0
Data LSPs would then be configured with: Data LSPs would then be configured with:
- CT=CT0, set-up priority =1, holding priority=1 - CT=CT0, set-up priority =1, holding priority=1
A new Voice LSP would then be able to preempt an existing Data LSP in 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 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 Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data
LSP would never preempt another Data LSP. LSP would never preempt another Data LSP.
Protocols for Diffserv-aware TE March 2004 4.4.2.Example 2
4.4.2. Example 2
The Network Administrator of another network may elect to configure The Network Administrator of another network may elect to configure
the following TE-Class Mapping in order to optimize global network the following TE-Class Mapping in order to optimize global network
resource utilization by favoring placement of large LSPs closer to resource utilization by favoring placement of large LSPs closer to
their shortest path: their shortest path:
TE-Class[0] <--> < CT1 , preemption 0 > TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 > TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[2] <--> < CT1 , preemption 2 > TE-Class[2] <--> < CT1 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 > TE-Class[3] <--> < CT0 , preemption 3 >
skipping to change at page 9, line 36 skipping to change at page 10, line 4
Small size Voice LSPs could be configured with: Small size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 2, holding priority=2 - CT=CT1, set-up priority = 2, holding priority=2
Small size Data LSPs could be configured with: Small size Data LSPs could be configured with:
- CT=CT0, set-up priority = 3, holding priority=3. - CT=CT0, set-up priority = 3, holding priority=3.
A new large size Voice LSP would then be able to preempt a small size 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. 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 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 Data LSP or a small size Voice LSP in case they contend for
Protocols for Diffserv-aware TE December 2004
resources, but it would not be able to preempt a large size Voice resources, but it would not be able to preempt a large size Voice
LSP. LSP.
4.4.3. Example 3 4.4.3.Example 3
The Network Administrator of another network may elect to configure The Network Administrator of another network may elect to configure
the following TE-Class Mapping in order to ensure that Voice LSPs are the following TE-Class Mapping in order to ensure that Voice LSPs are
never driven away from their shortest path because of Data LSPs while never driven away from their shortest path because of Data LSPs while
also achieving some optimization of global network resource also achieving some optimization of global network resource
utilization by favoring placement of large LSPs closer to their utilization by favoring placement of large LSPs closer to their
shortest path: shortest path:
TE-Class[0] <--> < CT1 , preemption 0 > TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 > TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 2 > TE-Class[2] <--> < CT0 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 > TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7 TE-Class[i] <--> unused, for 4 <= i <= 7
Large size Voice LSPs could be configured with: Large size Voice LSPs could be configured with:
Protocols for Diffserv-aware TE March 2004
- CT=CT1, set-up priority = 0, holding priority=0. - CT=CT1, set-up priority = 0, holding priority=0.
Small size Voice LSPs could be configured with: Small size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 1, holding priority=1. - CT=CT1, set-up priority = 1, holding priority=1.
Large size Data LSPs could be configured with: Large size Data LSPs could be configured with:
- CT=CT0, set-up priority = 2, holding priority=2. - CT=CT0, set-up priority = 2, holding priority=2.
Small size Data LSPs could be configured with: Small size Data LSPs could be configured with:
- CT=CT0, set-up priority = 3, holding priority=3. - CT=CT0, set-up priority = 3, holding priority=3.
A Voice LSP could preempt a Data LSP if they contend for resources. A 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 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 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 Large size Data LSP could preempt a small size Data LSP if they
contend for resources. contend for resources.
4.4.4. Example 4 4.4.4.Example 4
The Network Administrator of another network may elect to configure The Network Administrator of another network may elect to configure
the following TE-Class Mapping in order to ensure that no preemption the following TE-Class Mapping in order to ensure that no preemption
occurs in the DS-TE domain: occurs in the DS-TE domain:
TE-Class[0] <--> < CT1 , preemption 0 > TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 0 > TE-Class[1] <--> < CT0 , preemption 0 >
TE-Class[i] <--> unused, for 2 <= i <= 7 TE-Class[i] <--> unused, for 2 <= i <= 7
Voice LSPs would then be configured with: Voice LSPs would then be configured with:
- CT=CT1, set-up priority =0, holding priority=0 - CT=CT1, set-up priority =0, holding priority=0
Data LSPs would then be configured with: Data LSPs would then be configured with:
Protocols for Diffserv-aware TE December 2004
- CT=CT0, set-up priority =0, holding priority=0 - CT=CT0, set-up priority =0, holding priority=0
No LSP would then be able to preempt any other LSP. No LSP would then be able to preempt any other LSP.
4.4.5. Example 5 4.4.5.Example 5
The Network Administrator of another network may elect to configure The Network Administrator of another network may elect to configure
the following TE-Class Mapping in view of increased network stability the following TE-Class Mapping in view of increased network stability
through a more limited use of preemption: through a more limited use of preemption:
TE-Class[0] <--> < CT1 , preemption 0 > TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 > TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 1 > TE-Class[2] <--> < CT0 , preemption 1 >
TE-Class[3] <--> < CT0 , preemption 2 > TE-Class[3] <--> < CT0 , preemption 2 >
TE-Class[i] <--> unused, for 4 <= i <= 7 TE-Class[i] <--> unused, for 4 <= i <= 7
Large size Voice LSPs could be configured with: Large size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 0, holding priority=0. - CT=CT1, set-up priority = 0, holding priority=0.
Protocols for Diffserv-aware TE March 2004
Small size Voice LSPs could be configured with: Small size Voice LSPs could be configured with:
- CT=CT1, set-up priority = 1, holding priority=0. - CT=CT1, set-up priority = 1, holding priority=0.
Large size Data LSPs could be configured with: Large size Data LSPs could be configured with:
- CT=CT0, set-up priority = 2, holding priority=1. - CT=CT0, set-up priority = 2, holding priority=1.
Small size Data LSPs could be configured with: Small size Data LSPs could be configured with:
- CT=CT0, set-up priority = 2, holding priority=2. - CT=CT0, set-up priority = 2, holding priority=2.
A new large size Voice LSP would be able to preempt a Data LSP in 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 case they contend for resources, but it would not be able to preempt
any Voice LSP even a small size Voice LSP. any Voice LSP even a small size Voice LSP.
A new small size Voice LSP would be able to preempt a small size Data 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 LSP in case they contend for resources, but it would not be able to
preempt a large size Data LSP or any Voice LSP. preempt a large size Data LSP or any Voice LSP.
A Data LSP would not be able to preempt any other LSP. A Data LSP would not be able to preempt any other LSP.
5. IGP Extensions for DS-TE 5.IGP Extensions for DS-TE
This section only discusses the differences with the IGP This section only discusses the differences with the IGP
advertisement supported for (aggregate) MPLS Traffic Engineering as advertisement supported for (aggregate) MPLS Traffic Engineering as
per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is per [OSPF-TE] and [ISIS-TE]. The rest of the IGP advertisement is
unchanged. unchanged.
5.1. Bandwidth Constraints 5.1.Bandwidth Constraints
As detailed above in section 4.1.1, up to 8 Bandwidth Constraints As detailed above in section 4.1.1, up to 8 Bandwidth Constraints
( BCb, 0 <= b <= 7) are configurable on any given link. ( BCb, 0 <= b <= 7) are configurable on any given link.
Protocols for Diffserv-aware TE December 2004
With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV
([OSPF-TE], [ISIS-TE]) is retained with a generalized semantic so ([OSPF-TE], [ISIS-TE]) is retained with a generalized semantic so
that it MUST now be interpreted as the aggregate bandwidth constraint that it MUST now be interpreted as the aggregate bandwidth constraint
across all Class-Types [ i.e. across all Class-Types [ i.e.
SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of SUM (Reserved (CTc)) <= Max Reservable Bandwidth], independently of
the Bandwidth Constraints Model. the Bandwidth Constraints Model.
This document also defines the following new optional sub-TLV to This document also defines the following new optional sub-TLV to
advertise the eight potential Bandwidth Constraints (BC0 to BC7): advertise the eight potential Bandwidth Constraints (BC0 to BC7):
"Bandwidth Constraints" sub-TLV: "Bandwidth Constraints" sub-TLV:
- Bandwidth Constraints Model Id (1 octet) - Bandwidth Constraints Model Id (1 octet)
- Reserved (3 octets) - Reserved (3 octets)
- Bandwidth Constraints (Nx4 octets) - Bandwidth Constraints (Nx4 octets)
Where: Where:
Protocols for Diffserv-aware TE March 2004
- With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its - With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its
sub-TLV type is TBD sub-TLV type is TBD
- With ISIS, the sub-TLV is a sub-TLV of the "extended IS - With ISIS, the sub-TLV is a sub-TLV of the "extended IS
reachability TLV" and its sub-TLV type is TBD (). reachability TLV" and its sub-TLV type is TBD ().
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the sub-TLV numbers are allocated by IANA publication: When the sub-TLV numbers are allocated by IANA
for OSPF and ISIS, replace "TBD" in the two bullet points above by for OSPF and ISIS, replace "TBD" in the two bullet points above by
the respective assigned value. See IANA Considerations section for the respective assigned value. See IANA Considerations section for
skipping to change at page 12, line 38 skipping to change at page 13, line 5
- Bandwidth Constraints: contains BC0, BC1,... BC(N-1). - Bandwidth Constraints: contains BC0, BC1,... BC(N-1).
Each Bandwidth Constraint is encoded on 32 bits in IEEE Each Bandwidth Constraint is encoded on 32 bits in IEEE
floating point format. The units are bytes (not bits!) per floating point format. The units are bytes (not bits!) per
second. Where the configured TE-class mapping and the second. Where the configured TE-class mapping and the
Bandwidth Constraints model in use are such that BCh+1, Bandwidth Constraints model in use are such that BCh+1,
BCh+2, ...and BC7 are not relevant to any of the Class-Types BCh+2, ...and BC7 are not relevant to any of the Class-Types
associated with a configured TE-class, it is RECOMMENDED that associated with a configured TE-class, it is RECOMMENDED that
only the Bandwidth Constraints from BC0 to BCh be advertised, only the Bandwidth Constraints from BC0 to BCh be advertised,
in order to minimize the impact on IGP scalability. in order to minimize the impact on IGP scalability.
Protocols for Diffserv-aware TE December 2004
All relevant generic TLV encoding rules (including TLV format, All relevant generic TLV encoding rules (including TLV format,
padding and alignment, as well as IEEE floating point format padding and alignment, as well as IEEE floating point format
encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this encoding) defined in [OSPF-TE] and [ISIS-TE] are applicable to this
new sub-TLV. new sub-TLV.
The "Bandwidth Constraints" sub-TLV format is illustrated below: The "Bandwidth Constraints" sub-TLV format is illustrated below:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved | | BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value | | BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . // // . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value | | BCh value |
Protocols for Diffserv-aware TE March 2004
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A DS-TE LSR MAY optionally advertise Bandwidth Constraints. A DS-TE LSR MAY optionally advertise Bandwidth Constraints.
A DS-TE LSR which does advertise Bandwidth Constraints MUST use the A DS-TE LSR which does advertise Bandwidth Constraints MUST use the
new "Bandwidth Constraints" sub-TLV (in addition to the existing new "Bandwidth Constraints" sub-TLV (in addition to the existing
Maximum Reservable Bandwidth sub-TLV) to do so. For example, Maximum Reservable Bandwidth sub-TLV) to do so. For example,
considering the case where a Service Provider deploys DS-TE with considering the case where a Service Provider deploys DS-TE with
TE-classes associated with CT0 and CT1 only, and where the Bandwidth TE-classes associated with CT0 and CT1 only, and where the Bandwidth
Constraints Model is such that only BC0 and BC1 are relevant to CT0 Constraints Model is such that only BC0 and BC1 are relevant to CT0
skipping to change at page 13, line 39 skipping to change at page 14, line 5
Model designated by the Bandwidth Constraints Model Id, or if the DS- Model designated by the Bandwidth Constraints Model Id, or if the DS-
TE LSR does not support operations with multiple simultaneous TE LSR does not support operations with multiple simultaneous
Bandwidth Constraints Models, the DS-TE LSR MAY discard the Bandwidth Constraints Models, the DS-TE LSR MAY discard the
corresponding TLV. If the DS-TE LSR does support the Bandwidth corresponding TLV. If the DS-TE LSR does support the Bandwidth
Constraints Model designated by the Bandwidth Constraints Model Id Constraints Model designated by the Bandwidth Constraints Model Id
and if the DS-TE LSR does support operations with multiple and if the DS-TE LSR does support operations with multiple
simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY accept
the corresponding TLV and allow operations with different Bandwidth the corresponding TLV and allow operations with different Bandwidth
Constraints Models used in different parts of the DS-TE domain. Constraints Models used in different parts of the DS-TE domain.
5.2. Unreserved Bandwidth Protocols for Diffserv-aware TE December 2004
5.2.Unreserved Bandwidth
With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is retained
as the only vehicle to advertise dynamic bandwidth information as the only vehicle to advertise dynamic bandwidth information
necessary for Constraint Based Routing on Head-ends, except that it necessary for Constraint Based Routing on Head-ends, except that it
is used with a generalized semantic. The Unreserved Bandwidth sub-TLV is used with a generalized semantic. The Unreserved Bandwidth sub-TLV
still carries eight bandwidth values but they now correspond to the still carries eight bandwidth values but they now correspond to the
unreserved bandwidth for each of the TE-Class (instead of for each unreserved bandwidth for each of the TE-Class (instead of for each
preemption priority as per existing TE). preemption priority as per existing TE).
More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth
sub-TLV with a definition which is generalized into the following: sub-TLV with a definition which is generalized into the following:
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth
not yet reserved for each of the eight TE-classes, in IEEE floating not yet reserved for each of the eight TE-classes, in IEEE floating
point format arranged in increasing order of TE-Class index, with point format arranged in increasing order of TE-Class index, with
Protocols for Diffserv-aware TE March 2004
unreserved bandwidth for TE-Class [0] occurring at the start of the unreserved bandwidth for TE-Class [0] occurring at the start of the
sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the sub-TLV, and unreserved bandwidth for TE-Class [7] at the end of the
sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <= sub-TLV. The unreserved bandwidth value for TE-Class [i] ( 0 <= i <=
7) is referred to as "Unreserved TE-Class [i]". It indicates the 7) is referred to as "Unreserved TE-Class [i]". It indicates the
bandwidth that is available, for reservation, to an LSP which : bandwidth that is available, for reservation, to an LSP which :
- transports a Traffic Trunk from the Class-Type of TE- - transports a Traffic Trunk from the Class-Type of TE-
Class[i], and Class[i], and
- has a setup priority corresponding to the preemption priority - has a setup priority corresponding to the preemption priority
of TE-Class[i]. of TE-Class[i].
skipping to change at page 14, line 42 skipping to change at page 15, line 5
If i < j , then any of the following relationship may be true If i < j , then any of the following relationship may be true
"Unreserved TE-Class [i]" = "Unreserved TE-Class [j]" "Unreserved TE-Class [i]" = "Unreserved TE-Class [j]"
OR OR
"Unreserved TE-Class [i]" > "Unreserved TE-Class [j]" "Unreserved TE-Class [i]" > "Unreserved TE-Class [j]"
OR OR
"Unreserved TE-Class [i]" < "Unreserved TE-Class [j]". "Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".
Rules for computing "Unreserved TE-Class [i]" are specified in Rules for computing "Unreserved TE-Class [i]" are specified in
section 11. section 11.
Protocols for Diffserv-aware TE December 2004
If TE-Class[i] is unused, the value advertised by the IGP in If TE-Class[i] is unused, the value advertised by the IGP in
"Unreserved TE-Class [i]" MUST be set to zero by the LSR generating "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating
the IGP advertisement, and MUST be ignored by the LSR receiving the the IGP advertisement, and MUST be ignored by the LSR receiving the
IGP advertisement. IGP advertisement.
6. RSVP-TE Extensions for DS-TE 6.RSVP-TE Extensions for DS-TE
In this section we describe extensions to RSVP-TE for support of In this section we describe extensions to RSVP-TE for support of
Diff-Serv-aware MPLS Traffic Engineering. These extensions are in Diff-Serv-aware MPLS Traffic Engineering. These extensions are in
addition to the extensions to RSVP defined in [RSVP-TE] for support addition to the extensions to RSVP defined in [RSVP-TE] for support
of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP of (aggregate) MPLS Traffic Engineering and to the extensions to RSVP
defined in [DIFF-MPLS] for support of Diff-Serv over MPLS. defined in [DIFF-MPLS] for support of Diff-Serv over MPLS.
Protocols for Diffserv-aware TE March 2004 6.1.DS-TE related RSVP Messages Format
6.1. DS-TE related RSVP Messages Format
One new RSVP Object is defined in this document: the CLASSTYPE One new RSVP Object is defined in this document: the CLASSTYPE
Object. Detailed description of this Object is provided below. This Object. Detailed description of this Object is provided below. This
new Object is applicable to Path messages. This specification only new Object is applicable to Path messages. This specification only
defines the use of the CLASSTYPE Object in Path messages used to defines the use of the CLASSTYPE Object in Path messages used to
establish LSP Tunnels in accordance with [RSVP-TE] and thus establish LSP Tunnels in accordance with [RSVP-TE] and thus
containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 containing a Session Object with a C-Type equal to LSP_TUNNEL_IPv4
and containing a LABEL_REQUEST object. and containing a LABEL_REQUEST object.
Restrictions defined in [RSVP-TE] for support of establishment of LSP Restrictions defined in [RSVP-TE] for support of establishment of LSP
Tunnels via RSVP-TE are also applicable to the establishment of LSP Tunnels via RSVP-TE are also applicable to the establishment of LSP
Tunnels supporting DS-TE. For instance, only unicast LSPs are Tunnels supporting DS-TE. For instance, only unicast LSPs are
supported and Multicast LSPs are for further study. supported and Multicast LSPs are for further study.
This new CLASSTYPE object is optional with respect to RSVP so that This new CLASSTYPE object is optional with respect to RSVP so that
general RSVP implementations not concerned with MPLS LSP set up do general RSVP implementations not concerned with MPLS LSP set up do
not have to support this object. not have to support this object.
An LSR supporting DS-TE MUST support the CLASSTYPE Object. An LSR supporting DS-TE MUST support the CLASSTYPE Object.
6.1.1. Path Message Format 6.1.1.Path Message Format
The format of the Path message is as follows: The format of the Path message is as follows:
<Path Message> ::= <Common Header> [ <INTEGRITY> ] <Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP> <SESSION> <RSVP_HOP>
<TIME_VALUES> <TIME_VALUES>
[ <EXPLICIT_ROUTE> ] [ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST> <LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ] [ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ] [ <DIFFSERV> ]
[ <CLASSTYPE> ] [ <CLASSTYPE> ]
[ <POLICY_DATA> ... ] [ <POLICY_DATA> ... ]
[ <sender descriptor> ] [ <sender descriptor> ]
Protocols for Diffserv-aware TE December 2004
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ] <sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ] [ <ADSPEC> ]
[ <RECORD_ROUTE> ] [ <RECORD_ROUTE> ]
6.2. CLASSTYPE Object 6.2.CLASSTYPE Object
The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is The CLASSTYPE object Class Name is CLASSTYPE. Its Class Number is
TBD. Currently, there is only one defined C_Type which is C_Type 1. TBD. Currently, there is only one defined C_Type which is C_Type 1.
The CLASSTYPE object format is shown below. The CLASSTYPE object format is shown below.
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the RSVP Class-Num is assigned by IANA publication: When the RSVP Class-Num is assigned by IANA
replace "TBD" replace "TBD"
Protocols for Diffserv-aware TE March 2004
above by the assigned value. See IANA Considerations section above by the assigned value. See IANA Considerations section
for allocation request. for allocation request.
</IANA-note> </IANA-note>
6.2.1. CLASSTYPE object 6.2.1.CLASSTYPE object
Class Number = TBD Class Number = TBD
Class Type = 1 Class Type = 1
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the RSVP Class Number is assigned by IANA publication: When the RSVP Class Number is assigned by IANA
replace "TBD" replace "TBD"
above by the assigned value. See IANA Considerations section above by the assigned value. See IANA Considerations section
for allocation request. for allocation request.
</IANA-note> </IANA-note>
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT | | Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved : 29 bits Reserved : 29 bits
This field is reserved. It must be set to zero on transmission This field is reserved. It MUST be set to zero on transmission
and must be ignored on receipt. and MUST be ignored on receipt.
CT : 3 bits CT : 3 bits
Indicates the Class-Type. Values currently allowed are Indicates the Class-Type. Values currently allowed are
1, 2, ... , 7. Value of 0 is Reserved. 1, 2, ... , 7. Value of 0 is Reserved.
6.3. Handling CLASSTYPE Object 6.3.Handling CLASSTYPE Object
To establish an LSP tunnel with RSVP, the sender LSR creates a Path To establish an LSP tunnel with RSVP, the sender LSR creates a Path
message with a session type of LSP_Tunnel_IPv4 and with a message with a session type of LSP_Tunnel_IPv4 and with a
Protocols for Diffserv-aware TE December 2004
LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also LABEL_REQUEST object as per [RSVP-TE]. The sender LSR may also
include the DIFFSERV object as per [DIFF-MPLS]. include the DIFFSERV object as per [DIFF-MPLS].
If the LSP is associated with Class-Type 0, the sender LSR MUST NOT If the LSP is associated with Class-Type 0, the sender LSR MUST NOT
include the CLASSTYPE object in the Path message. This allows include the CLASSTYPE object in the Path message. This allows
backward compatibility with non-DSTE-configured or non-DSTE-capable backward compatibility with non-DSTE-configured or non-DSTE-capable
LSRs as discussed below in section 10 and Appendix C. LSRs as discussed below in section 10 and Appendix C.
If the LSP is associated with Class-Type N (1 <= N <=7), the sender If the LSP is associated with Class-Type N (1 <= N <=7), the sender
LSR MUST include the CLASSTYPE object in the Path message with the LSR MUST include the CLASSTYPE object in the Path message with the
Class-Type (CT) field set to N. Class-Type (CT) field set to N.
Protocols for Diffserv-aware TE March 2004
If a path message contains multiple CLASSTYPE objects, only the first If a path message contains multiple CLASSTYPE objects, only the first
one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and one is meaningful; subsequent CLASSTYPE object(s) MUST be ignored and
MUST NOT be forwarded. MUST NOT be forwarded.
Each LSR along the path MUST record the CLASSTYPE object, when Each LSR along the path MUST record the CLASSTYPE object, when
present, in its path state block. present, in its path state block.
If the CLASSTYPE object is not present in the Path message, the LSR If the CLASSTYPE object is not present in the Path message, the LSR
MUST associate the Class-Type 0 to the LSP. MUST associate the Class-Type 0 to the LSP.
skipping to change at page 17, line 45 skipping to change at page 18, line 4
- recognizes the CLASSTYPE object, but - recognizes the CLASSTYPE object, but
- does not support the particular Class-Type, - does not support the particular Class-Type,
MUST send a PathErr towards the sender with the error code "Diff- MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "Unsupported Class-Type". Serv-aware TE Error" and an error value of "Unsupported Class-Type".
Those are defined below in section 6.5. Those are defined below in section 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which: An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object, but - recognizes the CLASSTYPE object, but
- determines that the Class-Type value is not valid (i.e. - determines that the Class-Type value is not valid (i.e.
Class-Type value 0), Class-Type value 0),
Protocols for Diffserv-aware TE December 2004
MUST send a PathErr towards the sender with the error code "Diff- MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "Invalid Class-Type Serv-aware TE Error" and an error value of "Invalid Class-Type
value". Those are defined below in section 6.5. value". Those are defined below in section 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which: An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object, - recognizes the CLASSTYPE object,
- supports the particular Class-Type, but - supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and - determines that the tuple formed by (i) this Class-Type and
(ii) the set-up priority signaled in the same Path message, (ii) the set-up priority signaled in the same Path message,
is not one of the eight TE-classes configured in the TE-class is not one of the eight TE-classes configured in the TE-class
mapping, mapping,
Protocols for Diffserv-aware TE March 2004
MUST send a PathErr towards the sender with the error code "Diff- MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "CT and setup priority do Serv-aware TE Error" and an error value of "CT and setup priority do
not form a configured TE-Class". Those are defined below in section not form a configured TE-Class". Those are defined below in section
6.5. 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which: An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object, - recognizes the CLASSTYPE object,
- supports the particular Class-Type, but - supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and - determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message, (ii) the holding priority signaled in the same Path message,
is not one of the eight TE-classes configured in the TE-class is not one of the eight TE-classes configured in the TE-class
mapping, mapping,
MUST send a PathErr towards the sender with the error code "Diff- MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "CT and holding priority Serv-aware TE Error" and an error value of "CT and holding priority
do not form a configured TE-Class". Those are defined below in do not form a configured TE-Class". Those are defined below in
section 6.5. section 6.5.
An LSR receiving a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object,
- supports the particular Class-Type, but
- determines that the tuple formed by (i) this Class-Type and
(ii) the setup priority signaled in the same Path message,
is not one of the eight TE-classes configured in the TE-class
mapping, AND
- determines that the tuple formed by (i) this Class-Type and
(ii) the holding priority signaled in the same Path message,
is not one of the eight TE-classes configured in the TE-class
mapping
MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "CT and setup priority do
not form a configured TE-Class AND CT and holding priority do not
form a configured TE-Class". Those are defined below in section 6.5.
An LSR receiving a Path message with the CLASSTYPE object and with An LSR receiving a Path message with the CLASSTYPE object and with
the DIFFSERV object for an L-LSP, which: the DIFFSERV object for an L-LSP, which:
- recognizes the CLASSTYPE object, - recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types - has local knowledge of the relationship between Class-Types
and PSC (e.g. via configuration) and PSC (e.g. via configuration)
Protocols for Diffserv-aware TE December 2004
- based on this local knowledge, determines that the PSC - based on this local knowledge, determines that the PSC
signaled in the DIFFSERV object is inconsistent with the signaled in the DIFFSERV object is inconsistent with the
Class-Type signaled in the CLASSTYPE object, Class-Type signaled in the CLASSTYPE object,
MUST send a PathErr towards the sender with the error code "Diff- MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "Inconsistency between Serv-aware TE Error" and an error value of "Inconsistency between
signaled PSC and signaled CT". Those are defined below in section signaled PSC and signaled CT". Those are defined below in section
6.5. 6.5.
An LSR receiving a Path message with the CLASSTYPE object and with An LSR receiving a Path message with the CLASSTYPE object and with
the DIFFSERV object for an E-LSP, which: the DIFFSERV object for an E-LSP, which:
skipping to change at page 19, line 5 skipping to change at page 19, line 34
MUST send a PathErr towards the sender with the error code "Diff- MUST send a PathErr towards the sender with the error code "Diff-
Serv-aware TE Error" and an error value of "Inconsistency between Serv-aware TE Error" and an error value of "Inconsistency between
signaled PHBs and signaled CT". Those are defined below in section signaled PHBs and signaled CT". Those are defined below in section
6.5. 6.5.
An LSR MUST handle the situations where the LSP can not be accepted An LSR MUST handle the situations where the LSP can not be accepted
for other reasons than those already discussed in this section, in for other reasons than those already discussed in this section, in
accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is accordance with [RSVP-TE] and [DIFF-MPLS] (e.g. a reservation is
rejected by admission control, a label can not be associated). rejected by admission control, a label can not be associated).
Protocols for Diffserv-aware TE March 2004 6.4.Non-support of the CLASSTYPE Object
6.4. Non-support of the CLASSTYPE Object
An LSR that does not recognize the CLASSTYPE object Class-Num MUST An LSR that does not recognize the CLASSTYPE object Class-Num MUST
behave in accordance with the procedures specified in [RSVP] for an behave in accordance with the procedures specified in [RSVP] for an
unknown Class-Num whose format is 0bbbbbbb (i.e. it must send a unknown Class-Num whose format is 0bbbbbbb (i.e. it MUST send a
PathErr with the error code "Unknown object class" toward the PathErr with the error code "Unknown object class" toward the
sender). sender).
An LSR that recognizes the CLASSTYPE object Class-Num but does not An LSR that recognizes the CLASSTYPE object Class-Num but does not
recognize the CLASSTYPE object C-Type, MUST behave in accordance with recognize the CLASSTYPE object C-Type, MUST behave in accordance with
the procedures specified in [RSVP] for an unknown C-type (i.e. it the procedures specified in [RSVP] for an unknown C-type (i.e. it
must send a PathErr with the error code "Unknown object C-Type" MUST send a PathErr with the error code "Unknown object C-Type"
toward the sender). toward the sender).
In both situations, this causes the path set-up to fail. The sender In both situations, this causes the path set-up to fail. The sender
SHOULD notify the operator/management-system that an LSP cannot be SHOULD notify the operator/management-system that an LSP cannot be
established and possibly might take action to retry reservation established and possibly might take action to retry reservation
establishment without the CLASSTYPE object. establishment without the CLASSTYPE object.
6.5. Error Codes For Diff-Serv-aware TE 6.5.Error Codes For Diff-Serv-aware TE
In the procedures described above, certain errors must be reported as Protocols for Diffserv-aware TE December 2004
a "Diff-Serv-aware TE Error". The value of the "Diff-Serv-aware TE
Error" error code is (TBD)(). In the procedures described above, certain errors are reported as a
"Diff-Serv-aware TE Error". The value of the "Diff-Serv-aware TE
Error" error code is (TBD).
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the "Diff-Serv-aware TE Error" Error Code is publication: When the "Diff-Serv-aware TE Error" Error Code is
assigned by assigned by
IANA, replace "TBD" above by the assigned value. IANA, replace "TBD" above by the assigned value.
See IANA Considerations section for allocation request. See IANA Considerations section for allocation request.
</IANA-note> </IANA-note>
The following defines error values for the Diff-Serv-aware TE Error: The following defines error values for the Diff-Serv-aware TE Error:
Value Error Value Error
1 Unexpected CLASSTYPE object 1 Unexpected CLASSTYPE object
2 Unsupported Class-Type 2 Unsupported Class-Type
3 Invalid Class-Type value 3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured 4 Class-Type and setup priority do not form a configured
TE-Class TE-Class
5 Class-Type and holding priority do not form a 5 Class-Type and holding priority do not form a
configured TE-Class configured TE-Class
6 Inconsistency between signaled PSC and signaled 6 Class-Type and setup priority do not form a configured
TE-Class AND Class-Type and holding priority do not form
a configured TE-Class
7 Inconsistency between signaled PSC and signaled
Class-Type
8 Inconsistency between signaled PHBs and signaled
Class-Type Class-Type
7 Inconsistency between signaled PHBs and signaled
Class-Type
See the IANA Considerations section for allocation of additional See the IANA Considerations section for allocation of additional
Values. Values.
Protocols for Diffserv-aware TE March 2004 7.DS-TE support with MPLS extensions.
7. DS-TE support with MPLS extensions.
There are a number of extensions to the initial base specification There are a number of extensions to the initial base specification
for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE].
Those include enhancements for generalization [GMPLS-SIG] Those include enhancements for generalization ([GMPLS-SIG] and
[GMPLS-ROUTE], as well as for additional functionality such as LSP [GMPLS-ROUTE]), as well as for additional functionality such as LSP
hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration hierarchy [HIERARCHY], link bundling [BUNDLE] and fast restoration
[REROUTE]. These specifications may reference how to encode [REROUTE]. These specifications may reference how to encode
information associated with certain preemption priorities, how to information associated with certain preemption priorities, how to
treat LSPs at different preemption priorities, or otherwise specify treat LSPs at different preemption priorities, or otherwise specify
encodings or behavior that have a different meaning for an DS-TE encodings or behavior that have a different meaning for a DS-TE
router. router.
In order for an implementation to support both this specification for In order for an implementation to support both this specification for
Diff-Serv-aware TE and a given MPLS enhancement such as those listed Diff-Serv-aware TE and a given MPLS enhancement such as those listed
above (but not limited to those), it MUST treat references to above (but not limited to those), it MUST treat references to
Protocols for Diffserv-aware TE December 2004
"preemption priority" and to "Maximum Reservable Bandwidth" in a "preemption priority" and to "Maximum Reservable Bandwidth" in a
generalized manner, such as it is used in this specification. generalized manner, such as it is used in this specification.
Additionally, current and future MPLS enhancements may include more Additionally, current and future MPLS enhancements may include more
precise specification for how they interact with Diff-Serv-aware TE. precise specification for how they interact with Diff-Serv-aware TE.
7.1. DS-TE support and references to preemption priority 7.1.DS-TE support and references to preemption priority
When a router supports both Diff-Serv-aware TE and one of the MPLS When a router supports both Diff-Serv-aware TE and one of the MPLS
protocol extensions such as those mentioned above, encoding of values protocol extensions such as those mentioned above, encoding of values
of preemption priority in signaling or encoding of information of preemption priority in signaling or encoding of information
associated with preemption priorities in IGP defined for the MPLS associated with preemption priorities in IGP defined for the MPLS
extension, MUST be considered to be an encoding of the same extension, MUST be considered to be an encoding of the same
information for the corresponding TE-Class. For instance, if an MPLS information for the corresponding TE-Class. For instance, if an MPLS
enhancement specifies advertisement in IGP of a parameter for routing enhancement specifies advertisement in IGP of a parameter for routing
information at preemption priority N, in a DS-TE environment it MUST information at preemption priority N, in a DS-TE environment it MUST
actually be interpreted as specifying advertisement of the same actually be interpreted as specifying advertisement of the same
routing information but for TE-Class [N]. On receipt, DS-TE routers routing information but for TE-Class [N]. On receipt, DS-TE routers
MUST interpret it as such as well. MUST interpret it as such as well.
When there is discussion on how to comparatively treat LSPs of When there is discussion on how to comparatively treat LSPs of
different preemption priority, a DS-TE LSR MUST treat the preemption different preemption priority, a DS-TE LSR MUST treat the preemption
priorities in this context as the preemption priorities associated priorities in this context as the preemption priorities associated
with the TE-Classes of the LSPs in question. with the TE-Classes of the LSPs in question.
7.2. DS-TE support and references to Maximum Reservable Bandwidth 7.2.DS-TE support and references to Maximum Reservable Bandwidth
When a router supports both Diff-Serv-aware TE and MPLS protocol When a router supports both Diff-Serv-aware TE and MPLS protocol
extensions such as those mentioned above, advertisements of Maximum extensions such as those mentioned above, advertisements of Maximum
Reservable Bandwidth MUST be done with the generalized interpretation Reservable Bandwidth MUST be done with the generalized interpretation
defined above in section 4.1.1 as the aggregate bandwidth constraint defined above in section 4.1.1 as the aggregate bandwidth constraint
Protocols for Diffserv-aware TE March 2004
across all Class-Types and MAY also allow the optional advertisement across all Class-Types and MAY also allow the optional advertisement
of all Bandwidth Constraints. of all Bandwidth Constraints.
8. Constraint Based Routing 8.Constraint Based Routing
Let us consider the case where a path needs to be computed for an LSP Let us consider the case where a path needs to be computed for an LSP
whose Class-Type is configured to CTc and whose set-up preemption whose Class-Type is configured to CTc and whose set-up preemption
priority is configured to p. priority is configured to p.
Then the pair of CTc and p will map to one of the TE-Classes defined Then the pair of CTc and p will map to one of the TE-Classes defined
in the TE-Class mapping. Let us refer to this TE-Class as TE- in the TE-Class mapping. Let us refer to this TE-Class as TE-
Class[i]. Class[i].
The Constraint Based Routing algorithm of a DS-TE LSR is still only The Constraint Based Routing algorithm of a DS-TE LSR is still only
required to perform path computation satisfying a single bandwidth required to perform path computation satisfying a single bandwidth
constraint which is to fit in "Unreserved TE-Class [i]" as advertised constraint which is to fit in "Unreserved TE-Class [i]" as advertised
by the IGP for every link. Thus, no changes are required to the by the IGP for every link. Thus, no changes are required to the
existing TE Constraint Based Routing algorithm itself. existing TE Constraint Based Routing algorithm itself.
Protocols for Diffserv-aware TE December 2004
The Constraint Based Routing algorithm MAY also take into account, The Constraint Based Routing algorithm MAY also take into account,
when used, the optional additional information advertised in IGP such when used, the optional additional information advertised in IGP such
as the Bandwidth Constraints and the Maximum Reservable Bandwidth. As as the Bandwidth Constraints and the Maximum Reservable Bandwidth. As
an example, the Bandwidth Constraints MIGHT be used as a tie-breaker an example, the Bandwidth Constraints MIGHT be used as a tie-breaker
criteria in situations where multiple paths, otherwise equally criteria in situations where multiple paths, otherwise equally
attractive, are possible. attractive, are possible.
9. Diff-Serv scheduling 9.Diff-Serv scheduling
The Class-Type signaled at LSP establishment MAY optionally be used The Class-Type signaled at LSP establishment MAY optionally be used
by DS-TE LSRs to dynamically adjust the resources allocated to the by DS-TE LSRs to dynamically adjust the resources allocated to the
Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv Class-Type by the Diff-Serv scheduler. In addition, the Diff-Serv
information (i.e. the PSC) signaled by the TE-LSP signaling protocols information (i.e. the PSC) signaled by the TE-LSP signaling protocols
as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE
LSRs to dynamically adjust the resources allocated to a PSC/OA within LSRs to dynamically adjust the resources allocated to a PSC/OA within
a Class Type by the Diff-Serv scheduler. a Class Type by the Diff-Serv scheduler.
10. Existing TE as a Particular Case of DS-TE 10.Existing TE as a Particular Case of DS-TE
We observe that existing TE can be viewed as a particular case of We observe that existing TE can be viewed as a particular case of
DS-TE where: DS-TE where:
(i) a single Class-Type is used, (i) a single Class-Type is used,
(ii) all 8 preemption priorities are allowed for that Class- (ii) all 8 preemption priorities are allowed for that Class-
Type, and Type, and
(iii) the following TE-Class Mapping is used: (iii) the following TE-Class Mapping is used:
TE-Class[i] <--> < CT0 , preemption i > TE-Class[i] <--> < CT0 , preemption i >
Protocols for Diffserv-aware TE March 2004
Where 0 <= i <= 7. Where 0 <= i <= 7.
In that case, DS-TE behaves as existing TE. In that case, DS-TE behaves as existing TE.
As with existing TE, the IGP advertises: As with existing TE, the IGP advertises:
- Unreserved Bandwidth for each of the 8 preemption priorities - Unreserved Bandwidth for each of the 8 preemption priorities
As with existing TE, the IGP may advertise: As with existing TE, the IGP may advertise:
- Maximum Reservable Bandwidth containing a bandwidth - Maximum Reservable Bandwidth containing a bandwidth
constraint applying across all LSPs constraint applying across all LSPs
Since all LSPs transport traffic from CT0, RSVP-TE signaling is done Since all LSPs transport traffic from CT0, RSVP-TE signaling is done
without explicit signaling of the Class-Type (which is only used for without explicit signaling of the Class-Type (which is only used for
other Class-Types than CT0 as explained in section 6) as with other Class-Types than CT0 as explained in section 6) as with
existing TE. existing TE.
11. Computing "Unreserved TE-Class [i]" and Admission Control Rules 11.Computing "Unreserved TE-Class [i]" and Admission Control Rules
11.1. Computing "Unreserved TE-Class [i]" Protocols for Diffserv-aware TE December 2004
11.1.Computing "Unreserved TE-Class [i]"
We first observe that, for existing TE, details on admission control We first observe that, for existing TE, details on admission control
algorithms for TE LSPs, and consequently details on formulas for algorithms for TE LSPs, and consequently details on formulas for
computing the unreserved bandwidth, are outside the scope of the computing the unreserved bandwidth, are outside the scope of the
current IETF work. This is left for vendor differentiation. Note that current IETF work. This is left for vendor differentiation. Note that
this does not compromise interoperability across various this does not compromise interoperability across various
implementations since the TE schemes rely on LSRs to advertise their implementations since the TE schemes rely on LSRs to advertise their
local view of the world in terms of Unreserved Bw to other LSRs. This local view of the world in terms of Unreserved Bw to other LSRs. This
way, regardless of the actual local admission control algorithm used way, regardless of the actual local admission control algorithm used
on one given LSR, Constraint Based Routing on other LSRs can rely on on one given LSR, Constraint Based Routing on other LSRs can rely on
skipping to change at page 23, line 4 skipping to change at page 23, line 35
algorithms are left for vendor differentiation and formulas for algorithms are left for vendor differentiation and formulas for
computing the unreserved bandwidth for TE-Class[i] are outside the computing the unreserved bandwidth for TE-Class[i] are outside the
scope of this specification. However, DS-TE places the additional scope of this specification. However, DS-TE places the additional
requirement on the LSR that the unreserved bandwidth values requirement on the LSR that the unreserved bandwidth values
advertised MUST reflect all of the Bandwidth Constraints relevant to advertised MUST reflect all of the Bandwidth Constraints relevant to
the CT associated with TE-Class[i] in accordance with the Bandwidth the CT associated with TE-Class[i] in accordance with the Bandwidth
Constraints Model. Thus, formulas for computing "Unreserved TE-Class Constraints Model. Thus, formulas for computing "Unreserved TE-Class
[i]" depend on the Bandwidth Constraints Model in use and MUST [i]" depend on the Bandwidth Constraints Model in use and MUST
reflect how bandwidth constraints apply to CTs. Example formulas for reflect how bandwidth constraints apply to CTs. Example formulas for
computing "Unreserved TE-Class [i]" Model are provided for the computing "Unreserved TE-Class [i]" Model are provided for the
Protocols for Diffserv-aware TE March 2004
Russian Dolls Model and Maximum Allocation Model respectively in Russian Dolls Model and Maximum Allocation Model respectively in
[DSTE-RDM] and [DSTE-MAM]. [DSTE-RDM] and [DSTE-MAM].
As with existing TE, DS-TE LSRs MUST consider the holding preemption As with existing TE, DS-TE LSRs MUST consider the holding preemption
priority of established LSPs (as opposed to their set-up preemption priority of established LSPs (as opposed to their set-up preemption
priority) for the purpose of computing the unreserved bandwidth for priority) for the purpose of computing the unreserved bandwidth for
TE-Class [i]. TE-Class [i].
11.2. Admission Control Rules 11.2.Admission Control Rules
A DS-TE LSR MUST support the following admission control rule: A DS-TE LSR MUST support the following admission control rule:
Regardless of how the admission control algorithm actually computes Regardless of how the admission control algorithm actually computes
the unreserved bandwidth for TE-Class[i] for one of its local link, the unreserved bandwidth for TE-Class[i] for one of its local link,
an LSP of bandwidth B, of set-up preemption priority p and of Class- an LSP of bandwidth B, of set-up preemption priority p and of
Type CTc is admissible on that link if, and only if,: Class-Type CTc is admissible on that link if, and only if,:
B <= Unreserved Bandwidth for TE-Class[i] B <= Unreserved Bandwidth for TE-Class[i]
Where Where
Protocols for Diffserv-aware TE December 2004
- TE-Class [i] maps to < CTc , p > in the TE-Class mapping - TE-Class [i] maps to < CTc , p > in the TE-Class mapping
configured on the LSR. configured on the LSR.
12. Security Considerations 12.Security Considerations
This document does not introduce additional security threats beyond This document does not introduce additional security threats beyond
those described for Diff-Serv ([DIFF-ARCH]) and MPLS Traffic those described for Diff-Serv ([DIFF-ARCH]) and MPLS Traffic
Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]) and the same
security measures and procedures described in these documents apply security measures and procedures described in these documents apply
here. For example, the approach for defense against theft- and here. For example, the approach for defense against theft- and
denial-of-service attacks discussed in [DIFF-ARCH], which consists of denial-of-service attacks discussed in [DIFF-ARCH], which consists of
the combination of traffic conditioning at DS boundary nodes along the combination of traffic conditioning at DS boundary nodes along
with security and integrity of the network infrastructure within a with security and integrity of the network infrastructure within a
Diff-Serv domain, may be followed when DS-TE is in use. Also, as Diff-Serv domain, may be followed when DS-TE is in use. Also, as
stated in [TE-REQ], it is specifically important that manipulation of stated in [TE-REQ], it is specifically important that manipulation of
administratively configurable parameters (such as those related to administratively configurable parameters (such as those related to
DS-TE LSPs) be executed in a secure manner by authorized entities. DS-TE LSPs) be executed in a secure manner by authorized entities.
13. Acknowledgments 13.Acknowledgments
We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier We thank Martin Tatham, Angela Chiu and Pete Hicks for their earlier
contribution in this work. We also thank Sanjaya Choudhury for his contribution in this work. We also thank Sanjaya Choudhury for his
thorough review and suggestions. thorough review and suggestions.
Protocols for Diffserv-aware TE March 2004 14.IANA Considerations
14. IANA Considerations
This document creates two new name spaces which are to be managed by This document creates two new name spaces which are to be managed by
IANA. Also, a number of assignments from existing name spaces have IANA. Also, a number of assignments from existing name spaces have
been made by IANA in this document. Those are discussed below. been made by IANA in this document. Those are discussed below.
14.1. A new name space for Bandwidth Constraints Model Identifiers 14.1.A new name space for Bandwidth Constraints Model Identifiers
This document defines in section 5.1 a "Bandwidth Constraints Model This document defines in section 5.1 a "Bandwidth Constraints Model
Id" field (name space) within the "Bandwidth Constraints" sub-TLV, Id" field (name space) within the "Bandwidth Constraints" sub-TLV,
both for OSPF and ISIS. IANA is requested to create and maintain this both for OSPF and ISIS. IANA is requested to create and maintain this
new name space. The field for this namespace is 1 octet, and IANA new name space. The field for this namespace is 1 octet, and IANA
guidelines for assignments for this field are as follows: guidelines for assignments for this field are as follows:
o values in the range 0-127 are to be assigned according to o values in the range 0-239 are to be assigned according to
the "Specification Required" policy defined in [IANA-CONS]. the "Specification Required" policy defined in [IANA-CONS].
o values in the range 128-239 are not to be assigned at this o values in the range 240-255 are reserved for "Private Use" as
time. Before any assignments can be made in this range, there MUST be defined in [IANA-CONS].
a Standards Track RFC that specifies IANA Considerations that cover
assignment within that range.
o values in the range 240-255 are for experimental use; these
will not be registered with IANA, and MUST NOT be mentioned by RFCs.
14.2. A new name space for Error Values under the "Diff-Serv-aware TE 14.2.A new name space for Error Values under the "Diff-Serv-aware TE
Error" Error"
Protocols for Diffserv-aware TE December 2004
An Error Code is an 8-bit quantity defined in [RSVP] that appears in An Error Code is an 8-bit quantity defined in [RSVP] that appears in
an ERROR_SPEC object to broadly define an error condition. With each an ERROR_SPEC object to broadly define an error condition. With each
Error Code there may be a 16-bit Error Value (which depends on the Error Code there may be a 16-bit Error Value (which depends on the
Error Code) that further specifies the cause of the error. Error Code) that further specifies the cause of the error.
This document defines in section 6.5 a new RSVP error code, the This document defines in section 6.5 a new RSVP error code, the
"Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for
the "Diff-Serv-aware TE Error" constitute a new name space to be the "Diff-Serv-aware TE Error" constitute a new name space to be
managed by IANA. managed by IANA.
This document defines, in section 6.5, values 1 through 7 in that This document defines, in section 6.5, values 1 through 7 in that
name space (see section 14.3.5). name space (see section 14.3.5).
Future allocations of values in this name space are to be assigned by Future allocations of values in this name space are to be assigned by
IANA using the "Specification Required" policy defined in [IANA- IANA using the "Specification Required" policy defined in
CONS]. [IANA-CONS].
14.3. Assignments made in this Document
14.3.1. Bandwidth Constraints sub-TLV for OSPF version 2 14.3.Assignments made in this Document
Protocols for Diffserv-aware TE March 2004 14.3.1.Bandwidth Constraints sub-TLV for OSPF version 2
[OSPF-TE] creates a name space for the sub-TLV types within the "Link [OSPF-TE] creates a name space for the sub-TLV types within the "Link
TLV" of the Traffic Engineering LSA and rules for management of this TLV" of the Traffic Engineering LSA and rules for management of this
name space by IANA. name space by IANA.
This document defines in section 5.1 a new sub-TLV, the "Bandwidth This document defines in section 5.1 a new sub-TLV, the "Bandwidth
Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the Constraints" sub-TLV, for the OSPF "Link" TLV. In accordance with the
IANA considerations provided in [OSPF-TE], a sub-TLV type in the IANA considerations provided in [OSPF-TE], a sub-TLV type in the
range 10 to 32767 was requested and the value TBD has been assigned range 10 to 32767 was requested and the value TBD has been assigned
by IANA for the "Bandwidth Constraints" sub-TLV. by IANA for the "Bandwidth Constraints" sub-TLV.
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the sub-TLV Type is assigned by IANA replace publication:
"TBD" above When the sub-TLV Type is assigned by IANA replace "TBD" above by the
by the assigned value. assigned value.
</IANA-note> </IANA-note>
14.3.2. Bandwidth Constraints sub-TLV for ISIS
14.3.2.Bandwidth Constraints sub-TLV for ISIS
[ISIS-TE] creates a name space for the sub-TLV types within the ISIS [ISIS-TE] creates a name space for the sub-TLV types within the ISIS
"Extended IS Reachability" TLV and rules for management of this name "Extended IS Reachability" TLV and rules for management of this name
space by IANA. space by IANA.
This document defines in section 5.1 a new sub-TLV, the "Bandwidth This document defines in section 5.1 a new sub-TLV, the "Bandwidth
Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. In
accordance with the IANA considerations provided in [ISIS-TE], a sub- accordance with the IANA considerations provided in [ISIS-TE], a
TLV type was requested and the value TBD has been assigned by IANA sub-TLV type was requested and the value TBD has been assigned by
for the "Bandwidth Constraints" sub-TLV. IANA for the "Bandwidth Constraints" sub-TLV.
Protocols for Diffserv-aware TE December 2004
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the sub-TLV Type is assigned by IANA replace publication:
"TBD" above When the sub-TLV Type is assigned by IANA replace "TBD" above by the
by the assigned value. assigned value.
</IANA-note> </IANA-note>
14.3.3. CLASSTYPE object for RSVP
14.3.3.CLASSTYPE object for RSVP
[RSVP] defines the Class Number name space for RSVP object which is [RSVP] defines the Class Number name space for RSVP object which is
managed by IANA. Currently allocated Class Numbers are listed at managed by IANA. Currently allocated Class Numbers are listed at
"http://www.iana.org/assignments/rsvp-parameters" "http://www.iana.org/assignments/rsvp-parameters"
This document defines in section 6.2.1 a new RSVP object, the This document defines in section 6.2.1 a new RSVP object, the
CLASSTYPE object. IANA was requested to assign a Class Number for CLASSTYPE object. IANA was requested to assign a Class Number for
this RSVP object from the range defined in section 3.10 of [RSVP] for this RSVP object from the range defined in section 3.10 of [RSVP] for
those objects which, if not understood, cause the entire RSVP message those objects which, if not understood, cause the entire RSVP message
to be rejected with an error code of "Unknown Object Class". Such to be rejected with an error code of "Unknown Object Class". Such
objects are identified by a zero in the most significant bit of the objects are identified by a zero in the most significant bit of the
class number (i.e. class number (i.e.
Class-Num = 0bbbbbbb). Class-Num = 0bbbbbbb).
IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is IANA assigned Class-Number TBD to the CLASSTYPE object. C_Type 1 is
defined in this document for the CLASSTYPE object. defined in this document for the CLASSTYPE object.
Protocols for Diffserv-aware TE March 2004
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the RSVP Class-Num is assigned by IANA publication:
replace "TBD" When the RSVP Class-Num is assigned by IANA replace "TBD" above by
above by the assigned value. the assigned value.
</IANA-note> </IANA-note>
14.3.4. "Diff-Serv-aware TE Error" Error Code
14.3.4."Diff-Serv-aware TE Error" Error Code
[RSVP] defines the Error Code name space and rules for management of [RSVP] defines the Error Code name space and rules for management of
this name space by IANA. Currently allocated Error Codes are listed this name space by IANA. Currently allocated Error Codes are listed
at "http://www.iana.org/assignments/rsvp-parameters" at "http://www.iana.org/assignments/rsvp-parameters"
This document defines in section 6.5 a new RSVP Error Code, the This document defines in section 6.5 a new RSVP Error Code, the
"Diff-Serv-aware TE Error". In accordance with the IANA "Diff-Serv-aware TE Error". In accordance with the IANA
considerations provided in [RSVP], Error Code TBD was assigned by considerations provided in [RSVP], Error Code TBD was assigned by
IANA to the "Diff-Serv-aware TE Error". IANA to the "Diff-Serv-aware TE Error".
<IANA-note> To be removed by the RFC editor at the time of <IANA-note> To be removed by the RFC editor at the time of
publication: When the RSVP Class-Num is assigned by IANA publication:
replace "TBD" When the RSVP Class-Num is assigned by IANA replace "TBD" above by
above by the assigned value. the assigned value.
</IANA-note> </IANA-note>
14.3.5. Error Values for "Diff-Serv-aware TE Error"
14.3.5.Error Values for "Diff-Serv-aware TE Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in An Error Code is an 8-bit quantity defined in [RSVP] that appears in
an ERROR_SPEC object to broadly define an error condition. With each an ERROR_SPEC object to broadly define an error condition. With each
Protocols for Diffserv-aware TE December 2004
Error Code there may be a 16-bit Error Value (which depends on the Error Code there may be a 16-bit Error Value (which depends on the
Error Code) that further specifies the cause of the error. Error Code) that further specifies the cause of the error.
This document defines in section 6.5 a new RSVP error code, the This document defines in section 6.5 a new RSVP error code, the
"Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for "Diff-Serv-aware TE Error" (see section 14.3.4). The Error Values for
the "Diff-Serv-aware TE Error" constitute a new name space to be the "Diff-Serv-aware TE Error" constitute a new name space to be
managed by IANA. managed by IANA.
This document defines, in section 6.5, the following Error Values for This document defines, in section 6.5, the following Error Values for
the "Diff-Serv-aware TE Error": the "Diff-Serv-aware TE Error":
Value Error Value Error
1 Unexpected CLASSTYPE object 1 Unexpected CLASSTYPE object
2 Unsupported Class-Type 2 Unsupported Class-Type
3 Invalid Class-Type value 3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured 4 Class-Type and setup priority do not form a configured
TE-Class TE-Class
5 Class-Type and holding priority do not form a 5 Class-Type and holding priority do not form a
configured TE-Class configured TE-Class
6 Inconsistency between signaled PSC and signaled 6 Class-Type and setup priority do not form a configured
TE-Class AND Class-Type and holding priority do not form
a configured TE-Class
7 Inconsistency between signaled PSC and signaled
Class-Type Class-Type
7 Inconsistency between signaled PHBs and signaled 8 Inconsistency between signaled PHBs and signaled
Class-Type Class-Type
Protocols for Diffserv-aware TE March 2004
See section 14.2 for allocation of other values in that name space. See section 14.2 for allocation of other values in that name space.
15. Intellectual Property Considerations 15. Intellectual Property Considerations
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in RFC 2028. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
Protocols for Diffserv-aware TE December 2004
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
16. Normative References 16.Normative References
[DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv- [DSTE-REQ] Le Faucheur et al, Requirements for support of Diff-Serv-
aware MPLS Traffic Engineering, RFC3564, . aware MPLS Traffic Engineering, RFC3564.
[MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching [MPLS-ARCH] Rosen et al., "Multiprotocol Label Switching
Architecture", RFC3031. Architecture", RFC3031.
[DIFF-ARCH] Blake et al., "An Architecture for Differentiated [DIFF-ARCH] Blake et al., "An Architecture for Differentiated
Services", RFC2475. Services", RFC2475.
[TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over [TE-REQ] Awduche et al., "Requirements for Traffic Engineering Over
MPLS", RFC2702. MPLS", RFC2702.
[OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF [OSPF-TE] Katz et al., "Traffic Engineering (TE) Extensions to OSPF
Version 2", RFC3630. Version 2", RFC3630.
[ISIS-TE] Smit, Li, IS-IS extensions for Traffic Engineering, draft- [ISIS-TE] Smit, Li, "Intermediate System to Intermediate System
ietf-isis-traffic-05.txt, work in progress. (IS-IS) extensions for Traffic Engineering (TE)", RFC 3784.
Protocols for Diffserv-aware TE March 2004
[RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP [RSVP-TE] Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209. Tunnels", RFC 3209.
[RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version [RSVP] Braden et al, "Resource ReSerVation Protocol (RSVP) - Version
1 Functional Specification", RFC 2205. 1 Functional Specification", RFC 2205.
[DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270. [DIFF-MPLS] Le Faucheur et al, "MPLS Support of Diff-Serv", RFC3270.
[RFC2119] S. Bradner, Key words for use in RFCs to Indicate [RFC2119] S. Bradner, Key words for use in RFCs to Indicate
Requirement Levels, RFC2119. Requirement Levels, RFC2119.
[IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA [IANA-CONS], T. Narten et al, "Guidelines for Writing an IANA
Considerations Section in RFCs", RFC2434. Considerations Section in RFCs", RFC2434.
17. Informative References 17.Informative References
[DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints [DSTE-RDM] Le Faucheur et al., "Russian Dolls Bandwidth Constraints
Model for DS-TE", draft-ietf-tewg-diff-te-russian-04.txt, work in Model for DS-TE", draft-ietf-tewg-diff-te-russian-07.txt, work in
progress. progress.
Protocols for Diffserv-aware TE December 2004
[DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth [DSTE-MAM] Le Faucheur, Lai, "Maximum Allocation Bandwidth
Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-02.txt, Constraints Model for DS-TE", draft-ietf-tewg-diff-te-mam-04.txt,
work in progress . work in progress .
[DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth [DSTE-MAR] Ash, "Max Allocation with Reservation Bandwidth
Constraints Model for MPLS/DiffServ TE & Performance Comparisons", Constraints Model for MPLS/DiffServ TE & Performance Comparisons",
draft-ietf-tewg-diff-te-mar-03.txt, work in progress . draft-ietf-tewg-diff-te-mar-03.txt, work in progress .
[GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label [GMPLS-SIG] Berger et. al., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC3471 Switching (GMPLS) Signaling Functional Description", RFC3471
[GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of [GMPLS-ROUTE] Kompella et. al., "Routing Extensions in Support of
Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, work in Generalized MPLS", draft-ietf-ccamp-gmpls-routing-09.txt, work in
progress. progress.
[BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic [BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS Traffic
Engineering", draft-ietf-mpls-bundle-04.txt, work in progress. Engineering", draft-ietf-mpls-bundle-04.txt, work in progress.
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS [HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress. TE", draft-ietf-mpls-lsp-hierarchy-08.txt, work in progress.
[REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP [REROUTE] Pan et. al., "Fast Reroute Extensions to RSVP-TE for LSP
Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt, work in Tunnels", draft-ietf-mpls-rsvp-lsp-fastreroute-07.txt, work in
progress. progress.
18. Editor's Address: 18.Editor's Address:
Protocols for Diffserv-aware TE March 2004
Francois Le Faucheur Francois Le Faucheur
Cisco Systems, Inc. Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3 Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille 400, Avenue de Roumanille
06410 Biot-Sophia Antipolis 06410 Biot-Sophia Antipolis
France France
Phone: +33 4 97 23 26 19 Phone: +33 4 97 23 26 19
Email: flefauch@cisco.com Email: flefauch@cisco.com
19. Full Copyright Statement 19.Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Protocols for Diffserv-aware TE December 2004
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
skipping to change at page 30, line 4 skipping to change at page 30, line 33
Appendix A - Prediction for Multiple Path Computation Appendix A - Prediction for Multiple Path Computation
There are situations where a Head-End needs to compute paths for There are situations where a Head-End needs to compute paths for
multiple LSPs over a short period of time. There are potential multiple LSPs over a short period of time. There are potential
advantages for the Head-end in trying to predict the impact of the n- advantages for the Head-end in trying to predict the impact of the n-
th LSP on the unreserved bandwidth when computing the path for the th LSP on the unreserved bandwidth when computing the path for the
(n+1)-th LSP, before receiving updated IGP information. One example (n+1)-th LSP, before receiving updated IGP information. One example
would be to perform better load-distribution of the multiple LSPs would be to perform better load-distribution of the multiple LSPs
across multiple paths. Another example would be to avoid CAC across multiple paths. Another example would be to avoid CAC
rejection when the (n+1)-th LSP would no longer fit on a link after rejection when the (n+1)-th LSP would no longer fit on a link after
Protocols for Diffserv-aware TE March 2004
establishment of the n-th LSP. While there are also a number of establishment of the n-th LSP. While there are also a number of
conceivable scenarios where doing such predictions might result in a conceivable scenarios where doing such predictions might result in a
worse situation, it is more likely to improve the situation. As a worse situation, it is more likely to improve the situation. As a
matter of fact, a number of network administrators have elected to matter of fact, a number of network administrators have elected to
use such predictions when deploying existing TE. use such predictions when deploying existing TE.
Such predictions are local matters, are optional and are outside the Such predictions are local matters, are optional and are outside the
scope of this specification. scope of this specification.
Where such predictions are not used, the optional Bandwidth Where such predictions are not used, the optional Bandwidth
skipping to change at page 30, line 30 skipping to change at page 31, line 4
that is required by Head-Ends to perform Constraint Based Routing. that is required by Head-Ends to perform Constraint Based Routing.
Where such predictions are used on Head-Ends, the optional Bandwidth Where such predictions are used on Head-Ends, the optional Bandwidth
Constraints sub-TLV and the optional Maximum Reservable Bandwidth Constraints sub-TLV and the optional Maximum Reservable Bandwidth
sub-TLV MAY be advertised in IGP. This is in order for the Head-ends sub-TLV MAY be advertised in IGP. This is in order for the Head-ends
to predict as accurately as possible how an LSP affects unreserved to predict as accurately as possible how an LSP affects unreserved
bandwidth values for subsequent LSPs. bandwidth values for subsequent LSPs.
Remembering that actual admission control algorithms are left for Remembering that actual admission control algorithms are left for
vendor differentiation, we observe that predictions can only be vendor differentiation, we observe that predictions can only be
Protocols for Diffserv-aware TE December 2004
performed effectively when the Head-end LSR predictions are based on performed effectively when the Head-end LSR predictions are based on
the same (or a very close) admission control algorithm as used by the same (or a very close) admission control algorithm as used by
other LSRs. other LSRs.
Appendix B - Solution Evaluation Appendix B - Solution Evaluation
1. Satisfying Detailed Requirements 1. Satisfying Detailed Requirements
This DS-TE Solution addresses all the scenarios presented in [DSTE- This DS-TE Solution addresses all the scenarios presented in [DSTE-
REQ]. REQ].
skipping to change at page 31, line 4 skipping to change at page 31, line 31
The objective set out in the last paragraph of section "4.7 The objective set out in the last paragraph of section "4.7
overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE overbooking" of [DSTE-REQ] is only partially addressed by this DS-TE
solution. Through support of the "LSP Size Overbooking" and "Link solution. Through support of the "LSP Size Overbooking" and "Link
Size Overbooking" methods, this DS-TE solution effectively allows CTs Size Overbooking" methods, this DS-TE solution effectively allows CTs
to have different overbooking ratios and simultaneously allows to have different overbooking ratios and simultaneously allows
overbooking to be tweaked differently (collectively across all CTs) overbooking to be tweaked differently (collectively across all CTs)
on different links. But, in a general sense, it does not allow the on different links. But, in a general sense, it does not allow the
effective overbooking ratio of every CT to be tweaked differently in effective overbooking ratio of every CT to be tweaked differently in
different parts of the network independently of other CTs, while different parts of the network independently of other CTs, while
maintaining accurate bandwidth accounting of how different CTs maintaining accurate bandwidth accounting of how different CTs
Protocols for Diffserv-aware TE March 2004
mutually affect each other through shared Bandwidth Constraints (such mutually affect each other through shared Bandwidth Constraints (such
as the Maximum Reservable Bandwidth). as the Maximum Reservable Bandwidth).
2. Flexibility 2. Flexibility
This DS-TE solution supports 8 CTs. It is entirely flexible as to how This DS-TE solution supports 8 CTs. It is entirely flexible as to how
Traffic Trunks are grouped together into a CT. Traffic Trunks are grouped together into a CT.
3. Extendibility 3. Extendibility
skipping to change at page 31, line 32 skipping to change at page 32, line 5
extensions beyond those specified in this document. extensions beyond those specified in this document.
Although the prime objective of this solution is support of Diff- Although the prime objective of this solution is support of Diff-
Serv-aware Traffic Engineering, its mechanisms are not tightly Serv-aware Traffic Engineering, its mechanisms are not tightly
coupled with Diff-Serv. This makes the solution amenable, or more coupled with Diff-Serv. This makes the solution amenable, or more
easily extendable, for support of potential other future Traffic easily extendable, for support of potential other future Traffic
Engineering applications. Engineering applications.
4. Scalability 4. Scalability
Protocols for Diffserv-aware TE December 2004
This DS-TE solution is expected to have a very small scalability This DS-TE solution is expected to have a very small scalability
impact compared to existing TE. impact compared to existing TE.
From an IGP viewpoint, the amount of mandatory information to be From an IGP viewpoint, the amount of mandatory information to be
advertised is identical to existing TE. One additional sub-TLV has advertised is identical to existing TE. One additional sub-TLV has
been specified, but its use is optional and it only contains a been specified, but its use is optional and it only contains a
limited amount of static information (at most 8 Bandwidth limited amount of static information (at most 8 Bandwidth
Constraints). Constraints).
We expect no noticeable impact on LSP Path computation since, as with We expect no noticeable impact on LSP Path computation since, as with
skipping to change at page 32, line 5 skipping to change at page 32, line 31
this solution since it only requires processing of one additional this solution since it only requires processing of one additional
information (the Class-Type) and does not significantly increase the information (the Class-Type) and does not significantly increase the
likelihood of CAC rejection. Note that DS-TE has some inherent impact likelihood of CAC rejection. Note that DS-TE has some inherent impact
on LSP signaling in the sense that it assumes that different classes on LSP signaling in the sense that it assumes that different classes
of traffic are split over different LSPs so that more LSPs need to be of traffic are split over different LSPs so that more LSPs need to be
signaled; but this is due to the DS-TE concept itself and not to the signaled; but this is due to the DS-TE concept itself and not to the
actual DS-TE solution discussed here. actual DS-TE solution discussed here.
5. Backward Compatibility/Migration 5. Backward Compatibility/Migration
Protocols for Diffserv-aware TE March 2004
This solution is expected to allow smooth migration from existing TE This solution is expected to allow smooth migration from existing TE
to DS-TE. This is because existing TE can be supported as a to DS-TE. This is because existing TE can be supported as a
particular configuration of DS-TE. This means that an "upgraded" LSR particular configuration of DS-TE. This means that an "upgraded" LSR
with a DS-TE implementation can directly interwork with an "old" LSR with a DS-TE implementation can directly interwork with an "old" LSR
supporting existing TE only. supporting existing TE only.
This solution is expected to allow smooth migration when increasing This solution is expected to allow smooth migration when increasing
the number of CTs actually deployed since it only requires the number of CTs actually deployed since it only requires
configuration changes. however, these changes must be performed in a configuration changes. However, these changes need to be performed in
coordinated manner across the DS-TE domain. a coordinated manner across the DS-TE domain.
Appendix C - Interoperability with non DS-TE capable LSRs Appendix C - Interoperability with non DS-TE capable LSRs
This DSTE solution allows operations in a hybrid network where some This DSTE solution allows operations in a hybrid network where some
LSRs are DS-TE capable while some LSRs are not DS-TE capable, which LSRs are DS-TE capable while some LSRs are not DS-TE capable, which
may occur during migration phases. This Appendix discusses the may occur during migration phases. This Appendix discusses the
constraints and operations in such hybrid networks. constraints and operations in such hybrid networks.
We refer to the set of DS-TE capable LSRs as the DS-TE domain. We We refer to the set of DS-TE capable LSRs as the DS-TE domain. We
refer to the set of non DS-TE capable (but TE capable) LSRs as the refer to the set of non DS-TE capable (but TE capable) LSRs as the
TE-domain. TE-domain.
Hybrid operations requires that the TE-class mapping in the DS-TE Hybrid operations requires that the TE-class mapping in the DS-TE
domain is configured so that: domain is configured so that:
Protocols for Diffserv-aware TE December 2004
- a TE-class exist for CT0 for every preemption priority - a TE-class exist for CT0 for every preemption priority
actually used in the TE domain actually used in the TE domain
- the index in the TE-class mapping for each of these TE- - the index in the TE-class mapping for each of these TE-
classes is equal to the preemption priority. classes is equal to the preemption priority.
For example, imagine the TE domain uses preemption 2 and 3. Then, DS- For example, imagine the TE domain uses preemption 2 and 3. Then, DS-
TE can be deployed in the same network by including the following TE- TE can be deployed in the same network by including the following TE-
classes in the TE-class mapping: classes in the TE-class mapping:
i <---> CT preemption i <---> CT preemption
==================================== ====================================
2 CT0 2 2 CT0 2
3 CT0 3 3 CT0 3
Another way to look at this is to say that, the whole TE-class Another way to look at this is to say that, the whole TE-class
mapping does not have to be consistent with the TE domain, but the mapping does not have to be consistent with the TE domain, but the
subset of this TE-Class mapping applicable to CT0 must effectively be subset of this TE-Class mapping applicable to CT0 has to effectively
consistent with the TE domain. be consistent with the TE domain.
Hybrid operations also requires that: Hybrid operations also requires that:
- non DS-TE capable LSRs be configured to advertise the Maximum - non DS-TE capable LSRs be configured to advertise the Maximum
Reservable Bandwidth Reservable Bandwidth
- DS-TE capable LSRs be configured to advertise Bandwidth - DS-TE capable LSRs be configured to advertise Bandwidth
Constraints (using the Max Reservable Bandwidth sub-TLV as Constraints (using the Max Reservable Bandwidth sub-TLV as
Protocols for Diffserv-aware TE March 2004
well as the Bandwidth Constraints sub-TLV, as specified in well as the Bandwidth Constraints sub-TLV, as specified in
section 5.1 above). section 5.1 above).
This allows DS-TE capable LSRs to unambiguously identify non DS-TE This allows DS-TE capable LSRs to unambiguously identify non DS-TE
capable LSRs. capable LSRs.
Finally hybrid operations require that non DS-TE capable LSRs be able Finally hybrid operations require that non DS-TE capable LSRs be able
to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth to accept Unreserved Bw sub-TLVs containing non decreasing bandwidth
values (ie with Unreserved [p] < Unreserved [q] with p <q). values (ie with Unreserved [p] < Unreserved [q] with p <q).
In such hybrid networks : In such hybrid networks :
skipping to change at page 33, line 33 skipping to change at page 34, line 4
- LSPs from other CTs can only transit via (or terminate at) - LSPs from other CTs can only transit via (or terminate at)
DS-TE capable LSRs DS-TE capable LSRs
Let us consider, the following example to illustrate operations: Let us consider, the following example to illustrate operations:
LSR0--------LSR1----------LSR2 LSR0--------LSR1----------LSR2
Link01 Link12 Link01 Link12
Where: Where:
LSR0 is a non-DS-TE capable LSR LSR0 is a non-DS-TE capable LSR
Protocols for Diffserv-aware TE December 2004
LSR1 and LSR2 are DS-TE capable LSRs LSR1 and LSR2 are DS-TE capable LSRs
Let"s assume again that preemption 2 and 3 are used in the TE-domain Let"s assume again that preemption 2 and 3 are used in the TE-domain
and that the following TE-class mapping is configured on LSR1 and and that the following TE-class mapping is configured on LSR1 and
LSR2: LSR2:
i <---> CT preemption i <---> CT preemption
==================================== ====================================
0 CT1 0 0 CT1 0
1 CT1 1 1 CT1 1
2 CT0 2 2 CT0 2
skipping to change at page 34, line 5 skipping to change at page 34, line 29
LSR0 is configured with a Max Reservable bandwidth=m01 for Link01. LSR0 is configured with a Max Reservable bandwidth=m01 for Link01.
LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max LSR1 is configured with a BC0=x0 a BC1=x1(possibly=0), and a Max
Reservable Bandwidth=m10(possibly=m01) for Link01. Reservable Bandwidth=m10(possibly=m01) for Link01.
LSR0 will advertise in IGP for Link01: LSR0 will advertise in IGP for Link01:
- Max Reservable Bw sub-TLV = <m01> - Max Reservable Bw sub-TLV = <m01>
- Unreserved Bw sub-TLV = - Unreserved Bw sub-TLV =
<CT0/0,CT0/1,CT0/2,CT0/3,CT0/4,CT0/5,CT0/6,CT0/7> <CT0/0,CT0/1,CT0/2,CT0/3,CT0/4,CT0/5,CT0/6,CT0/7>
Protocols for Diffserv-aware TE March 2004
On receipt of such advertisement, LSR1 will: On receipt of such advertisement, LSR1 will:
- understand that LSR0 is not DS-TE capable because it - understand that LSR0 is not DS-TE capable because it
advertised a Max Reservable Bw sub-TLV and no Bandwidth advertised a Max Reservable Bw sub-TLV and no Bandwidth
Constraints sub-TLV Constraints sub-TLV
- conclude that only CT0 LSPs can transit via LSR0 and that - conclude that only CT0 LSPs can transit via LSR0 and that
only the values CT0/2 and CT0/3 are meaningful in the only the values CT0/2 and CT0/3 are meaningful in the
Unreserved Bw sub-TLV. LSR1 may effectively behave as if the Unreserved Bw sub-TLV. LSR1 may effectively behave as if the
six other values contained in the Unreserved Bw sub-TLV were six other values contained in the Unreserved Bw sub-TLV were
set to zero. set to zero.
skipping to change at line 1680 skipping to change at page 35, line 4
- Unreserved Bw sub-TLV = <CT1/0,CT1/1,CT0/2,CT0/3,0,0,0,0> - Unreserved Bw sub-TLV = <CT1/0,CT1/1,CT0/2,CT0/3,0,0,0,0>
On receipt of such advertisement, LSR0 will: On receipt of such advertisement, LSR0 will:
- Ignore the Bandwidth Constraints sub-TLV (unrecognized) - Ignore the Bandwidth Constraints sub-TLV (unrecognized)
- Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub- - Correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-
TLV and use these values for CTO LSP establishment TLV and use these values for CTO LSP establishment
- Incorrectly believe that the other values contained in the - Incorrectly believe that the other values contained in the
Unreserved Bw sub-TLV relates to other preemption priorities Unreserved Bw sub-TLV relates to other preemption priorities
for CT0, but will actually never use those since we assume for CT0, but will actually never use those since we assume
that only preemption 2 and 3 are used in the TE domain. that only preemption 2 and 3 are used in the TE domain.
Protocols for Diffserv-aware TE December 2004
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 164 change blocks. 
256 lines changed or deleted 307 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/