RFC 3564

Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering

📅 published July 2003, from ietf

RFC 3564: Requirements for Support of Differentiated Services-aware MPLS Traffic Engineering 🎀

Okay bestie, let's get into RFC 3564 🦋 It's an Informational doc from July 2003, so it's giving "here's some useful information" and not an Internet standard. It came out of the Network Working Group and was written by F. Le Faucheur (Cisco Systems, Inc.) and W. Lai (AT&T). The header doesn't list any RFCs that it obsoletes or updates, so it's standing on its own 💅

Status of This Memo ✨

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 💜

This document presents Service Provider requirements for support of Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering (DS-TE).

Its goal is to give guidance for defining, picking and specifying a technical solution that meets these requirements. The spec for that solution itself is outside the scope of this document 🧚

It starts with a problem statement. Then it walks through example application scenarios that Service Providers have identified, where existing MPLS Traffic Engineering mechanisms fall short and Diff-Serv-aware Traffic Engineering can help. It also reviews the detailed requirements the technical solution needs to address. Finally, it identifies the evaluation criteria that should be considered when selecting and defining the technical solution ✨

Table of Contents 📋

Specification Requirements .......................................  2
1.  Introduction .................................................  3
    1.1.  Problem Statement ......................................  3
    1.2.  Definitions ............................................  3
    1.3.  Mapping of traffic to LSPs .............................  5
2.  Application Scenarios ........................................  6
    2.1.  Scenario 1: Limiting Proportion of Classes on a Link ...  6
    2.2.  Scenario 2: Maintain relative proportion of traffic ....  6
    2.3.  Scenario 3: Guaranteed Bandwidth Services ..............  8
3.  Detailed Requirements for DS-TE ..............................  9
    3.1.  DS-TE Compatibility ....................................  9
    3.2.  Class-Types ............................................  9
    3.3.  Bandwidth Constraints .................................. 11
    3.4.  Preemption and TE-Classes .............................. 12
    3.5.  Mapping of Traffic to LSPs ............................. 15
    3.6.  Dynamic Adjustment of Diff-Serv PHBs ................... 15
    3.7.  Overbooking ............................................ 16
    3.8.  Restoration ............................................ 16
4.  Solution Evaluation Criteria ................................. 16
    4.1.  Satisfying detailed requirements ....................... 17
    4.2.  Flexibility ............................................ 17
    4.3.  Extendibility .......................................... 17
    4.4.  Scalability ............................................ 17
    4.5.  Backward compatibility/Migration ....................... 17
    4.6.  Bandwidth Constraints Model ............................ 18
5.  Security Considerations ...................................... 18
6.  Acknowledgment ............................................... 18
7.  Normative References ......................................... 18
8.  Informative References ....................................... 19
9.  Contributing Authors ......................................... 20
10. Editors' Addresses ........................................... 21
11. Full Copyright Statement ..................................... 22

Specification Requirements 🔥

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

1. Introduction ✨

1.1. Problem Statement 💖

Diff-Serv is used by some Service Providers to build scalable network designs that support multiple classes of service. Lowkey genius 🧠

In some of these Diff-Serv networks, optimizing transmission resources across the whole network isn't the goal, so MPLS Traffic Engineering (TE) mechanisms may not be used.

In other networks, optimizing transmission resources is the goal. There, Diff-Serv mechanisms [DIFF-MPLS] may be combined with MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] [OSPF-TE] [RSVP-TE] that work on an aggregate basis across all Diff-Serv classes of service. In this setup, Diff-Serv and MPLS TE both bring their own benefits 🦋

To get fine-grained optimization of transmission resources and even better network performance and efficiency, as discussed in [TEWG-FW], it may be desirable to do traffic engineering per class instead of per aggregate. Mapping the traffic of a given Diff-Serv class of service onto its own separate LSP lets that traffic use the resources available to that class on both shortest paths and non-shortest paths. It can also follow paths that meet engineering constraints specific to that class. This is what we call "Diff-Serv-aware Traffic Engineering (DS-TE)" 👑

This document focuses exclusively on the specific environments that would benefit from DS-TE. Some examples include:

  • networks where bandwidth is scarce (e.g., transcontinental networks)
  • networks with significant amounts of delay-sensitive traffic
  • networks where the relative proportion of traffic across classes of service is not uniform

This document focuses on intra-domain operation. Inter-domain operation is not considered 🙈

1.2. Definitions 📖

For the convenience of the reader, the relevant Diff-Serv definitions ([DIFF-ARCH], [DIFF-NEW] and [DIFF-PDB]) are repeated here 💅

  • Behavior Aggregate (BA): a collection of packets with the same (Diff-Serv) codepoint crossing a link in a particular direction.
  • Per-Hop-Behavior (PHB): the externally observable forwarding behavior applied at a DS-compliant node to a Diff-Serv behavior aggregate.
  • PHB Scheduling Class (PSC): A PHB group for which a common constraint is that ordering of at least those packets belonging to the same microflow must be preserved.
  • Ordered Aggregate (OA): a set of BAs that share an ordering constraint. The set of PHBs that are applied to this set of Behavior Aggregates constitutes a PHB scheduling class.
  • Traffic Aggregate (TA): a collection of packets with a codepoint that maps to the same PHB, usually in a DS domain or some subset of a DS domain. A traffic aggregate marked for the foo PHB is referred to as the "foo traffic aggregate" or "foo aggregate" interchangeably. This generalizes the concept of Behavior Aggregate from a link to a network.
  • Per-Domain Behavior (PDB): the expected treatment that an identifiable or target group of packets will receive from "edge-to-edge" of a DS domain. A particular PHB (or, if applicable, list of PHBs) and traffic conditioning requirements are associated with each PDB.

We also repeat the following definition from [TE-REQ]:

  • Traffic Trunk: an aggregation of traffic flows of the same class which are placed inside a Label Switched Path. 🎀

In the context of this document, "flows of the same class" is to be interpreted as "flows from the same Forwarding Equivalence Class which are to be treated equivalently from the DS-TE perspective".

We refer to the set of TAs corresponding to the set of PHBs of a given PSC as a {TA}PSC. A given {TA}PSC will receive the treatment of the PDB associated with the corresponding PSC. In this document, we also loosely refer to a {TA}PSC as a "Diff-Serv class of service", or a "class of service". For example, the set of packets within a DS domain with a codepoint that maps to the EF PHB may form one {TA}PSC in that domain. As another example, the set of packets within a DS domain with a codepoint that maps to the AF11 or AF12 or AF13 PHB may form another {TA}PSC in that domain 🌈

We refer to the collection of packets that belong to a given Traffic Aggregate and are associated with a given MPLS Forwarding Equivalence Class (FEC) ([MPLS-ARCH]) as a <FEC/TA>.

We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC as a <FEC/{TA}PSC>.

1.3. Mapping of traffic to LSPs 🧚

A network may have multiple Traffic Aggregates (TAs) it wants to service. Recalling from [DIFF-MPLS], there are several options for how the set of <FEC/{TA}PSC> of a given FEC can be split into Traffic Trunks for mapping onto LSPs when running MPLS Traffic Engineering.

One option is to not split this set of <FEC/{TA}PSC>, so that each Traffic Trunk comprises traffic from all the {TA}/PSC. This option is typically used when aggregate traffic engineering is deployed using current MPLS TE mechanisms. In that case, all the <FEC/{TA}PSC> of a given FEC are routed collectively according to a single shared set of constraints and will follow the same path. Note that the LSP transporting such a Traffic Trunk is, by definition, an E-LSP as defined in [DIFF-MPLS] 💜

Another option is to split the different <FEC/{TA}PSC> of a given FEC into multiple Traffic Trunks based on the {TA}PSC. In other words, traffic from one given node to another is split, based on the "classes of service", into multiple Traffic Trunks. These are transported over separate LSPs and can potentially follow different paths through the network. DS-TE takes advantage of this and computes a separate path for each LSP. In doing so, DS-TE can take into account the specific requirements of the Traffic Trunk transported on each LSP (e.g., bandwidth requirement, preemption priority). Moreover, DS-TE can take into account the specific engineering constraints to be enforced for these sets of Traffic Trunks (e.g., limit all Traffic Trunks transporting a particular {TA}PSC to x% of link capacity). DS-TE achieves per-LSP constraint-based routing, with paths that match specific objectives of the traffic while forming the corresponding Traffic Trunk 🔥

For simplicity, and because this is the specific topic of this document, the paragraphs above in this section only considered splitting the traffic of a given FEC into multiple Traffic Aggregates based on {TA}PSC. However, it should be noted that, in addition to this, traffic from every {TA}PSC may also be split into multiple Traffic Trunks for load balancing purposes 🌸

2. Application Scenarios 🦋

2.1. Scenario 1: Limiting Proportion of Classes on a Link 💖

okay so picture this, bestie 🎀 an IP/MPLS network might need to carry a LOT of VoIP traffic compared to how much link capacity it has. like, 10,000 uncompressed calls at 20ms packetization gets you about 1Gbps of IP traffic, and that is seriously significant on an OC-48c based network 😭 and when stuff breaks (link or node failure), VoIP traffic can literally climb to the full bandwidth on certain links. chaotic 💀

for delay and jitter reasons, some network admins think it's undesirable to carry more than a certain percentage of VoIP traffic on any link 🫶 the rest of the link bandwidth can be used for other "classes of service" that don't care as much about delay/jitter (e.g., Best Effort Internet traffic) 🌸 figuring out what that "certain" percentage actually is? totally outside the scope of this requirements doc, so we're not going there ✨

during normal operations, VoIP traffic SHOULD be able to preempt other "classes of service" (if those other classes are designated as preemptable and have lower preemption priority) 🔥 that way it can use the shortest available path, only constrained by the maximum defined link utilization ratio/percentage of the VoIP class. main character energy 👑

existing TE mechanisms only let you do constraint based routing using a single bandwidth constraint shared by ALL "classes of service" 💀 which just doesn't cut it for what we need here. so this leads to the requirement for DS-TE to enforce a different bandwidth constraint for different "classes of service" 🦋 in the example above, the constraint for VoIP might be that "certain" percentage of each link's capacity, while the other classes might have their own constraints or get access to the rest of the link capacity 💅

2.2. Scenario 2: Maintain relative proportion of traffic 🧚

okay so suppose an IP/MPLS network supports 3 "classes of service" 🍓 the network admin wants to do Traffic Engineering to spread out the traffic load. and also, the proportion across those classes changes a LOT depending on the source/destination POPs 😭

with existing TE mechanisms, the proportion of traffic from each "class of service" on a given link will bounce around depending on stuff like:

  • the order the different TE-LSPs get established in
  • the preemption priority attached to the different TE-LSPs
  • link/node failure situations

and honestly? this can make it really hard, or even impossible, for the admin to configure the Diff-Serv PHBs (e.g., queue bandwidth) so that each "class of service" gets the treatment it deserves 🥺 which, again, leads to the requirement for DS-TE to enforce a different bandwidth constraint for different "classes of service" 💜 this could make sure that, no matter what order tunnels get routed in, no matter their preemption priority, and no matter the failure situation, the amount of traffic of each "class of service" routed over a link matches the Diff-Serv scheduler configuration on that link for the matching class (e.g., queue bandwidth) ✨

as an illustration of how DS-TE would handle this, the admin might set the service rate of Diff-Serv queues to (45%,35%,20%) for "classes of service" (1,2,3) respectively 🌈 then they'd split the traffic into separate Traffic Trunks for each "class of service" and attach a bandwidth to each LSP carrying those Traffic Trunks 🎀 the admin may also want to set preemption priorities on each LSP so the highest "class of service" gets the highest restoration priority and the medium one gets medium priority 🫶 then DS-TE could make sure that after a failure, "class of service" 1 traffic gets rerouted first, with first access at link capacity, without going over its 45% service rate of the link bandwidth 🔥 "class of service" 2 gets rerouted second, with second access at the link capacity, without going over its allotment 💅

now, if "class of service" 3 is the Best-Effort service, the requirement on DS-TE might be to make sure the total traffic across ALL "classes of service" doesn't go over the total link capacity of 100% 🦋 (as opposed to separately limiting Best Effort traffic to 20 even when there's barely any "class of service" 1 and "class of service" 2 traffic 💀)

in this scenario, DS-TE would let the distribution stay pretty steady across the classes, even during rerouting ✨ and that would rely on the REQUIRED ability of DS-TE to adjust how much traffic of each "class of service" is routed on a link, based on the scheduler configuration and how much bandwidth is available for each "class of service" 💖

alternatively, some admins might want to solve this by having the scheduler dynamically adjusted based on how much bandwidth the LSPs admitted for each "class of service" carry 🧚 this is an OPTIONAL additional requirement on the DS-TE solution 🌸

2.3. Scenario 3: Guaranteed Bandwidth Services 👑

okay so on top of Best Effort service, an IP/MPLS network operator might want to offer a point-to-point "guaranteed bandwidth" service 🎀 where the provider promises a given level of performance (bandwidth/delay/loss...) end-to-end through its network, from an ingress port to an egress port 💅 the goal is that all the "guaranteed" traffic covered by a subscribed service level specification gets delivered within the tolerances of that spec ✨

one approach for deploying this "guaranteed" service involves:

  • dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in [DIFF-NEW]) to the "guaranteed" traffic
  • policing guaranteed traffic on ingress against the traffic contract and marking the "guaranteed" packets with the corresponding DSCP/EXP value
if the target is a very high level of performance for the "guaranteed" service, it may be necessary to make sure the amount of "guaranteed" traffic stays below a given percentage of link capacity on every link 😭 and when the proportion of "guaranteed" traffic is high, constraint based routing can be used to enforce that 🔥

but wait, the network operator may also want to do Traffic Engineering for the rest of the traffic (i.e., non-guaranteed traffic) at the same time 🙈 which would mean constraint based routing also has to enforce a different bandwidth constraint, one that's less strict than the one for guaranteed traffic 🦋

again, this combo of requirements can NOT be handled by existing TE mechanisms 💀 so DS-TE mechanisms that let you enforce a different bandwidth constraint for guaranteed traffic and for non-guaranteed traffic are REQUIRED 💜

  1. Detailed Requirements for DS-TE 🌈

this section spells out the functionality that the above scenarios need from the DS-TE solution 🎀 the actual technical protocol mechanisms and procedures to achieve that functionality are outside the scope of this document ✨

3.1. DS-TE Compatibility 🫶

since DS-TE may impact scalability (as discussed later in this document) and operational practices, DS-TE is expected to be used when existing TE mechanisms combined with Diff-Serv can't address the network design requirements (i.e., where constraint based routing is required and where it needs to enforce different bandwidth constraints for different "classes of service", like in the scenarios described above in section 2) 🔥 and if the benefits of DS-TE are only needed in a topological subset of their network, some network operators may want to deploy DS-TE in just that subset 🧚

so, the DS-TE solution MUST be developed in such a way that:

(i) it raises no interoperability issues with existing deployed TE mechanisms. (ii) it allows DS-TE deployment to the required level of granularity and scope (e.g., only in a subset of the topology, or only for the number of classes required in the considered network)

3.2. Class-Types 💅

the fundamental requirement for DS-TE is being able to enforce different bandwidth constraints for different sets of Traffic Trunks 💖

[TEWG-FW] introduces the concept of Class-Types when it talks about operations of MPLS Traffic Engineering in a Diff-Serv environment 🦋

we refine that definition into the following:

Class-Type (CT): the set of Traffic Trunks crossing a link,
that is governed by a specific set of Bandwidth constraints.
CT is used for the purposes of link bandwidth allocation,
constraint based routing and admission control.  A given
Traffic Trunk belongs to the same CT on all links.

note that different LSPs transporting Traffic Trunks from the same CT may be using the same or different preemption priorities, as explained in more detail in section 3.4 below ✨

mapping of {TA}PSC to Class-Types is flexible 🌸 different {TA}PSC can be mapped to different CTs, multiple {TA}PSC can be mapped to the same CT, and one {TA}PSC can be mapped to multiple CTs 🍓

for illustration, let's look at a network running 4 Diff-Serv PDBs, which are based on the EF PHB [EF], the AF1x PSC [AF], the AF2x PSC, and the Default (i.e., Best-Effort) PHB [DIFF-FIELD] 🧚 the network admin might deploy DS-TE like this:

  • from every DS-TE Head-end to every DS-TE Tail-end, split the traffic into 4 Traffic Trunks: one for traffic of each {TA}PSC
  • because the QoS objectives for the AF1x PDB and the AF2x PDB may be of a similar nature (e.g., both targeting low loss, albeit at different levels perhaps) 🥺 the same (set of) Bandwidth Constraint(s) may be applied collectively over the AF1x Traffic Trunks and the AF2x Traffic Trunks 💜 so the admin may only define three CTs: one for the EF Traffic Trunks, one for the AF1x and AF2x Traffic Trunks, and one for the Best Effort Traffic Trunks ✨

as another example of mapping {TA}PSC to CTs, a network operator may split the traffic from the {TA}PSC associated with EF into two different sets of traffic trunks 🎀 so each set is subject to different constraints on the bandwidth it can access 🔥 in this case, two distinct CTs are defined for the EF {TA}PSC traffic: one for the traffic subset under the first (set of) bandwidth constraint(s), and the other for the subset under the second (set of) bandwidth constraint(s) 🦋

the DS-TE solution MUST support up to 8 CTs 👑 those are referred to as CTc, 0 <= c <= MaxCT-1 = 7 💖 the DS-TE solution MUST be able to enforce a different set of Bandwidth Constraints for each CT 🫶 a DS-TE implementation MUST support at least 2 CTs, and MAY support up to 8 CTs 🌈

in a given network, the DS-TE solution MUST NOT require the network administrator to always deploy the maximum number of CTs 💅 the DS-TE solution MUST allow the network administrator to deploy only the number of CTs actually utilized 🧚

3.3. Bandwidth Constraints 💖

okay so a Bandwidth Constraint Model is basically the rulebook for two things: the maximum number of Bandwidth Constraints you get, and which CTs each one applies to and how. 📋

Remember how every CT is assigned either one Bandwidth Constraint or a whole set of them? That's the rule that makes all this work. 🎀

We call the Bandwidth Constraints BCb, where 0 <= b <= MaxBC-1. For any Class-Type CTc (0 <= c <= MaxCT-1), Reserved(CTc) is the sum of the bandwidth reserved by all established LSPs that belong to CTc. 🧮

There are lots of ways to set up Bandwidth Constraints for controlling CTs, bestie. 🌈

The first one is the "Maximum Allocation Model". It gives each CT its own separate Bandwidth Constraint, and it's defined like this:

MaxBC= MaxCT
for each value of b in the range 0 <= b <= (MaxCT - 1):
    Reserved (CTb) <= BCb

For illustration, say you've got a link with 100 units of bandwidth and three CTs in use. The network administrator might configure BC0=20, BC1= 50, BC2=30, which means:

  • All LSPs carrying Traffic Trunks from CT2 use no more than 30 (e.g., Voice <= 30) 🎙️
  • All LSPs carrying Traffic Trunks from CT1 use no more than 50 (e.g., Premium Data <= 50) 💎
  • All LSPs carrying Traffic Trunks from CT0 use no more than 20 (e.g., Best Effort <= 20) 🍓

The second one is the "Russian Doll" model 🪆, where the Bandwidth Constraints nest inside each other:

MaxBC= MaxCT
for each value of b in the range 0 <= b <= (MaxCT - 1):
    SUM (Reserved (CTc)) <= BCb,
    for all "c" in the range  b <= c <= (MaxCT - 1)

Same deal: 100 units of bandwidth, three CTs, and this time the admin might configure BC0=100, BC1= 80, BC2=60, which gives you:

  • All LSPs carrying Traffic Trunks from CT2 use no more than 60 (e.g., Voice <= 60) 🎤
  • All LSPs carrying Traffic Trunks from CT1 or CT2 use no more than 80 (e.g., Voice + Premium Data <= 80) ✨
  • All LSPs carrying Traffic Trunks from CT0, CT1 or CT2 use no more than 100 (e.g., Voice + Premium Data + Best Effort <= 100). 👑

Other models can also be dreamed up 💭. Those could involve arbitrary relationships between BCb and CTc, and they could also bring in extra ideas, like tying a minimum reservable bandwidth to a CT. Main character energy, honestly. 🦋

Now for the rules you actually have to follow 🫶. The DS-TE technical solution MUST have the capability to support multiple Bandwidth Constraints models. It MUST specify at least one bandwidth constraint model, and it MAY specify multiple Bandwidth Constraints models. Additional Bandwidth Constraints models MAY also be specified at a later stage, if they turn out to be useful based on operational experience from DS-TE deployments. Which model (or set of models) a given DS-TE implementation supports is an implementation choice 🔧.

For simplicity, a network operator may use the same Bandwidth Constraints Model on all the links of their network. But if they wish or need to, the operator may use different Bandwidth Constraints models on different links in the same network. 🌸

Whatever model you pick, the DS-TE solution MUST allow support for up to 8 BCs. 💅

3.4. Preemption and TE-Classes 🔥

[TEWG-FW] defines preemption and preemption priority. The DS-TE solution MUST retain full support of that preemption. However, a network administrator who prefers not to use preemption for user traffic MUST be able to disable the preemption mechanisms described below. Not everyone wants the drama, and that's valid. 🙈

The preemption attributes defined in [TE-REQ] MUST be retained and applicable across all Class Types. The setup priority and holding priority attributes MUST retain existing semantics, and these semantics MUST not be affected by the Ordered Aggregate carried by the LSP or by the LSP's Class Type. So if LSP1 is competing with LSP2 for resources, LSP1 may preempt LSP2 when LSP1 has a higher set-up preemption priority (i.e., lower numerical priority value) than LSP2's holding preemption priority. That's true no matter what OA/CT either LSP is using. 💜

Here's the new definition we're adding 📖:

TE-Class: A pair of:
       (i)    a Class-Type
       (ii)   a preemption priority allowed for that
              Class-Type.  This means that an LSP transporting a
              Traffic Trunk from that Class-Type can use that
              preemption priority as the set-up priority, as the
              holding priority or both.

Quick notes, by definition 🧠:

  • for a given Class-Type, there may be one or many TE-classes using that Class-Type, each with a different preemption priority
  • for a given preemption priority, there may be one or many TE-Class(es) using that preemption priority, each with a different Class-Type

The DS-TE solution MUST allow all LSPs carrying Traffic Trunks of a given Class-Type to use the same preemption priority. Put another way, it MUST allow a Class-Type to be used by a single TE-Class. This lets the network administrator make sure no preemption happens inside that Class-Type, whenever they want that 🛡️.

For example, the DS-TE solution MUST allow the network administrator to define a Class-Type made up of a single TE-class using preemption 0. 💖

The DS-TE solution MUST allow two LSPs carrying Traffic Trunks of the same Class-Type to use different preemption priorities. It MUST also let the LSP with the higher (numerically lower) set-up priority preempt the LSP with the lower (numerically higher) holding priority when they contend for resources. In other words, the DS-TE solution MUST allow multiple TE-Classes to be defined for a given Class-Type. This lets the network administrator turn on preemption within a Class-Type, whenever they want that ⚡.

For example, the DS-TE solution MUST allow the network administrator to define a Class-Type made up of three TE-Classes: one using preemption 0, one using preemption 1 and one using preemption 4. 🌈

The DS-TE solution MUST allow two LSPs carrying Traffic Trunks from different Class-Types to use different preemption priorities. It also MUST let the LSP with the higher setup priority preempt the one with the lower holding priority when they contend for resources. 🫧

For example, the DS-TE solution MUST allow the network administrator to define two Class-Types (CT0 and CT1), each made up of two TE-Classes. Say:

  • one TE-Class groups CT0 and preemption 0
  • one TE-Class groups CT0 and preemption 2
  • one TE-Class groups CT1 and preemption 1
  • one TE-Class groups CT1 and preemption 3

With that setup, the network administrator would be able to:

  • transport a CT0 Traffic Trunk over an LSP with setup priority=0 and holding priority=0 ✅
  • transport a CT0 Traffic Trunk over an LSP with setup priority=2 and holding priority=0 ✅
  • transport a CT1 Traffic Trunk over an LSP with setup priority=1 and holding priority=1 ✅
  • transport a CT1 Traffic Trunk over an LSP with setup priority=3 and holding priority=1 ✅

But the network administrator would not be able to:

  • transport a CT0 Traffic Trunk over an LSP with setup priority=1 and holding priority=1 ❌
  • transport a CT1 Traffic Trunk over an LSP with setup priority=0 and holding priority=0 ❌

The DS-TE solution MUST allow two LSPs carrying Traffic Trunks from different Class-Types to use the same preemption priority. Basically, the DS-TE solution MUST allow TE-classes using different CTs to share a preemption priority. That means the network administrator can make sure no preemption happens across Class-Types, if they want that 🕊️.

For example, the DS-TE solution MUST allow the network administrator to define three Class-Types (CT0, CT1 and CT2), each made up of one TE-Class using preemption 0. In that case, no preemption will ever occur. 🙌

There are 8 preemption priorities and up to 8 Class-Types, so in theory a network could have up to 64 TE-Classes. That's considered beyond current practical requirements. The current practical requirement is that the DS-TE solution MUST allow support for up to 8 TE-classes. The DS-TE solution MUST allow these TE-classes to be any arbitrary subset of 8 (or fewer) from the 64 possible combinations of 8 Class-Types and 8 preemption priorities. 🧩

Just like in existing TE, an LSP that gets preempted is torn down at preemption time. The Head-end of the preempted LSP may then try to reestablish it, which means recomputing a path by Constraint Based Routing based on updated available bandwidth information, then signaling for LSP establishment along the new path. 🔁

Heads up, though: there may be cases where the preempted LSP can't be reestablished (e.g., there's no possible path that satisfies the LSP's bandwidth constraints as well as its other constraints). 😭 In those cases, the Head-end behavior is left to implementation. It may involve periodic attempts at reestablishing the LSP, relaxing the LSP's constraints, or other behaviors.

3.5. Mapping of Traffic to LSPs 🗺️

The DS-TE solution MUST allow operation over E-LSPs onto which a single <FEC/{TA}PSC> is transported. ✨

The DS-TE solution MUST allow operation over L-LSPs. 🌷

The DS-TE solution MAY allow operation over E-LSPs onto which multiple <FEC/{TA}PSC> of a given FEC are transported, as long as DS-TE can treat those multiple <FEC/{TA}PSC> as a single atomic traffic trunk. This means they get routed as a whole, based on one collective bandwidth requirement, one affinity attribute, one preemption level, one Class-Type, and so on. 🧃

When that happens, it's also assumed that the multiple {TA}PSCs are grouped together in a consistent way throughout the DS-TE domain. For example, if <FECx/{TA}PSC1> and <FECx/{TA}PSC2> are transported together on an E-LSP, then there won't be any L-LSP carrying <FECy/{TA}PSC1> or <FECy/{TA}PSC2> on its own, and there won't be any E-LSP carrying <FECz/{TA}PSC1> and/or <FECz/{TA}PSC2> together with <FECz/{TA}PSC3>. Consistency is everything, bestie 🫶.

3.6. Dynamic Adjustment of Diff-Serv PHBs 🎀

As discussed in section 2.2, the DS-TE solution MAY support adjusting Diff-Serv PHB parameters (e.g., queue bandwidth) based on the number of TE-LSPs established for each OA/Class-Type. 📊 That dynamic adjustment is optional for DS-TE implementations, so no pressure. 💖

Where this dynamic adjustment is supported, it MUST allow for being disabled via configuration. Disabling it reverts you to PHB treatment with static scheduler configuration that's independent of DS-TE operations. 🔙 It MAY involve a number of configurable parameters that are outside the scope of this specification. Those MAY include configurable parameters that control how scheduling resources (e.g., service rates) get apportioned across multiple OAs when those OAs belong to the same Class-Type and are transported together on the same E-LSP. 🍰

Where it's supported, the dynamic adjustment MUST take account of the performance requirements of each PDB when computing the required adjustments. 🌟

3.7. Overbooking 💅

okay so overbooking isn't new bestie 🙈 existing TE already lets you overbook LSPs for Constraint Based Routing and admission control 🎀. Historically, people did it by factoring overbooking ratios in when sizing the LSP bandwidth, and/or when configuring the Maximum Reservable Bandwidth on links ✨.

The DS-TE solution MUST also allow overbooking and MUST effectively allow different overbooking ratios to be enforced for different CTs 💖. That's the whole "every class gets its own vibe" thing.

The DS-TE solution SHOULD optionally allow the effective overbooking ratio of a given CT to be tweaked differently in different parts of the network 🌸. Optional but lowkey iconic 🦋.

3.8. Restoration 🦋

With existing TE, restoration policies use standard priority mechanisms, like the preemption priority, to control the order and importance of LSPs for restoration 👑.

The DS-TE solution MUST ensure that similar application of the use of standard priority mechanisms for implementation of restoration policy are not prevented, since those are expected to be required for achieving the survivability requirements of DS-TE networks 🫶. Don't block the tools we need to keep things alive 😭.

Further discussion of restoration requirements are presented in the output document of the TEWG Requirements Design Team [SURVIV-REQ] 🧚.

4. Solution Evaluation Criteria 🔥

okay so a bunch of different solutions could support the DS-TE requirements we just went over 💅. Some might need all the current TE protocol syntax (IGP, RSVP-TE,) to be extended in different ways. For example, current TE protocols could be changed to support multiple bandwidth constraints instead of the existing single aggregate bandwidth constraint 🍓. Other solutions might keep the existing TE protocol syntax exactly the same and just change its semantics so it can handle multiple bandwidth constraints ✨.

This section identifies the evaluation criteria that MUST be used to assess potential DS-TE solutions for selection 👑. This is the scorecard, bestie 💀.

4.1. Satisfying detailed requirements ✨

The solution MUST address all the scenarios described in section 2 and satisfy all the requirements listed in section 3 🎀. No skipping the hard stuff 😤.

4.2. Flexibility 🦋

  • number of Class-Types that can be supported, compared to number identified in Requirements section
  • number of PDBs within a Class-Type

4.3. Extendibility 🌈

  • how far can the solution be extended in the future if requirements for more Class-Types are identified in the future

4.4. Scalability 💜

  • impact on network scalability in what is propagated, processed, stored and computed (IGP signaling, IGP processing, IGP database, TE-Tunnel signaling ,...).
  • how does scalability impact evolve with number of Class-Types/PDBs actually deployed in a network. In particular, is it possible to keep overhead small for a large networks which only use a small number of Class-Types/PDBs, while allowing higher number of Class-Types/PDBs in smaller networks which can bear higher overhead)

4.5. Backward compatibility/Migration 🫶

  • backward compatibility/migration with/from existing TE mechanisms
  • backward compatibility/migration when increasing/decreasing the number of Class-Types actually deployed in a given network

4.6. Bandwidth Constraints Model 🧚

Work is currently in progress to investigate the performance and trade-offs of different operational aspects of Bandwidth Constraints models (for example see [BC-MODEL], [BC-CONS] and [MAR]) 🔍. In this investigation, at least the following criteria are expected to be considered:

  • (1) addresses the scenarios in Section 2
  • (2) works well under both normal and overload conditions
  • (3) applies equally when preemption is either enabled or disabled
  • (4) minimizes signaling load processing requirements
  • (5) maximizes efficient use of the network
  • (6) Minimizes implementation and deployment complexity

In selection criteria (2), "normal condition" means that the network is attempting to establish a volume of DS-TE LSPs for which it is designed. "overload condition" means that the network is attempting to establish a volume of DS-TE LSPs beyond the one it is designed for. "works well" means that under these conditions, the network should be able to sustain the expected performance, e.g., under overload it is x times worse than its normal performance 📊.

5. Security Considerations 💀

The solution developed to address the DS-TE requirements defined in this document MUST address security aspects 🚨. Okay, this part is serious, so listen up 🙈. DS-TE does not raise any specific additional security requirements beyond the existing security requirements of MPLS TE and Diff-Serv 🔒. The solution MUST ensure that the existing security mechanisms (including those protecting against DOS attacks) of MPLS TE and Diff-Serv are not compromised by the protocol/procedure extensions of the DS-TE solution, or otherwise MUST provide security mechanisms to address this 🛡️. Do not let the new stuff break the old protections, periodt 😭.

6. Acknowledgment 🫶

We thank David Allen for his help in aligning with up-to-date Diff-Serv terminology 💖 slay, David 👑.

7. Normative References 📚

  • [AF] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999.
  • [DIFF-ARCH] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
  • [DIFF-FIELD] Nichols, K., Blake, S., Baker, F. and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
  • [MPLS-ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
  • [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.
  • [DIFF-NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
  • [EF] Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
  • [TEWG-FW] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X. Xiao, "Overview and Principles of Internet Traffic Engineering", RFC 3272, May 2002.
  • [TE-REQ] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J. McManus, "Requirements for Traffic Engineering over MPLS", RFC 2702, September 1999.
  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

8. Informative References 🧠

  • [DIFF-PDB] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.
  • [ISIS-TE] Smit, Li, "IS-IS extensions for Traffic Engineering", Work in Progress, December 2002.
  • [OSPF-TE] Katz, et al., "Traffic Engineering Extensions to OSPF", Work in Progress, October 2002.
  • [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.
  • [SURVIV-REQ] Lai, W. and D. McDysan, "Network Hierarchy and Multilayer Survivability", RFC 3386, November 2002.
  • [BC-MODEL] Lai, W., "Bandwidth Constraints Models for Diffserv-aware MPLS Traffic Engineering: Performance Evaluation", Work in Progress, June 2002.
  • [BC-CONS] F. Le Faucheur, "Considerations on Bandwidth Constraints Models for DS-TE", Work in Progress, June 2002.
  • [MAR] Ash, J., "Max Allocation with Reservation Bandwidth Constraint Model for MPLS/DiffServ TE & Performance Comparisons", Work in Progress, May 2003.

9. Contributing Authors 🌸

This document was the collective work of several people. The text and content of this document was contributed by the editors and the co-authors listed below. (The contact information for the editors appears below.)

Martin Tatham                        Thomas Telkamp
BT                                   Global Crossing
Adastral Park, Martlesham Heath,     Oudkerkhof 51,  3512 GJ Utrecht
Ipswich IP5 3RE, UK                  The Netherlands
Phone: +44-1473-606349               Phone: +31 30 238 1250
EMail: martin.tatham@bt.com          EMail: telkamp@gblx.net

David Cooper                         Jim Boyle
Global Crossing                      Protocol Driven Networks, Inc.
960 Hamlin Court                     1381 Kildaire Farm Road #288
Sunnyvale, CA 94089, USA             Cary, NC 27511, USA
Phone: (916) 415-0437                Phone: (919) 852-5160
EMail: dcooper@gblx.net              EMail: jboyle@pdnets.com

Luyuan Fang                          Gerald R. Ash
AT&T Labs                            AT&T Labs
200 Laurel Avenue                    200 Laurel Avenue
Middletown, New Jersey 07748, USA    Middletown, New Jersey 07748,USA
Phone: (732) 420-1921                Phone: (732) 420-4578
EMail: luyuanfang@att.com            EMail: gash@att.com
Pete Hicks                           Angela Chiu
CoreExpress, Inc                     AT&T Labs-Research
12655 Olive Blvd, Suite 500          200 Laurel Ave.  Rm A5-1F13
St. Louis, MO 63141, USA             Middletown, NJ 07748, USA
Phone: (314) 317-7504                Phone: (732) 420-9061
EMail: pete.hicks@coreexpress.net    EMail: chiu@research.att.com

William Townsend                     Thomas D. Nadeau
Tenor Networks                       Cisco Systems, Inc.
100 Nagog Park                       300 Beaver Brook Road
Acton, MA 01720, USA                 Boxborough, MA  01719
Phone: +1 978-264-4900               Phone: +1-978-936-1470
EMail:btownsend@tenornetworks.com    EMail: tnadeau@cisco.com

Darek Skalecki
Nortel Networks
3500 Carling Ave,
Nepean K2H 8E9,
Phone: (613) 765-2252
EMail: dareks@nortelnetworks.com

10. Editors' Addresses 💌

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.com


Wai Sum Lai
AT&T Labs
200 Laurel Avenue
Middletown, New Jersey 07748, USA

Phone: (732) 420-3712
EMail: wlai@att.com

okay bestie, we made it to the very last section 🥹🎀 the legal stuff is lowkey boring, but the rules are important, so here's the whole copyright statement word for word. You can't rewrite legal wording and still trust it, so I'm keeping it exact 💅

Copyright (C) The Internet Society (2003).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
ngl the vibe here is: you can share it, you can build cool stuff on top of it 🦋 but you can't edit the original doc itself (no cutting out the copyright line, no swapping the name 🙅‍♀️) unless it's for making internet standards or translating it. And the permissions don't expire, ever 💜

Acknowledgement

funding for the RFC Editor function is currently provided by the Internet Society 💸🌸 so the people keeping these docs organised have their bills covered, and that's iconic 👑

📦 where this page comes from