RFC 4124
Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
RFC 4124 🎀 Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering
okay bestie, this one is a Standards Track doc from June 2005 💖 The editor is F. Le Faucheur, Ed. from Cisco Systems, Inc. 🦋 The header doesn't list any RFCs it obsoletes or updates, so it's standing on its own, no drama 💅
Status of This Memo ✨
this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the current standardization state and status, check the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 🌈
Copyright Notice 🌸
Copyright (C) The Internet Society (2005). 💜
Abstract 🔥
okay so this doc specifies the protocol extensions for Diffserv-aware MPLS Traffic Engineering (DS-TE) 😭 It's giving generalization: it expands the meaning of a bunch of IGP extensions that already existed for regular MPLS Traffic Engineering in RFC 3630 and RFC 3784, and it adds some new IGP extensions on top 🧚 It also extends RSVP-TE signaling beyond what RFC 3209 already covers for regular MPLS TE ✨ All of this is so DS-TE's requirements from RFC 3564 are actually met 👑
Table of Contents 🍓
1. Introduction ....................................................3
1.1. Specification of Requirements ..............................3
2. Contributing Authors ............................................4
3. Definitions .....................................................5
4. Configurable Parameters .........................................5
4.1. Link Parameters ............................................5
4.1.1. Bandwidth Constraints (BCs) .........................5
4.1.2. Overbooking .........................................6
4.2. LSR Parameters .............................................7
4.2.1. TE-Class Mapping ....................................7
4.3. LSP Parameters .............................................8
4.3.1. Class-Type ..........................................8
4.3.2. Setup and Holding Preemption Priorities .............8
4.3.3. Class-Type/Preemption Relationship ..................8
4.4. Examples of Parameters Configuration .......................9
4.4.1. Example 1 ...........................................9
4.4.2. Example 2 ...........................................9
4.4.3. Example 3 ..........................................10
4.4.4. Example 4 ..........................................11
4.4.5. Example 5 ..........................................11
5. IGP Extensions for DS-TE .......................................12
5.1. Bandwidth Constraints .....................................12
5.2. Unreserved Bandwidth ......................................14
6. RSVP-TE Extensions for DS-TE ...................................15
6.1. DS-TE-Related RSVP Messages Format ........................15
6.1.1. Path Message Format ................................16
6.2. CLASSTYPE Object ..........................................16
6.2.1. CLASSTYPE object ...................................16
6.3. Handling CLASSTYPE Object .................................17
6.4. Non-support of the CLASSTYPE Object .......................20
6.5. Error Codes for Diffserv-aware TE .........................20
7. DS-TE Support with MPLS Extensions .............................21
7.1. DS-TE Support and References to Preemption Priority .......22
7.2. DS-TE Support and References to Maximum Reservable
Bandwidth .................................................22
8. Constraint-Based Routing .......................................22
9. Diffserv Scheduling ............................................23
10. Existing TE as a Particular Case of DS-TE .....................23
11. Computing "Unreserved TE-Class [i]" and Admission
Control Rules .................................................23
11.1. Computing "Unreserved TE-Class [i]" .....................23
11.2. Admission Control Rules .................................24
12. Security Considerations .......................................24
13. IANA Considerations ...........................................25
13.1. A New Name Space for Bandwidth Constraints Model
Identifiers .............................................25
13.2. A New Name Space for Error Values under the
"Diffserv-aware TE ......................................25
13.3. Assignments Made in This Document .......................26
13.3.1. Bandwidth Constraints sub-TLV for
OSPF Version 2 ..................................26
13.3.2. Bandwidth Constraints sub-TLV for ISIS ..........26
13.3.3. CLASSTYPE Object for RSVP .......................26
13.3.4. "Diffserv-aware TE Error" Error Code ............27
13.3.5. Error Values for "Diffserv-aware TE Error" ......27
14. Acknowledgements ..............................................28
Appendix A: Prediction for Multiple Path Computation ..............29
Appendix B: Solution Evaluation ...................................29
Appendix C: Interoperability with non DS-TE capable LSRs ..........31
Normative References ..............................................34
Informative References ............................................351. Introduction ✨
okay so [DSTE-REQ] is where the Service Provider requirements for DS-TE live 🧚 The big one is the ability to enforce different bandwidth constraints for different classes of traffic 💅
this doc specifies the IGP and RSVP-TE signaling extensions (on top of what's already specified for regular MPLS Traffic Engineering [OSPF-TE][ISIS-TE][RSVP-TE]) to meet the DS-TE requirements from [DSTE-REQ] 🦋 That includes environments that rely on distributed Constraint-Based Routing, like path computation involving head-end Label Switching Routers 🌈
[DSTE-REQ] gives a definition and examples of Bandwidth Constraints models 📚 This doc doesn't specify or assume one particular model, and specific models are out of scope here 🙈 The extensions can't necessarily support every conceivable Bandwidth Constraints model, but they do support the Russian Dolls Model from [DSTE-RDM], the Maximum Allocation Model from [DSTE-MAM], and the Maximum Allocation with Reservation Model from [DSTE-MAR] 👑
there can be differences between the quality of service you expect and get with Diffserv alone versus Diffserv with DS-TE 😭 Because DS-TE uses Constraint-Based Routing, and because of the admission control it adds to Diffserv, DS-TE can do things Diffserv can't: Diffserv doesn't indicate preemption by intent, but DS-TE describes multiple levels of preemption for its Class-Types 💖 Also, Diffserv has no way to explicitly control overbooking, while DS-TE allows it ✨ So if you're building a full quality of service environment with Diffserv routers and DS-TE, you really need to think about these differences carefully 🫶
1.1. Specification of Requirements 🌸
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 💜
2. Contributing Authors 🦋
this doc was a team effort with several authors 🫶 The text and content came from the editor and the co-authors below. (The editor's contact info is in the Editor's Address section.)
Jim Boyle Kireeti Kompella
Protocol Driven Networks, Inc. Juniper Networks, Inc.
1381 Kildaire Farm Road #288 1194 N. Mathilda Ave.
Cary, NC 27511, USA Sunnyvale, CA 94099
Phone: (919) 852-5160 EMail: kireeti@juniper.net
EMail: jboyle@pdnets.com
William Townsend Thomas D. Nadeau
Tenor Networks Cisco Systems, Inc.
100 Nagog Park 250 Apollo Drive
Acton, MA 01720 Chelmsford, MA 01824
Phone: +1-978-264-4900 Phone: +1-978-244-3051
EMail: btownsend@tenornetworks.com EMail: tnadeau@cisco.com
Darek Skalecki
Nortel Networks
3500 Carling Ave,
Nepean K2H 8E9
Phone: +1-613-765-2252
EMail: dareks@nortelnetworks.com3. Definitions 🧚
bestie, a few definitions from [DSTE-REQ] get repeated here so you don't have to go hunting 🔍
- Traffic Trunk 🍓 is an aggregation of traffic flows of the same class (meaning they get treated equivalently from the DS-TE perspective), and it gets placed inside a Label Switched Path (LSP).
- Class-Type (CT) 👑 is the set of Traffic Trunks crossing a link that's governed by one specific set of bandwidth constraints. CT is used for link bandwidth allocation, constraint-based routing, and admission control. A given Traffic Trunk belongs to the same CT on all links.
- TE-Class 💅 is a pair of: (i) a Class-Type, and (ii) a preemption priority allowed for that Class-Type. This means an LSP carrying a Traffic Trunk from that Class-Type can use that preemption priority as the setup priority, the holding priority, or both.
definitions for a bunch of MPLS terms aren't repeated here, so go check [MPLS-ARCH] for those 📚
4. Configurable Parameters 🌈
this section only covers the differences from the configurable parameters supported for MPLS Traffic Engineering per [TE-REQ], [ISIS-TE], [OSPF-TE], and [RSVP-TE] 💖 Everything else is unchanged, so no need to panic ✨
4.1. Link Parameters 🦋
4.1.1. Bandwidth Constraints (BCs) 💅
okay so [DSTE-REQ] literally says: "Regardless of the Bandwidth Constraints Model, the DS-TE solution MUST allow support for up to 8 BCs." 🎀 That's the main vibe check for this part.
For DS-TE, the old "Maximum Reservable link bandwidth" parameter sticks around, but it gets a glow-up. Its meaning is generalized, so it's now the aggregate bandwidth constraint across all Class-Types. No matter which Bandwidth Constraints Model you're using, this has to hold:
SUM (Reserved (CTc)) <= Max Reservable Bandwidth,where the SUM is across all values of "c" in the range 0 <= c <= 7. 🧚
Also, on every link, a DS-TE implementation MUST provide for configuration of up to 8 additional link parameters. These are the eight potential BCs: BC0, BC1, ... BC7. ✨ The LSR MUST interpret these BCs in accordance with the supported Bandwidth Constraints Model, meaning it has to figure out what BC applies to what Class-Type, and how. 🤓
Some models have rules about how the BC values relate to each other, and when that happens the LSR MUST enforce those rules at configuration time. For example, with the Russian Dolls Bandwidth Constraints Model ([DSTE-RDM]), the LSR MUST ensure that BCi is configured smaller than or equal to BCj, where i is greater than j, and ensure that BC0 is equal to the Maximum Reservable Bandwidth. 🪆 Another example: with the Maximum Allocation Model ([DSTE-MAM]), the LSR MUST ensure that all BCi are configured smaller or equal to the Maximum Reservable Bandwidth. 💖
4.1.2. Overbooking 🌸
DS-TE lets a network admin use different overbooking (or underbooking) ratios for different CTs. Iconic. 👑
The main ways to do this are the same ones people have used in regular TE deployments:
- (i) Take into account the overbooking/underbooking ratio that fits the Ordered Aggregate (OA) or CT tied to the LSP being considered, at the moment you set the bandwidth size of that LSP. We call this the "LSP Size Overbooking" method. AND/OR
- (ii) Take into account the overbooking/underbooking ratio when you configure the Maximum Reservable Bandwidth/BCs, and use values that are larger (overbooking) or smaller (underbooking) than what the link actually supports. We call this the "Link Size Overbooking" method.
The "LSP Size Overbooking" and "Link Size Overbooking" methods are expected to be enough in lots of DS-TE environments, and they don't need any extra configurable parameters. 🙌 Other overbooking methods might bring in extra configurable parameters, but those are out of scope for this document. 🫶
4.2. LSR Parameters 🦋
4.2.1. TE-Class Mapping 🍓
Following [DSTE-REQ], the preemption attributes from [TE-REQ] stay the same with DS-TE, and they apply within and across all CTs. ✨ The setup and holding priority keep their existing meanings, and those meanings aren't changed by the LSP CT. So if LSP1 and LSP2 fight over resources, LSP1 can preempt LSP2 when LSP1 has a higher setup preemption priority (lower numerical priority value) than LSP2's holding preemption priority. This applies no matter what LSP1's CT and LSP2's CT are. 💅
DS-TE LSRs MUST allow configuration of a TE-Class mapping, where the Class-Type and preemption level get set for each of (up to) 8 TE-Classes. 🌈
This mapping looks like this:
TE-Class[i] <--> < CTc , preemption p >
where 0 <= i <= 7, 0 <= c <= 7, 0 <= p <= 7Two TE-Classes MUST NOT be identical, meaning they can't have both the same Class-Type and the same preemption priority. 🙅♀️
Apart from that, there are no other rules on how the 8 Class-Types get paired with the 8 preemption priorities to form a TE-Class. 🎀 One preemption priority can be paired with two (or more) different Class-Types to make two (or more) TE-Classes. One Class-Type can also be paired with two (or more) different preemption priorities. And there's no required ordering between the TE-Class index ("i" above) and the Class-Type ("c" above) or the preemption priority ("p" above). It's giving freedom. 🧚
If the network admin uses fewer than 8 TE-Classes, the DS-TE LSR MUST allow the remaining ones to be configured as "Unused". 💀 Heads up: if all 8 TE-Classes are "Unused", that effectively disables TE/DS-TE, because no TE/DS-TE LSP can be established (or even configured, since, as described in Section 4.3.3 below, the CT and preemption priorities configured for an LSP MUST form one of the configured TE-Classes). 🙈
For coherent DS-TE operation, the network admin MUST configure exactly the same TE-Class mapping on all LSRs in the DS-TE domain. 🫶
When the TE-Class mapping needs changing in the DS-TE domain, be careful during the transition, because some DS-TE LSRs may have the new mapping while others still have the old one. It is recommended that active tunnels do not use any of the TE-Classes 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 extra configurable parameter that indicates the Class-Type of the Traffic Trunk carried by the LSP. 🔥
Each LSP has one and only one Class-Type configured. No sharing, bestie. 👑
The configured Class-Type indicates, according to the supported Bandwidth Constraints Model, which BCs MUST be enforced for that LSP. 🎀
4.3.2. Setup and Holding Preemption Priorities 🌸
Just like existing TE, DS-TE LSRs MUST allow every DS-TE LSP to be configured with a setup and holding priority, each with a value between 0 and 7. 🦋
4.3.3. Class-Type/Preemption Relationship 🍓
With DS-TE, the preemption priority configured for the setup priority of a given LSP and the Class-Type configured for that LSP MUST be such that, together, they form one of the (up to) 8 TE-Classes in the TE-Class mapping specified in Section 4.2.1 above. 🌈
The preemption priority configured for the holding priority of a given LSP and the Class-Type configured for that LSP MUST also be such that, together, they form one of the (up to) 8 TE-Classes in the TE-Class mapping specified in Section 4.2.1 above. 💅
The LSR MUST enforce these two rules at configuration time. 🔒
4.4. Examples of Parameters Configuration 🎀
Here come the examples! ✨ We're showing a few ways these configurable parameters can be used. Every example assumes that different BCs need enforcing for different sets of Traffic Trunks (like Voice and Data), so two or more Class-Types are needed. 🧁
4.4.1. Example 1 🎤
The network admin of a first network uses two CTs (CT1 for Voice and CT0 for Data). They might set the following TE-Class mapping so that Voice LSPs never get pushed off their shortest path by Data LSPs: 🙌
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[i] <--> unused, for 2 <= i <= 7Voice LSPs would then get:
CT = CT1, setup priority = 0, holding priority = 0Data LSPs would then get:
CT = CT0, setup priority = 1, holding priority = 1A new Voice LSP can preempt an existing Data LSP if they contend for resources. 🎙️ A Data LSP would never preempt a Voice LSP. A Voice LSP would never preempt another Voice LSP. A Data LSP would never preempt another Data LSP. Clean. 💅
4.4.2. Example 2 🌷
Another network admin might set the following TE-Class mapping to make better use of global network resources by letting large LSPs stay closer to their shortest path: 🧠
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 1 >
TE-Class[2] <--> < CT1 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 1, holding priority = 1Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 2, holding priority = 2Small-size Data LSPs could be configured with:
CT = CT0, setup priority = 3, holding priority = 3A new large-size Voice LSP can preempt a small-size Voice LSP or any Data LSP if they contend for resources. 🎤 A new large-size Data LSP can preempt a small-size Data LSP or a small-size Voice LSP if they contend for resources, but it can't preempt a large-size Voice LSP. 🥹
4.4.3. Example 3 🍑
This admin wants Voice LSPs never pushed away from their shortest path by Data LSPs, and also some global optimization by keeping large LSPs close to their shortest path: 🦄
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 2 >
TE-Class[3] <--> < CT0 , preemption 3 >
TE-Class[i] <--> unused, for 4 <= i <= 7Large-size Voice LSPs could be configured with:
CT = CT1, setup priority = 0, holding priority = 0.Small-size Voice LSPs could be configured with:
CT = CT1, setup priority = 1, holding priority = 1.Large-size Data LSPs could be configured with:
CT = CT0, setup priority = 2, holding priority = 2.Small-size Data LSPs could be configured with:
CT=CT0, setup priority = 3, holding priority = 3.A Voice LSP can preempt a Data LSP if they contend for resources. A Data LSP would never preempt a Voice LSP. A large-size Voice LSP can preempt a small-size Voice LSP if they contend for resources. A large-size Data LSP can preempt a small-size Data LSP if they contend for resources. ⚡
4.4.4. Example 4 🫧
Last one! This admin wants no preemption at all in the DS-TE domain: 🛑
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT0 , preemption 0 >
TE-Class[i] <--> unused, for 2 <= i <= 7Voice LSPs would then be configured with:
CT = CT1, setup priority =0, holding priority = 0Data LSPs would then be configured with:
CT = CT0, setup priority = 0, holding priority = 0No LSP can preempt any other LSP. Totally calm, totally stable. 🌊🫶
4.4.5. Example 5 ✨
okay bestie, this one's for a network admin who's like "I want stability, not drama" 🫶 so they're gonna use preemption way less. Their TE-Class mapping looks like this 🎀
TE-Class[0] <--> < CT1 , preemption 0 >
TE-Class[1] <--> < CT1 , preemption 1 >
TE-Class[2] <--> < CT0 , preemption 1 >
TE-Class[3] <--> < CT0 , preemption 2 >
TE-Class[i] <--> unused, for 4 <= i <= 7Now the LSPs. Here's how each kind gets set up 💅
Large-size Voice LSPs could be configured with: CT = CT1, setup
priority = 0, holding priority = 0.
Small-size Voice LSPs could be configured with: CT = CT1, setup
priority = 1, holding priority = 0.
Large-size Data LSPs could be configured with: CT = CT0, setup
priority = 2, holding priority = 1.
Small-size Data LSPs could be configured with: CT = CT0, setup
priority = 2, holding priority = 2.So if a brand-new large-size Voice LSP is fighting for resources, it can preempt a Data LSP 🔥 but it can't touch ANY Voice LSP, not even a small-size one 🙅♀️
A new small-size Voice LSP can preempt a small-size Data LSP if they contend for resources, but it can't preempt a large-size Data LSP or any Voice LSP. Lowkey very organized 🌸
A Data LSP can't preempt any other LSP. Just vibes, no drama 🧚
5. IGP Extensions for DS-TE 🌈
okay so this section only talks about what's different from the IGP advertisement that's supported for (aggregate) MPLS Traffic Engineering, as per [OSPF-TE] and [ISIS-TE]. Everything else in the IGP advertisement stays exactly the same ✨
5.1. Bandwidth Constraints
As we already covered in Section 4.1.1, up to 8 BCs (BCb, 0 <= b <= 7) can be configured on any given link 💖
With DS-TE, the existing "Maximum Reservable Bandwidth" sub-TLV ([OSPF-TE], [ISIS-TE]) is kept, but with a generalized meaning. It MUST now be read as the aggregate bandwidth constraint across ALL Class-Types, so SUM (Reserved (CTc)) <= Max Reservable Bandwidth, no matter which Bandwidth Constraints Model is in use 👑
This document also defines a brand-new optional sub-TLV to advertise the eight potential BCs (BC0 to BC7) 🦋
"Bandwidth Constraints" sub-TLV:
Bandwidth Constraints Model Id(1 octet)Reserved(3 octets)Bandwidth Constraints(N x 4 octets)
Where:
- With OSPF, the sub-TLV is a sub-TLV of the "Link TLV" and its sub-TLV type is 17.
- With ISIS, the sub-TLV is a sub-TLV of the "extended IS reachability TLV" and its sub-TLV type is 22.
Bandwidth Constraints Model Id: a 1-octet identifier for the Bandwidth Constraints Model currently in use by the LSR initiating the IGP advertisement. Check the IANA Considerations section for how values get assigned in this name space 🍓Reserved: a 3-octet field. This field should be set to zero by the LSR generating the sub-TLV and should be ignored by the LSR receiving the sub-TLV.Bandwidth Constraints: contains BC0, BC1,... BC(N-1). Each BC is encoded on 32 bits in IEEE floating point format. The units are bytes (not bits!) per second. Now here's the lowkey genius part: if the configured TE-Class mapping and the Bandwidth Constraints model in use mean that BCh+1, BCh+2, ...and BC7 aren't relevant to any of the Class-Types tied to a configured TE-Class, it is RECOMMENDED that only BC0 through BCh get advertised. That keeps IGP scalability happy 🫶
All the relevant generic TLV encoding rules (including TLV format, padding and alignment, and IEEE floating point format encoding) from [OSPF-TE] and [ISIS-TE] apply to this new sub-TLV 🎀
The "Bandwidth Constraints" sub-TLV format looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC Model Id | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BC0 value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// . . . //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BCh value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+A DS-TE LSR MAY optionally advertise BCs 🌷
A DS-TE LSR that DOES advertise BCs MUST use the new "Bandwidth Constraints" sub-TLV (on top of the existing Maximum Reservable Bandwidth sub-TLV) to do it. For example, say a service provider deploys DS-TE with TE-Classes tied only to CT0 and CT1, and the Bandwidth Constraints Model means only BC0 and BC1 matter for CT0 and CT1. Then the DS-TE LSR that advertises BCs would include BOTH the Maximum Reservable Bandwidth sub-TLV AND the "Bandwidth Constraints" sub-TLV in its IGP advertisement. The first should hold the aggregate bandwidth constraint across all CTs, and the second should hold BC0 and BC1 ✨
Now the tricky bit 👀 A DS-TE LSR that receives the "Bandwidth Constraints" sub-TLV with a Bandwidth Constraints Model Id that doesn't match the model it's currently using SHOULD generate a warning to the operator/management system, reporting the mismatch between Bandwidth Constraints Models used on different links. In that same situation, if the DS-TE LSR doesn't support the Bandwidth Constraints Model designated by the Bandwidth Constraints Model Id, OR if it doesn't support operations with multiple simultaneous Bandwidth Constraints Models, the DS-TE LSR MAY discard the corresponding TLV. But if the DS-TE LSR DOES support the designated model AND DOES support multiple simultaneous models, it MAY accept the TLV and allow operations with different Bandwidth Constraints Models used in different parts of the DS-TE domain 💅
5.2. Unreserved Bandwidth
With DS-TE, the existing "Unreserved Bandwidth" sub-TLV is kept as the ONLY way to advertise the dynamic bandwidth info that Constraint-Based Routing on head-ends needs. The catch is that it now has a generalized meaning. It still carries eight bandwidth values, but they now match the unreserved bandwidth for each TE-Class, instead of for each preemption priority like in existing TE 🦋
More precisely, a DS-TE LSR MUST support the Unreserved Bandwidth sub-TLV with a definition that's generalized into the following 💖
The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved for each of the eight TE-Classes. It's in IEEE floating point format, arranged in increasing order of TE-Class index. Unreserved bandwidth for TE-Class [0] sits at the start of the sub-TLV, and unreserved bandwidth for TE-Class [7] sits at the end. The unreserved bandwidth value for TE-Class [i] (0 <= i <= 7) is called "Unreserved TE-Class [i]". It tells you how much bandwidth is available for reservation to an LSP that:
- transports a Traffic Trunk from the Class-Type of TE-Class[i], and
- has a setup priority matching the preemption priority of TE-Class[i].
The units are bytes per second 🍓
Because the bandwidth values are ordered by TE-Class index now, they can relate to different CTs (with different BCs) and to any arbitrary preemption priority. So a DS-TE LSR MUST NOT assume any ordered relationship among these bandwidth values 🙈
With existing TE, every preemption priority reflects the same (and only) BCs, and the bandwidth values are advertised in preemption priority order. So the following is always true, and TE implementations often assume it:
If i < j, then "Unreserved Bw [i]" >= "Unreserved Bw [j]"With DS-TE, NO relationship should be assumed, so:
If i < j, then any of the following relationships may be true:
"Unreserved TE-Class [i]" = "Unreserved TE-Class [j]"
OR
"Unreserved TE-Class [i]" > "Unreserved TE-Class [j]"
OR
"Unreserved TE-Class [i]" < "Unreserved TE-Class [j]".The rules for computing "Unreserved TE-Class [i]" are specified in Section 11 📖
If TE-Class[i] is unused, the value the IGP advertises in "Unreserved TE-Class [i]" MUST be set to zero by the LSR generating the IGP advertisement, and it MUST be ignored by the LSR receiving the IGP advertisement 🌸
6. RSVP-TE Extensions for DS-TE 🧚
In this section we go over the RSVP-TE extensions that support Diffserv-aware MPLS Traffic Engineering. These extensions sit on top of the RSVP extensions defined in [RSVP-TE] for (aggregate) MPLS Traffic Engineering, and the RSVP extensions defined in [DIFF-MPLS] for Diffserv over MPLS 💜
6.1. DS-TE-Related RSVP Messages Format
One new RSVP object is defined in this document: the CLASSTYPE object. We'll get into the details below. This new object applies to Path messages. This spec only defines using the CLASSTYPE object in Path messages that set up LSP Tunnels under [RSVP-TE], which means ones that contain a session object with a CT equal to LSP_TUNNEL_IPv4 and contain a LABEL_REQUEST object ✨
The restrictions that [RSVP-TE] puts on setting up LSP Tunnels also apply to setting up LSP Tunnels that support DS-TE. For instance, only unicast LSPs are supported, and multicast LSPs are for further study 🙈
This new CLASSTYPE object is optional with respect to RSVP, so general RSVP implementations that aren't concerned with MPLS LSP setup don't have to support it 🫶
An LSR supporting DS-TE MUST support the CLASSTYPE object 👑
6.1.1. Path Message Format
The Path message format goes like this 🎀
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <CLASSTYPE> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> [ <SENDER_TSPEC> ]
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]6.2. CLASSTYPE Object
The CLASSTYPE object Class Name is CLASSTYPE, and its Class Number is 66. Right now there's only one defined C-Type, which is C-Type 1. The CLASSTYPE object format is shown below 🦋
6.2.1. CLASSTYPE object 🎀
okay so the CLASSTYPE object is literally just a little tag with a Class Number of 66 and a Class-Type of 1 🦋. Here's how the bits are laid out:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | CT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The Reserved part is 29 bits, and it's giving "don't touch me" 🙈. It MUST be set to zero on transmission and MUST be ignored on receipt.
The CT part is 3 bits and it's the Class-Type itself 💅. Values currently allowed are 1, 2, ... , 7, and a value of 0 is Reserved, so don't even try it.
6.3. Handling CLASSTYPE Object 🌸
okay this is the part where we figure out how the CLASSTYPE object actually gets handled, and it's kind of a lot, bestie 😭.
To set up an LSP tunnel with RSVP, the sender LSR makes a Path message with a session type of LSP_Tunnel_IPv4 and a LABEL_REQUEST object, as per [RSVP-TE]. The sender LSR can also include the DIFFSERV object, as per [DIFF-MPLS].
If the LSP is tied to Class-Type 0, the sender LSR MUST NOT include the CLASSTYPE object in the Path message. This is what keeps things backward compatible with non-DSTE-configured or non-DSTE-capable LSRs, which we'll get into below in Section 10 and Appendix C 🧚.
If the LSP is tied to Class-Type N (1 <= N <=7), the sender LSR MUST include the CLASSTYPE object in the Path message, with the Class-Type (CT) field set to N ✨.
If a Path message has multiple CLASSTYPE objects, only the first one actually matters 💀. The later ones MUST be ignored and MUST NOT be forwarded.
Every LSR along the path MUST record the CLASSTYPE object, when it's present, in its path state block 🍓.
If the CLASSTYPE object isn't in the Path message at all, the LSR MUST associate Class-Type 0 with the LSP.
The destination LSR that answers the Path message with a Resv message MUST NOT include a CLASSTYPE object in that Resv message. This is true whether or not the Path message had one, so no exceptions 👑.
While an LSP for Class-Type N is being set up, the LSR MUST perform admission control over the bandwidth available for that particular Class-Type 🔥.
An LSR that recognizes the CLASSTYPE object and gets a Path message that:
- contains the CLASSTYPE object, but
- does not contain a LABEL_REQUEST object or does not have a session type of LSP_Tunnel_IPv4,
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Unexpected CLASSTYPE object". These codes are defined in Section 6.5 🫶.
An LSR that gets a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object, but
- does not support the particular Class-Type,
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Unsupported Class-Type". These codes are defined in Section 6.5.
An LSR that gets a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object, but
- determines that the Class-Type value is not valid (i.e., Class-Type value 0),
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Invalid Class-Type value". These codes are defined in Section 6.5.
An LSR that gets a Path message with the CLASSTYPE object, which:
- recognizes the CLASSTYPE object and
- 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,
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "CT and setup priority do not form a configured TE-Class". These codes are defined in Section 6.5 💖.
An LSR that gets a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object and
- supports the particular Class-Type, but
- 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 "Diffserv-aware TE Error" and an error value of "CT and holding priority do not form a configured TE-Class". These codes are defined in Section 6.5.
An LSR that gets a Path message with the CLASSTYPE object that:
- recognizes the CLASSTYPE object and
- 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 "Diffserv-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". These codes are defined in Section 6.5 🔥.
An LSR that gets a Path message with the CLASSTYPE object and with the DIFFSERV object for an L-LSP that:
- recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types and Per Hop Behavior (PHB) Scheduling Class, e.g., via configuration, and
- determines, based on this local knowledge, that the PHB Scheduling Class (PSC) signaled in the DIFFSERV object is inconsistent with the Class-Type signaled in the CLASSTYPE object,
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Inconsistency between signaled PSC and signaled CT". These codes are defined below in Section 6.5 🦋.
An LSR that gets a Path message with the CLASSTYPE object and with the DIFFSERV object for an E-LSP that:
- recognizes the CLASSTYPE object,
- has local knowledge of the relationship between Class-Types and PHBs (e.g., via configuration), and
- determines, based on this local knowledge, that the PHBs signaled in the MAP entries of the DIFFSERV object are inconsistent with the Class-Type signaled in the CLASSTYPE object,
MUST send a PathErr towards the sender with the error code "Diffserv-aware TE Error" and an error value of "Inconsistency between signaled PHBs and signaled CT". These codes are defined in Section 6.5 🌈.
An LSR MUST handle situations where the LSP can't be accepted for reasons other than the ones already covered in this section. It does this in accordance with [RSVP-TE] and [DIFF-MPLS], for example when a reservation gets rejected by admission control, or when a label can't be associated 🧚.
6.4. Non-support of the CLASSTYPE Object 💅
so what happens if an LSR doesn't know what CLASSTYPE even is? 🙈
An LSR that doesn't recognize the CLASSTYPE object Class-Num MUST behave according to the procedures in [RSVP] for an unknown Class-Num whose format is 0bbbbbbb. In other words, it MUST send a PathErr with the error code "Unknown object class" toward the sender.
An LSR that recognizes the CLASSTYPE object Class-Num but doesn't recognize the CLASSTYPE object C-Type MUST behave according to the procedures in [RSVP] for an unknown C-type. In other words, it MUST send a PathErr with the error code "Unknown object C-Type" toward the sender.
Both of the above situations make the path setup fail 😭. The sender SHOULD notify the operator/management system that an LSP can't be established, and it might take action to retry the reservation establishment without the CLASSTYPE object.
6.5. Error Codes for Diffserv-aware TE 🍓
In the procedures we just went through, certain errors get reported as a "Diffserv-aware TE Error". The value of the "Diffserv-aware TE Error" error code is 28 ✨.
Here's the table that defines the error values for the Diffserv-aware TE Error:
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured
TE-Class
5 Class-Type and holding priority do not form a
configured TE-Class
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-TypeFor any additional values, see the IANA Considerations section for how they get allocated 👑.
7. DS-TE Support with MPLS Extensions 🧚
okay so there are a bunch of extensions to the original base spec for signaling [RSVP-TE] and IGP support for TE [OSPF-TE][ISIS-TE]. They include enhancements for generalization ([GMPLS-SIG] and [GMPLS-ROUTE]), and they also add extra features like LSP hierarchy [HIERARCHY], link bundling [BUNDLE], and fast restoration [REROUTE] 💖. These specifications might explain how to encode info tied to certain preemption priorities, how to treat LSPs at different preemption priorities, or they might just specify encodings or behavior that means something different for a DS-TE router.
For an implementation to support both this Diffserv-aware TE spec and a given MPLS enhancement, like the ones listed above (but not limited to those), it MUST treat references to "preemption priority" and to "Maximum Reservable Bandwidth" in a generalized manner. That means the way this spec uses those terms 🦋.
Also, current and future MPLS enhancements might get more precise about how they work with Diffserv-aware TE 🌸.
7.1. DS-TE Support and References to Preemption Priority 💅
When a router supports both Diffserv-aware TE and one of the MPLS protocol extensions mentioned above, any encoding of preemption priority values in signaling, or any encoding of info tied to preemption priorities in an IGP defined for the MPLS extension, MUST be treated as an encoding of the same information for the corresponding TE-Class. For example, if an MPLS enhancement says a parameter for routing info at preemption priority N gets advertised in the IGP, then in a DS-TE environment it MUST actually be interpreted as advertising that same routing info, but for TE-Class [N]. DS-TE routers MUST also interpret it that way when they receive it 🔥.
When there's discussion about how to treat LSPs of different preemption priority comparatively, a DS-TE LSR MUST treat the preemption priorities in that context as the ones associated with the TE-Classes of the LSPs in question ✨.
7.2. DS-TE Support and References to Maximum Reservable Bandwidth 🎀
When a router supports both Diffserv-aware TE and MPLS protocol extensions like the ones mentioned above, advertisements of Maximum Reservable Bandwidth MUST be done with the generalized interpretation defined in Section 4.1.1. That means it's the aggregate bandwidth constraint across all Class-Types 👑. It MAY also allow the optional advertisement of all BCs 🫶.
8. Constraint-Based Routing ✨
okay so picture this 🎀 an LSP whose Class-Type is set to CTc and whose setup preemption priority is set to p. That pair of CTc and p maps to one of the TE-Classes in the TE-Class mapping, and we'll call that one TE-Class[i] 💅.
The Constraint-Based Routing algorithm of a DS-TE LSR is still only required to do path computation that satisfies a single BC: the path has to fit in "Unreserved TE-Class [i]" as advertised by the IGP for every link. So the existing TE Constraint-Based Routing algorithm itself doesn't need any changes 🙌.
The Constraint-Based Routing algorithm MAY also take into account, when used, the optional extra info advertised in the IGP, like the BCs and the Maximum Reservable Bandwidth. For example, the BCs MIGHT be used as tie-breakers when several paths are equally attractive 🦋.
9. Diffserv Scheduling 🌈
The Class-Type signaled at LSP establishment MAY optionally be used by DS-TE LSRs to dynamically adjust the resources the Diffserv scheduler gives the Class-Type. Also, the Diffserv info (the PSC) signaled by the TE-LSP signaling protocols as specified in [DIFF-MPLS], if used, MAY optionally be used by DS-TE LSRs to dynamically adjust the resources the Diffserv scheduler allocates to a PSC/OA within a CT 🧚.
10. Existing TE as a Particular Case of DS-TE 👑
existing TE can be seen as a special case of DS-TE where:
(i) a single Class-Type is used,
(ii) all 8 preemption priorities are allowed for that Class-Type,
and
(iii) the following TE-Class mapping is used:
TE-Class[i] <--> < CT0 , preemption i >
Where 0 <= i <= 7.In that case, DS-TE behaves just like existing TE ✨.
As with existing TE, the IGP advertises:
- Unreserved Bandwidth for each of the 8 preemption priorities.
As with existing TE, the IGP may advertise:
- Maximum Reservable Bandwidth containing a BC applying across all LSPs.
Because all LSPs carry traffic from CT0, RSVP-TE signaling happens without explicit signaling of the Class-Type (which only gets used for Class-Types other than CT0, as explained in Section 6), just like existing TE 💖.
11. Computing "Unreserved TE-Class [i]" and Admission Control Rules 🎀
11.1. Computing "Unreserved TE-Class [i]"
let's start with existing TE. Details on admission control algorithms for TE LSPs, and therefore the formulas for computing unreserved bandwidth, are outside the current IETF work. That part is left for vendor differentiation 💅. This doesn't break interoperability, because TE schemes rely on each LSR advertising its own local view, in terms of Unreserved Bw, to other LSRs. So no matter which local admission control algorithm one LSR uses, Constraint-Based Routing on other LSRs can trust the advertised info to decide whether a new LSP will be accepted or rejected by that LSR. The only requirement is that an LSR advertises unreserved bandwidth values that match its own local admission control algorithm and take into account the holding preemption priority of established LSPs ✨.
In DS-TE, again, admission control details are left for vendor differentiation, and the formulas for computing unreserved bandwidth for TE-Class[i] are outside the scope of this spec. BUT DS-TE adds an extra rule for the LSR: the unreserved bandwidth values it advertises MUST reflect all the BCs relevant to the CT associated with TE-Class[i], following the Bandwidth Constraints Model. So the formulas for "Unreserved TE-Class [i]" depend on which Bandwidth Constraints Model is in use, and they MUST reflect how BCs apply to CTs 🔥. Example formulas for the Russian Dolls Model and the Maximum Allocation Model are given in [DSTE-RDM] and [DSTE-MAM] respectively 🪆.
As with existing TE, DS-TE LSRs MUST consider the holding preemption priority of established LSPs (not their setup preemption priority) when computing unreserved bandwidth for TE-Class [i] 🙈.
11.2. Admission Control Rules
A DS-TE LSR MUST support the following admission control rule 💅:
Regardless of how the admission control algorithm actually computes the unreserved bandwidth for TE-Class[i] on one of its local links, an LSP of bandwidth B, setup preemption priority p, and Class-Type CTc is admissible on that link if, and only if:
B <= Unreserved Bandwidth for TE-Class[i]where TE-Class [i] maps to < CTc , p > in the TE-Class mapping configured on the LSR.
12. Security Considerations 🔐
this document doesn't introduce any additional security threats beyond the ones described for Diffserv ([DIFF-ARCH]) and MPLS Traffic Engineering ([TE-REQ], [RSVP-TE], [OSPF-TE], [ISIS-TE]). The same security measures and procedures described in those documents apply here 🛡️. For example, the approach to defending against theft- and denial-of-service attacks discussed in [DIFF-ARCH], which combines traffic conditioning at DS boundary nodes with security and integrity of the network infrastructure within a Diffserv domain, may be followed when DS-TE is in use. Also, as [TE-REQ] points out, it is seriously important that changes to administratively configurable parameters (such as those related to DS-TE LSPs) are made in a secure manner by authorized entities 🚨😭.
13. IANA Considerations 📋
This document creates two new name spaces that IANA will manage. A number of assignments were also made from existing name spaces by IANA in this document. Let's go through them 💅.
13.1. A New Name Space for Bandwidth Constraints Model Identifiers
This document defines in Section 5.1 a "Bandwidth Constraints Model Id" field (name space) within the "Bandwidth Constraints" sub-TLV, for both OSPF and ISIS. IANA created this new name space and will maintain it. The field for this name space is 1 octet, and the IANA guidelines for assignments to it are as follows:
- values in the range 0-239 are to be assigned according to the "Specification Required" policy defined in [IANA-CONS].
- values in the range 240-255 are reserved for "Private Use" as defined in [IANA-CONS].
13.2. A New Name Space for Error Values under the "Diffserv-aware TE Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
This document defines, in Section 6.5, values 1 through 7 in that name space (see Section 13.3.5).
Future allocations of values in this name space are to be assigned by IANA using the "Specification Required" policy defined in [IANA-CONS].
13.3. Assignments Made in This Document
13.3.1. Bandwidth Constraints sub-TLV for OSPF Version 2
[OSPF-TE] creates a name space for the sub-TLV types within the "Link TLV" of the Traffic Engineering Link State Advertisement (LSA), along with rules for IANA management of this name space.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the OSPF "Link" TLV. Following the IANA considerations provided in [OSPF-TE], a sub-TLV type in the range 10 to 32767 was requested, and IANA has assigned the value 17 to the "Bandwidth Constraints" sub-TLV.
13.3.2. Bandwidth Constraints sub-TLV for ISIS
[ISIS-TE] creates a name space for the sub-TLV types within the ISIS "Extended IS Reachability" TLV, along with rules for IANA management of this name space.
This document defines in Section 5.1 a new sub-TLV, the "Bandwidth Constraints" sub-TLV, for the ISIS "Extended IS Reachability" TLV. Following the IANA considerations provided in [ISIS-TE], a sub-TLV type was requested, and IANA has assigned the value 22 to the "Bandwidth Constraints" sub-TLV.
13.3.3. CLASSTYPE Object for RSVP
[RSVP] defines the Class Number name space for RSVP objects, which IANA manages. Currently allocated Class Numbers are listed at http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.2.1 a new RSVP object, the CLASSTYPE object. IANA has assigned a Class Number for this RSVP object from the range defined in Section 3.10 of [RSVP] for objects that, if not understood, cause the entire RSVP message 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 class number (i.e., Class-Num = 0bbbbbbb).
IANA assigned Class-Number 66 to the CLASSTYPE object. C_Type 1 is defined in this document for the CLASSTYPE object.
13.3.4. "Diffserv-aware TE Error" Error Code
[RSVP] defines the Error Code name space and the rules for IANA management of this name space. Currently allocated Error Codes are listed at http://www.iana.org/assignments/rsvp-parameters.
This document defines in Section 6.5 a new RSVP Error Code, the "Diffserv-aware TE Error". Following the IANA considerations provided in [RSVP], IANA assigned Error Code 28 to the "Diffserv-aware TE Error".
13.3.5. Error Values for "Diffserv-aware TE Error"
An Error Code is an 8-bit quantity defined in [RSVP] that appears in an ERROR_SPEC object to define an error condition broadly. With each Error Code there may be a 16-bit Error Value (which depends on the Error Code) that further specifies the cause of the error.
This document defines in Section 6.5 a new RSVP error code, the "Diffserv-aware TE Error" (see Section 13.3.4). The Error Values for the "Diffserv-aware TE Error" constitute a new name space to be managed by IANA.
This document defines, in Section 6.5, the following Error Values for the "Diffserv-aware TE Error":
Value Error
1 Unexpected CLASSTYPE object
2 Unsupported Class-Type
3 Invalid Class-Type value
4 Class-Type and setup priority do not form a configured
TE-Class
5 Class-Type and holding priority do not form a configured
TE-Class
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-TypeSee Section 13.2 for allocation of other values in that name space.
14. Acknowledgements 🫶
We thank Martin Tatham, Angela Chiu, and Pete Hicks for their earlier contributions to this work. We also thank Sanjaya Choudhury for his thorough review and suggestions 💜.
Appendix A: Prediction for Multiple Path Computation 🔮
okay so sometimes a head-end has to compute paths for a bunch of LSPs in a super short window 🏃♀️. There's real upside in trying to predict what the n-th LSP does to the unreserved bandwidth before fresh IGP info shows up, so when it's time to path the (n+1)-th LSP, you aren't flying blind 👀. You get better load-distribution across multiple paths, and if the (n+1)-th LSP wouldn't fit on a link after the n-th one is set up, you dodge a Connection Admission Control (CAC) rejection 🙅♀️. Yes, there are some conceivable scenarios where things could get worse, but doing these predictions is more likely to make things better ✨. As a matter of fact, a number of network admins have chosen to use predictions when deploying existing TE 💅.
Such predictions are local matters, are optional, and are outside the scope of this specification 🫶.
Where such predictions are not used, the optional BC sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV need not be advertised in IGP for the purpose of path computation 🌸. Why? Because the information in the Unreserved Bw sub-TLV is all that Head-Ends need to do Constraint-Based Routing. Iconic, honestly 👑.
Where such predictions are used on head-ends, the optional BCs sub-TLV and the optional Maximum Reservable Bandwidth sub-TLV MAY be advertised in IGP 🦋. That's so the head-ends can predict as accurately as possible how an LSP affects unreserved bandwidth values for the LSPs that come after it 🧚.
Remember that actual admission control algorithms are left up to vendor differentiation 💁♀️. So predictions only work well when the head-end LSR's predictions are based on the same (or a very close) admission control algorithm as the one used by other LSRs. Otherwise it's a whole mess 😭.
Appendix B: Solution Evaluation 💜
B.1. Satisfying Detailed Requirements
okay this DS-TE Solution addresses all the scenarios presented in [DSTE-REQ] 🎀.
It also satisfies all the detailed requirements presented in [DSTE-REQ] ✅.
Now, the objective in the last paragraph of Section 4.7 of [DSTE-REQ], "Overbooking", is only partially addressed by this DS-TE solution 🙈. Through support of the "LSP size Overbooking" and "Link Size Overbooking" methods, the solution effectively lets CTs have different overbooking ratios, and lets overbooking be tweaked differently (collectively across all CTs) on different links 💖. But in a general sense, it does not let the effective overbooking ratio of every CT be tweaked differently in different parts of the network independently of other CTs. It also doesn't keep accurate bandwidth accounting of how different CTs mutually affect each other through shared BCs (such as the Maximum Reservable Bandwidth) 💀. So it's giving "mostly," not "fully" 🫠.
B.2. Flexibility
This DS-TE solution supports 8 CTs 🌈. It is entirely flexible as to how Traffic Trunks are grouped together into a CT 🍓.
B.3. Extendibility
A maximum of 8 CTs is considered more than comfortable by the authors of this document 😌. A maximum of 8 TE-Classes is considered sufficient by the authors too 💅. However, this solution could be extended to support more CTs or more TE-Classes if deemed necessary in the future. That would need additional IGP extensions beyond those specified in this document 🔧.
Although the prime objective of this solution is support of Diffserv-aware Traffic Engineering, its mechanisms are not tightly coupled with Diffserv ✨. This makes the solution amenable to, or more easily extendable for, other potential future Traffic Engineering applications 🦋.
B.4. Scalability
This DS-TE solution is expected to have a very small scalability impact compared to existing TE 📈.
From an IGP viewpoint, the amount of mandatory information to be advertised is identical to that of existing TE 🧠. One additional sub-TLV has been specified, but its use is optional, and it only contains a limited amount of static information (at most 8 BCs) 🫶.
We expect no noticeable impact on LSP Path computation because, just like existing TE, this solution only requires Constrained Shortest Path First (CSPF) to consider a single unreserved bandwidth value for any given LSP 🏆.
From a signaling viewpoint, we expect no significant impact, because the solution only requires processing of one additional item of information (the Class-Type). It also doesn't significantly increase the likelihood of CAC rejection 🙌. Note that DS-TE does have some inherent impact on LSP signaling, since it assumes different classes of traffic are split over different LSPs, so more LSPs need to be signaled 🤸♀️. But that comes from the DS-TE concept itself, not from the actual DS-TE solution discussed here 💜.
B.5. Backward Compatibility/Migration
This solution is expected to allow smooth migration from existing TE to DS-TE 🦋. That's because existing TE can be supported as a particular configuration of DS-TE ✨. So an "upgraded" LSR with a DS-TE implementation can directly interwork with an "old" LSR that only supports existing TE 🤝.
This solution is also expected to allow smooth migration when the number of CTs actually deployed goes up, since it only requires configuration changes 🎀. However, those changes need to be performed in a coordinated manner across the DS-TE domain, so get your group chat together first 📣.
Appendix C: Interoperability with Non-DS-TE Capable LSRs 🧚♀️
This DSTE solution allows operations in a hybrid network, where some LSRs are DS-TE capable and some are not, as may happen during migration phases 🌈. This appendix talks through the constraints and operations in those hybrid networks 🔍.
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 TE-domain 🫶.
Hybrid operations require that the TE-Class mapping in the DS-TE domain be configured so that:
- a TE-Class exists for CT0 for every preemption priority actually used in the TE domain, and
- the index in the TE-class mapping for each of these TE-Classes is equal to the preemption priority.
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-Classes in the TE-Class mapping 🍓:
i <---> CT preemption
====================================
2 CT0 2
3 CT0 3Another way to look at this: although the whole TE-class mapping does not have to be consistent with the TE domain, the subset of this TE-Class mapping that applies to CT0 effectively has to be consistent with the TE domain 🧐.
Hybrid operations also require that:
- non-DS-TE-capable LSRs be configured to advertise the Maximum Reservable Bandwidth, and
- DS-TE-capable LSRs be configured to advertise BCs (using the Max Reservable Bandwidth sub-TLV as well as the BCs sub-TLV, as specified in Section 5.1) 📡.
This lets DS-TE-capable LSRs identify non-DS-TE-capable LSRs unambiguously 🕵️♀️.
Finally, hybrid operations require that non-DS-TE-capable LSRs be able to accept Unreserved Bw sub-TLVs containing non-decreasing bandwidth values (i.e., with Unreserved [p] < Unreserved [q] with p < q) 🫠.
In such hybrid networks, the following apply:
- CT0 LSPs can be established by both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- CT0 LSPs can transit via (or terminate at) both DS-TE-capable LSRs and non-DS-TE-capable LSRs.
- LSPs from other CTs can only be established by DS-TE-capable LSRs.
- LSPs from other CTs can only transit via (or terminate at) DS-TE-capable LSRs.
Let's walk through an example to see how this all plays out 🎬:
LSR0--------LSR1----------LSR2
Link01 Link12
where:
LSR0 is a non-DS-TE-capable LSR
LSR1 and LSR2 are DS-TE-capable LSRsLet's assume again that preemptions 2 and 3 are used in the TE-domain, and that the following TE-Class mapping is configured on LSR1 and LSR2 💅:
i <---> CT preemption
====================================
0 CT1 0
1 CT1 1
2 CT0 2
3 CT0 3
rest unusedLSR0 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 Reservable Bandwidth = m10 (possibly = m01) for Link01 📶.
In IGP for Link01, LSR0 will advertise:
- Max Reservable Bw sub-TLV = <m01>
- Unreserved Bw sub-TLV = <CT0/0, CT0/1, CT0/2, CT0/3, CT0/4, CT0/5, CT0/6, CT0/7>
When LSR1 receives that advertisement, it will:
- understand that LSR0 is not DS-TE-capable, because it advertised a Max Reservable Bw sub-TLV and no Bandwidth Constraints sub-TLV, and
- conclude that only CT0 LSPs can transit via LSR0, and that only the values CT0/2 and CT0/3 are meaningful in the Unreserved Bw sub-TLV. LSR1 may effectively behave as if the six other values contained in the Unreserved Bw sub-TLV were set to zero 🧠.
In IGP for Link01, LSR1 will advertise:
- Max Reservable Bw sub-TLV = <m10>
- Bandwidth Constraints sub-TLV = <BC Model ID, x0, x1>
- Unreserved Bw sub-TLV = <CT1/0, CT1/1, CT0/2, CT0/3, 0, 0, 0, 0>
When LSR0 receives that advertisement, it will:
- ignore the Bandwidth Constraints sub-TLV (unrecognized) 🙃
- correctly process CT0/2 and CT0/3 in the Unreserved Bw sub-TLV, and use these values for CTO LSP establishment ✅
- incorrectly believe that the other values contained in the Unreserved Bw sub-TLV relate to other preemption priorities for CT0. It will never actually use those, though, since we assume that only preemptions 2 and 3 are used in the TE domain 🫣.
Normative References 📚💖
okay bestie, this is the reading list the spec leans on, so let's get it all in. Here are the normative ones, the stuff you need in order to implement this:
[DSTE-REQ] Le Faucheur, F. and W. Lai, "Requirements for Support
of Differentiated Services-aware MPLS Traffic
Engineering", RFC 3564, July 2003.
[MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon,
"Multiprotocol Label Switching Architecture", RFC 3031,
January 2001.
[TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and
J. McManus, "Requirements for Traffic Engineering Over
MPLS", RFC 2702, September 1999.
[OSPF-TE] Katz, D., Kompella, K. and D. Yeung, "Traffic
Engineering (TE) Extensions to OSPF Version 2", RFC
3630, September 2003.
[ISIS-TE] Smit, H. and T. Li, "Intermediate System to
Intermediate System (IS-IS) Extensions for Traffic
Engineering (TE)", RFC 3784, June 2004.
[RSVP-TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan,
V. and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
1 Functional Specification", RFC 2205, September 1997.
[DIFF-MPLS] Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
"Multi-Protocol Label Switching (MPLS) Support of
Differentiated Services", RFC 3270, May 2002.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[IANA-CONS] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.Informative References 🧠✨
these ones are the background reading. Totally worth a look if you want the full picture 🫶
[DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[DSTE-RDM] Le Faucheur,F., Ed., "Russian Dolls Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4127, June 2005.
[DSTE-MAM] Le Faucheur, F. and W. Lai, "Maximum Allocation
Bandwidth Constraints Model for Diffserv-aware Traffice
Engineering", RFC 4125, June 2005.
[DSTE-MAR] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for DiffServ-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, June
2005.
[GMPLS-SIG] Berger, L., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Functional Description", RFC 3471,
January 2003.
[GMPLS-ROUTE] Kompella, et al., "Routing Extensions in Support of
Generalized MPLS", Work in Progress.
[BUNDLE] Kompella, Rekhter, Berger, "Link Bundling in MPLS
Traffic Engineering", Work in Progress.
[HIERARCHY] Kompella, Rekhter, "LSP Hierarchy with Generalized MPLS
TE", Work in Progress.
[REROUTE] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute
Extensions to RSVP-TE for LSP Tunnels", RFC 4090, May
2005.Editor's Address 📬💅
this is where you find the editor, Francois Le Faucheur, if you need to reach out 🌸
Francois Le Faucheur
Cisco Systems, Inc.
Village d'Entreprise Green Side - Batiment T3
400, Avenue de Roumanille
06410 Biot-Sophia Antipolis
France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.comFull Copyright Statement ⚖️
Copyright (C) The Internet Society (2005).
ngl this part is a lot of legal-speak, but the gist is that this document is subject to the rights, licenses and restrictions in BCP 78. Except as set forth there, the authors keep all their rights 🔒
Also, this document and everything in it is provided on an "AS IS" basis. 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. no guarantees, babe 💀
Intellectual Property 🪪
the IETF takes no position on whether any Intellectual Property Rights might be claimed over the technology in this document, or on whether any license under those rights might or might not be available. It also doesn't say it has done any independent work to find such rights. For the procedures around rights in RFC documents, check BCP 78 and BCP 79 🦋
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF also invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org. 📩
Acknowledgement 🙏🌈
funding for the RFC Editor function is currently provided by the Internet Society. thank you, Internet Society 🫶✨
📦 where this page comes from
- ietf: rfc4124 2005-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms