RFC 3270
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services
RFC 3270: Multi-Protocol Label Switching (MPLS) Support of Differentiated Services 🎀
Part 1 of 12 💖 more parts are coming, bestie!
Okay so, the title block first 🧚 This is RFC 3270, titled "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services". It's a Standards Track doc from the Network Working Group, dated May 2002. F. Le Faucheur is the Editor, and the other authors are L. Wu, B. Davie (Cisco Systems), S. Davari (PMC-Sierra Inc.), P. Vaananen (Nokia), R. Krishnan (Axiowave Networks), P. Cheval (Alcatel) and J. Heinanen (Song Networks). The header doesn't show an affiliation for F. Le Faucheur or L. Wu 🤷♀️ And there's nothing in the header about obsoleting or updating any other RFC, so no drama there 💅
Status of This Memo 📜
This doc specifies an Internet standards track protocol for the Internet community, and it literally requests discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📖 Distribution of this memo is unlimited 🫶
Copyright Notice 🌸
Copyright (C) The Internet Society (2002). All Rights Reserved. 💜
Abstract ✨
Okay so this doc gives you a flexible solution for supporting Differentiated Services (Diff-Serv) over Multi-Protocol Label Switching (MPLS) networks 🦋
The solution lets the MPLS network administrator pick how Diff-Serv Behavior Aggregates (BAs) get mapped onto Label Switched Paths (LSPs), so they can best match their Diff-Serv, Traffic Engineering and protection goals in their own network 🎯 For example, the admin can decide whether different sets of BAs go onto the same LSP or onto separate LSPs. Main character energy for the admin 👑
Table of Contents 📚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2 EXP-Inferred-PSC LSPs (E-LSP) . . . . . . . . . . . . . . . . . 6
1.3 Label-Only-Inferred-PSC LSPs (L-LSP). . . . . . . . . . . . . . 7
1.4 Overall Operations. . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Relationship between Label and FEC. . . . . . . . . . . . . . . 8
1.6 Bandwidth Reservation for E-LSPs and L-LSPs . . . . . . . . . . 8
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models . 9
2.1 Label Forwarding Model for Diff-Serv LSRs . . . . . . . . . . . 9
2.2 Incoming PHB Determination. . . . . . . . . . . . . . . . . . .10
2.3 Outgoing PHB Determination With Optional Traffic Conditioning .11
2.4 Label Forwarding. . . . . . . . . . . . . . . . . . . . . . . .11
2.5 Encoding Diff-Serv Information Into Encapsulation Layer . . . .13
2.6 Diff-Serv Tunneling Models over MPLS. . . . . . . . . . . . . .13
3. Detailed Operations of E-LSPs. . . . . . . . . . . . . . . . . .22
3.1 E-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .22
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP . .23
3.3 Incoming PHB Determination On Incoming E-LSP. . . . . . . . . .23
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
E-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .24
3.5 Encoding Diff-Serv information into Encapsulation Layer On
Outgoing E-LSP. . . . . . . . . . . . . . . . . . . . . . . . .26
3.6 E-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .27
4. Detailed Operation of L-LSPs. . . . . . . . . . . . . . . . . .28
4.1 L-LSP Definition. . . . . . . . . . . . . . . . . . . . . . . .28
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP . .28
4.3 Incoming PHB Determination On Incoming L-LSP. . . . . . . . . .30
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing
L-LSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . .31
4.5 Encoding Diff-Serv Information into Encapsulation Layer on
Outgoing L-LSP. . . . . . . . . . . . . . . . . . . . . . . . .33
4.6 L-LSP Merging . . . . . . . . . . . . . . . . . . . . . . . . .34
5. RSVP Extension for Diff-Serv Support . . . . . . . . . . . . . .34
5.1 Diff-Serv related RSVP Messages Format. . . . . . . . . . . . .34
5.2 DIFFSERV Object . . . . . . . . . . . . . . . . . . . . . . . .35
5.3 Handling DIFFSERV Object. . . . . . . . . . . . . . . . . . . .37
5.4 Non-support of the DIFFSERV Object. . . . . . . . . . . . . . .40
5.5 Error Codes For Diff-Serv . . . . . . . . . . . . . . . . . . .40
5.6 Intserv Service Type. . . . . . . . . . . . . . . . . . . . . .41
6. LDP Extensions for Diff-Serv Support . . . . . . . . . . . . . .41
6.1 Diff-Serv TLV . . . . . . . . . . . . . . . . . . . . . . . . .42
6.2 Diff-Serv Status Code Values. . . . . . . . . . . . . . . . . .44
6.3 Diff-Serv Related LDP Messages. . . . . . . . . . . . . . . . .44
6.4 Handling of the Diff-Serv TLV . . . . . . . . . . . . . . . . .46
6.5 Non-Handling of the Diff-Serv TLV . . . . . . . . . . . . . . .49
6.6 Bandwidth Information . . . . . . . . . . . . . . . . . . . . .49
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and
Non-LC-FR Interfaces . . . . . . . . . . . . . . . . . . . . . .49
8. MPLS Support of Diff-Serv over LC-ATM Interfaces . . . . . . . .50
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms. .50
8.2 LSR Implementation With LC-ATM Interfaces . . . . . . . . . . .50
9. MPLS Support of Diff-Serv over LC-FR Interfaces. . . . . . . . .51
9.1 Use of Frame Relay Traffic parameters and Traffic Management
mechanisms. . . . . . . . . . . . . . . . . . . . . . . . . . .51
9.2 LSR Implementation With LC-FR Interfaces. . . . . . . . . . . .51
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .52
11. Security Considerations . . . . . . . . . . . . . . . . . . . .52
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . .52
APPENDIX A. Example Deployment Scenarios. . . . . . . . . . . . . .53
APPENDIX B. Example Bandwidth Reservation Scenarios . . . . . . . .58
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . .60
Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . . . .62
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . .641. Introduction 🦋
Okay, picture an MPLS domain [MPLS_ARCH] 🌊 When a stream of data goes along a common path, a Label Switched Path (LSP) can be set up using MPLS signaling protocols 🛤️ At the ingress Label Switch Router (LSR), each packet gets a label and is sent downstream. At each LSR along the LSP, the label is what gets used to forward the packet to the next hop. Labels doing all the work, iconic 💅
Now a Differentiated Service (Diff-Serv) domain [DIFF_ARCH] is where all the IP packets crossing a link that need the same Diff-Serv behavior are said to make up a Behavior Aggregate (BA) 🍓 At the ingress node of the Diff-Serv domain, packets get classified and marked with a Diff-Serv Code Point (DSCP) that matches their Behavior Aggregate. At each transit node, the DSCP is used to pick the Per Hop Behavior (PHB), which decides the scheduling treatment and, in some cases, the drop probability for each packet ✨
This doc specifies a solution for supporting the Diff-Serv Behavior Aggregates whose PHBs are currently defined (in [DIFF_HEADER], [DIFF_AF], [DIFF_EF]) over an MPLS network 🎀 It also has flexibility for easily supporting PHBs that might be defined in the future 🔮
This solution depends on using two types of LSPs together 🫶
- LSPs which can carry multiple Ordered Aggregates, so that the EXP field of the MPLS Shim Header tells the LSR which PHB to apply to the packet (covering both info about the packet's scheduling treatment and its drop precedence) 🌈
- LSPs which only carry a single Ordered Aggregate, so that the LSR infers the packet's scheduling treatment purely from the packet's label value, while the packet's drop precedence is conveyed in the EXP field of the MPLS Shim Header or in the encapsulating link layer specific selective drop mechanism (ATM, Frame Relay, 802.1) 🍭
As mentioned in [DIFF_HEADER], "Service providers are not required to use the same node mechanisms or configurations to enable service differentiation within their networks, and are free to configure the node parameters in whatever way that is appropriate for their service offerings and traffic engineering objectives". 🙈 So the solution in this doc gives Service Providers flexibility in choosing how Diff-Serv classes of service are Routed or Traffic Engineered within their domain (for example, separate classes of service supported via separate LSPs and Routed separately, or all classes of service supported on the same LSP and Routed together) 🧚
Because MPLS is path-oriented, it can potentially provide faster and more predictable protection and restoration capabilities in the face of topology changes than conventional hop by hop routed IP systems 💫 In this doc we refer to such capabilities as "MPLS protection". Those capabilities and their associated mechanisms are outside the scope of this spec, but we note that they may offer different levels of protection to different LSPs 🛡️ Since the solution here lets Service Providers choose how Diff-Serv classes of service are mapped onto LSPs, it also gives them flexibility in the level of protection provided to different Diff-Serv classes of service (for example, some classes of service can be supported by LSPs which are protected while other classes of service are supported by LSPs which are not protected) 💜
Furthermore, the solution specified in this doc achieves label space conservation and reduces the volume of label set-up/tear-down signaling where possible, by only using multiple LSPs for a given Forwarding Equivalent Class (FEC) [MPLS_ARCH] when it's useful or required 🌸 Efficiency is giving 🌷
This spec allows support of Differentiated Services for both IPv4 and IPv6 traffic transported over an MPLS network 🌐 This document only describes operations for unicast. Multicast support is for future study 🔜
The solution described in this doc does not preclude the signaled or configured use of the EXP bits to support Explicit Congestion Notification [ECN] at the same time as Diff-Serv over MPLS. However, techniques for supporting ECN in an MPLS environment are outside the scope of this document 🙇♀️ More parts coming, so stay tuned, bestie! 🎀
1.1 Terminology
okay so first things first 💅 the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read the way RFC 2119 explains them 🎀 that's the official rulebook for the capitalized requirement words, so pay attention to them!
bestie, you're expected to already know the vibe of [MPLS_ARCH], [MPLS_ENCAPS], [MPLS_ATM], and [MPLS_FR] 🦋 here's the cheat sheet:
FEC Forwarding Equivalency Class
FTN FEC-To-NHLFE Map
ILM Incoming Label Map
LC-ATM Label Switching Controlled-ATM (interface)
LC-FR Label Switching Controlled-Frame Relay (interface)
LSP Label Switched Path
LSR Label Switch Router
MPLS Multi-Protocol Label Switching
NHLFE Next Hop Label Forwarding Entryyou also need to be fluent in [DIFF_ARCH], [DIFF_HEADER], [DIFF_AF], and [DIFF_EF] 🌸 the DiffServ crew:
AF Assured Forwarding
BA Behavior Aggregate
CS Class Selector
DF Default Forwarding
DSCP Differentiated Services Code Point
EF Expedited Forwarding
PHB Per Hop Behaviorand then [DIFF_NEW] adds the next layer of drama 👑
OA Ordered Aggregate. The set of Behavior Aggregates which
share an ordering constraint.
PSC PHB Scheduling Class. The set of one or more PHB(s)
that are applied to the Behavior Aggregate(s) belonging
to a given OA. For example, AF1x is a PSC comprising
the AF11, AF12 and AF13 PHBs. EF is an example of PSC
comprising a single PHB, the EF PHB.these acronyms also show up, so keep them in your back pocket ✨
CLP Cell Loss Priority
DE Discard Eligibility
SNMP Simple Network Management Protocoland last but not least, this spec invents two of its own 🧚 they're the main characters of the whole doc
E-LSP EXP-Inferred-PSC LSP
L-LSP Label-Only-Inferred-PSC LSP1.2 EXP-Inferred-PSC LSPs (E-LSP)
okay so one single LSP can carry more than one OA 🌈 these LSPs can support up to eight BAs of a given FEC, no matter how many OAs those BAs stretch across. the LSR figures out which PHB to apply by looking at the EXP field of the MPLS Shim Header. that covers both the PSC and the drop preference 💖
we call these "EXP-inferred-PSC LSPs" (E-LSP) because the PSC of a packet on this LSP depends on that packet's EXP field value 💅
the mapping from the EXP field to the PHB (so, to the PSC and the drop precedence) for an LSP like this is either explicitly signaled at label set-up or comes from a pre-configured mapping 🎀
the detailed operations of E-LSPs are in section 3 below ✨
1.3 Label-Only-Inferred-PSC LSPs (L-LSP)
a separate LSP can be set up for a single <FEC, OA> pair 🦋 for these, the PSC gets explicitly signaled when the label is established, so once that's done the LSR can tell the PSC to apply just from the label value 🫶
when the Shim Header is used, the LSR's Drop Precedence for the labeled packet is carried inside the MPLS Shim Header in the EXP field 🌸 when the Shim Header isn't used (for example, MPLS Over ATM), the Drop Precedence is carried in the link layer header encapsulation using link layer specific drop precedence fields (for example, ATM CLP) 🍓
we call these "Label-Only-Inferred-PSC LSPs" (L-LSP) since the PSC can be fully inferred from the label alone, regardless of the EXP field value 💜 the detailed operations of L-LSPs are in section 4 below 🧚
1.4 Overall Operations
okay this is the part where the network admin gets to pick the combo 👑 for a given FEC, and unless media specific restrictions apply (see sections 7, 8 and 9 below), this spec allows any one of these combos inside an MPLS Diff-Serv domain:
- zero or any number of E-LSPs, and
- zero or any number of L-LSPs.
the network administrator chooses the actual combination from the allowed set, and also picks how the Behavior Aggregates actually get carried over that combo 🌈 they do this to best match their environment and goals for Diff-Serv support, Traffic Engineering and MPLS Protection ✨ the criteria for picking a combo are outside the scope of this spec 💅
for a given FEC there can be more than one LSP carrying the same OA, for example to load balance that OA 🦋 however, to respect ordering constraints, all packets of a given microflow (even if it spans multiple BAs of a given Ordered Aggregate) MUST be transported over the same LSP 🫶 and the other way around, each LSP MUST be capable of supporting all the (active) BAs of a given OA 🎀
examples of deployment scenarios are provided for information in APPENDIX A 🍓
1.5 Relationship between Label and FEC
[MPLS_ARCH] says in section 2.1. Overview that:
Some routers analyze a packet's network layer header not merely to choose the packet's next hop, but also to determine a packet's "precedence" or "class of service". They may then apply different discard thresholds or scheduling disciplines to different packets. MPLS allows (but does not require) the precedence or class of service to be fully or partially inferred from the label. In this case, one may say that the label represents the combination of a FEC and a precedence or class of service.'in line with that, we notice the following 🌸
- with E-LSPs, the label represents the combination of a FEC and the set of BAs transported over the E-LSP. when all the supported BAs are transported over an E-LSP, the label then represents the complete FEC 💖
- with L-LSPs, the label represents the combination of a FEC and an OA 🦋
1.6 Bandwidth Reservation for E-LSPs and L-LSPs
no matter which label binding protocol you use, E-LSPs and L-LSPs may be established with or without bandwidth reservation 🌈
establishing an E-LSP or L-LSP with bandwidth reservation means the bandwidth requirements for the LSP get signaled when the LSP is set up 💅 those signaled requirements may be used by LSRs at establishment time to do admission control of the signaled LSP over the Diff-Serv resources provisioned (for example via configuration, SNMP or policy protocols) for the relevant PSC(s) 🎀 they may also be used by LSRs at establishment time to adjust the Diff-Serv resources tied to the relevant PSC(s) (for example, adjusting PSC scheduling weight) ✨
heads up: establishing an E-LSP or L-LSP with bandwidth reservation does NOT mean per-LSP scheduling is required 🙈 since E-LSPs and L-LSPs are specified here for Differentiated Services, the forwarding treatment (scheduling and drop policy) is defined by the appropriate Diff-Serv PHB 👑 this forwarding treatment MUST be applied by the LSR at the granularity of the BA, and MUST be compliant with the relevant PHB specification 🫶
when bandwidth requirements are signaled at the establishment of an L-LSP, the signaled bandwidth is obviously tied to the L-LSP's PSC 🧚 so LSRs that use it for admission control may do admission control over the Diff-Serv resources dedicated to that PSC (for example, over the bandwidth guaranteed to the PSC through its scheduling weight) 🍓
when bandwidth requirements are signaled at the establishment of an E-LSP, the signaled bandwidth is tied to the whole LSP, and therefore to the set of PSCs it carries 💜 so LSRs that use it for admission control may do admission control over global resources shared by that set of PSCs (for example, over the total bandwidth of the link) 🌸
examples of scenarios with and without bandwidth reservation are provided for information in APPENDIX B ✨
2. Label Forwarding Model for Diff-Serv LSRs and Tunneling Models ✨
2.1 Label Forwarding Model for Diff-Serv LSRs
since different Ordered Aggregates of a given FEC can be carried over different LSPs, the label swapping decision of a Diff-Serv LSR clearly depends on the forwarded packet's Behavior Aggregate 🦋 also, the IP DS field of a forwarded packet may not be directly visible to an LSR, so the way to figure out the PHB for a received packet and to encode the PHB into a transmitted packet is different from a non-MPLS Diff-Serv Router 🫶
so to describe Label Forwarding by Diff-Serv LSRs, we model the LSR Diff-Serv label switching behavior, which has four stages 🌈
- Incoming PHB Determination (A)
- Outgoing PHB Determination with Optional Traffic Conditioning(B)
- Label Forwarding (C)
- Encoding of Diff-Serv information into Encapsulation Layer (EXP, CLP, DE, User_Priority) (D)
we'll go through each stage in more detail in the following sections 💅
obviously, to enforce the Diff-Serv service differentiation, the LSR MUST also apply the forwarding treatment that corresponds to the Outgoing PHB 🎀
this model is illustrated below 🧚
--Inc_label(s)(*)------------------------>I===I--Outg_label(s)(&)-->
\ I I \
\---->I===I I C I \-->I===I--Encaps->
I A I I===I--Outg_PHB->I===I I D I (&)
-Encaps->I===I--Inc_PHB->I B I \ /->I===I
(*) I===I \--------+
\----Forwarding-->
Treatment
(PHB)"Encaps" designates the Diff-Serv related information encoded in the MPLS Encapsulation layer (for example the EXP field, ATM CLP, Frame Relay DE, or 802.1 User_Priority) 🍓
(*) when the LSR behaves as an MPLS ingress node, the incoming packet may be received unlabelled 🌸
(&) when the LSR behaves as an MPLS egress node, the outgoing packet may be transmitted unlabelled 💖
this model is here to describe the functional operations of Diff-Serv LSRs, and it does not constrain actual implementation 🌈
2.2 Incoming PHB Determination
this stage determines which Behavior Aggregate the received packet belongs to 🦋
2.2.1 Incoming PHB Determination Considering a Label Stack Entry
sections 3.3 and 4.3 have the details on how to do incoming PHB Determination when you consider a given received label stack entry and/or received incoming MPLS encapsulation information, depending on the incoming LSP type and the incoming MPLS encapsulation 🫶
section 2.6 has the details on which label stack entry to consider for Incoming PHB Determination, depending on the supported Diff-Serv tunneling mode 👑
2.2.2 Incoming PHB Determination Considering IP Header
section 2.6 covers when the IP Header is to be considered for incoming PHB determination, depending on the supported Diff-Serv tunneling model 🧚 in those cases where the IP header is used, this stage works exactly like a non-MPLS IP Diff-Serv Router and uses the DS field to determine the incoming PHB 💅
2.3. Outgoing PHB Determination With Optional Traffic Conditioning 🎀
Okay so the traffic conditioning stage is totally optional 💅 An LSR may use it to do traffic conditioning, including Behavior Aggregate demotion or promotion. It's outside the scope of this spec, so we're not going there, ngl. For Diff-Serv over MPLS, we just need to note that the PHB an LSR actually enforces and tells downstream LSRs about (the "outgoing PHB") can be different from the PHB the previous LSR attached to the packet (the "incoming PHB") ✨
When there's no traffic conditioning stage, the "outgoing PHB" is simply the same as the "incoming PHB" 🦋
2.4. Label Forwarding 🧚
Okay this part is giving label-swapping realness 😭 [MPLS_ARCH] explains how an LSR swaps labels on incoming labeled packets using an Incoming Label Map (ILM), where each incoming label maps to one or multiple NHLFEs. It also explains how an LSR imposes labels on incoming unlabelled packets using a FEC-to-NHLFEs Map (FTN), where each incoming FEC maps to one or multiple NHLFEs 💖
Now, a Diff-Serv Context for a label is made up of:
LSP type (i.e., E-LSP or L-LSP)supported PHBsEncaps-->PHB mappingfor an incoming labelSet of PHB-->Encaps mappingsfor an outgoing label
This spec says that a Diff-Serv Context is stored in the ILM for each incoming label. ✨
[MPLS_ARCH] says the `NHLFE may also contain any other information needed in order to properly dispose of the packet'. Following that, this spec says a Diff-Serv Context is stored in the NHLFE for each outgoing label that is swapped or pushed 🌸
This Diff-Serv Context info gets populated into the ILM and the FTN when the label is established 🫶
If the label corresponds to an E-LSP and no EXP<-->PHB mapping has been explicitly signaled at LSP setup, the supported PHBs is filled in with the set of PHBs from the preconfigured EXP<-->PHB mapping, which we'll talk about below in section 3.2.1 🎀
If the label corresponds to an E-LSP and an EXP<-->PHB mapping has been explicitly signaled at LSP setup, the supported PHBs is filled in with the set of PHBs from the signaled EXP<-->PHB mapping 💜
If the label corresponds to an L-LSP, the supported PHBs is filled in with the set of PHBs forming the PSC that's signaled at LSP set-up 🦋
How the Encaps-->PHB mapping or the Set of PHB-->Encaps mappings get populated is defined below, in sections 3 and 4 🧚
[MPLS_ARCH] also says:
"If the ILM [respectively, FTN] maps a particular label to a set of NHLFEs that contain more than one element, exactly one element of the set must be chosen before the packet is forwarded. The procedures for choosing an element from the set are beyond the scope of this document. Having the ILM [respectively, FTN] map a label [respectively, a FEC] to a set containing more than one NHLFE may be useful if, e.g., it is desired to do load balancing over multiple equal-cost paths."
Following that, this spec allows an incoming label [respectively FEC] to be mapped, for Diff-Serv purposes, to multiple NHLFEs. For example, different NHLFEs might correspond to egress labels that support different sets of PHBs 🌈 When a label [respectively FEC] maps to multiple NHLFEs, the Diff-Serv LSR MUST choose one of the NHLFEs whose Diff-Serv Context says it supports the Outgoing PHB of the forwarded packet 🔥
When a label [respectively FEC] maps to multiple NHLFEs that support the Outgoing PHB, the procedure for choosing one of them is outside the scope of this document 🙈 This can happen when you want to load balance a Behavior Aggregate over multiple LSPs. In those situations, to respect ordering constraints, all packets of a given microflow MUST be transported over the same LSP 💅
2.5. Encoding Diff-Serv Information Into Encapsulation Layer 🍓
This stage decides how to encode the fields that carry Diff-Serv info in the transmitted packet (e.g., MPLS Shim EXP, ATM CLP, Frame Relay DE, 802.1 User_Priority) 💖
2.5.1. Encoding Diff-Serv Information Into Transmitted Label Entry 🎀
Sections 3.5 and 4.5 give you the details on how to encode Diff-Serv info into a transmitted label stack entry and/or transmitted MPLS encapsulation info. This depends on the outgoing LSP type and the MPLS encapsulation 🫶
Section 2.6 tells you which label stack entry to encode Diff-Serv info into, based on the supported Diff-Serv tunneling mode 🌸
2.5.2. Encoding Diff-Serv Information Into Transmitted IP Header ✨
To encode Diff-Serv info into the transmitted packet's IP header, this stage works exactly like a non-MPLS IP Diff-Serv Router. It encodes the DSCP of the Outgoing PHB into the DS field 🦋
Section 2.6 says when Diff-Serv Information Encoding should be done into the transmitted IP header, depending on the supported Diff-Serv tunneling mode 🧚
2.6. Diff-Serv Tunneling Models over MPLS 🌈
2.6.1. Diff-Serv Tunneling Models 👑
[DIFF_TUNNEL] looks at how Differentiated Services interacts with IP tunnels of various forms. MPLS LSPs aren't a form of "IP tunnels", since the MPLS encapsulating header doesn't contain an IP header, so MPLS LSPs aren't considered in [DIFF_TUNNEL]. Still, even though they aren't an "IP tunnel", MPLS LSPs are a form of "tunnel" 💅
From the Diff-Serv standpoint, LSPs share a few things in common with IP Tunnels:
- Intermediate nodes (i.e., Nodes somewhere along the LSP span) only see and operate on the "outer" Diff-Serv information.
- LSPs are unidirectional.
- The "outer" Diff-Serv information can be modified at any of the intermediate nodes.
But from the Diff-Serv standpoint, LSPs also have one distinctive difference from IP Tunnels 👀
- There's generally no behavior analogous to Penultimate Hop Popping (PHP) used with IP Tunnels. Also, PHP means the "outer" Diff-Serv information associated with the LSP isn't visible to the LSP egress. Where that info isn't meaningful at the LSP Egress, this is obviously not an issue at all. Where it is meaningful at the LSP Egress, it must be carried some other way 😭
The two conceptual models for Diff-Serv tunneling over IP Tunnels defined in [DIFF_TUNNEL] also apply to, and are useful for, Diff-Serv over MPLS. Their detailed operations are a bit different over MPLS, though 🫶 These two models are the Pipe Model and the Uniform Model. Their operations over MPLS are specified in the following sections. Discussing and defining alternative tunneling models is outside the scope of this specification 💜
2.6.2. Pipe Model 🎀
okay so the Pipe Model is giving "hide the messy middle" energy 💅. MPLS tunnels (aka LSPs) are used to hide the intermediate MPLS nodes between LSP Ingress and LSP Egress from the Diff-Serv point of view ✨
In this model, tunneled packets have to carry two meaningful pieces of Diff-Serv info 🫶
- the Diff-Serv info that intermediate nodes along the LSP span (including the LSP Egress) care about, which we call the "LSP Diff-Serv Information". This one is NOT meaningful beyond the LSP Egress. So even if Traffic Conditioning at intermediate nodes on the LSP span changes the LSP Diff-Serv information, that updated info isn't considered meaningful past the LSP Egress and just gets ignored 🙈
- the Diff-Serv info that IS meaningful beyond the LSP Egress, which we call the "Tunneled Diff-Serv Information". The LSP Ingress has to convey this to the LSP Egress. The intermediate nodes on the LSP span don't care about it at all 💖
Operation of the Pipe Model without PHP is illustrated below:
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E (M*)
(M) represents the "LSP Diff-Serv information"
(m) represents the "Tunneled Diff-Serv information"
(*) The LSP Egress considers the LSP Diff-Serv information received
in the outer header (i.e., before the pop) in order to apply its
Diff-Serv forwarding treatment (i.e., actual PHB)
I represents the LSP ingress node
E represents the LSP egress nodeWith the Pipe Model, the "LSP Diff-Serv Information" needs to get to the LSP Egress so it can apply its forwarding treatment based on it. The "Tunneled Diff-Serv information" also needs to get to the LSP Egress so it can be conveyed further downstream 🧚
Since both of those require Diff-Serv info to reach the LSP Egress, the Pipe Model only works without PHP 🙅♀️
The Pipe Model is especially giving for environments in which:
- the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
- the outgoing interface of the LSP Egress is in the (last) Diff-Serv domain spanned by the LSP
For example, say a service provider is offering an MPLS VPN service (see [MPLS_VPN] for an example of MPLS VPN architecture) that includes Diff-Serv differentiation. A collection of sites is interconnected via that MPLS VPN service. This collection of sites is managed under one common administration and also supports Diff-Serv service differentiation. If the VPN site administration and the Service Provider aren't sharing the exact same Diff-Serv policy (for instance, not supporting the same number of PHBs), then running Diff-Serv in the Pipe Model over the MPLS VPN service lets the VPN Sites Diff-Serv policy work consistently across the ingress VPN Site and Egress VPN Site, and transparently over the Service Provider Diff-Serv domain. It's useful to think of these LSPs as linking the Diff-Serv domains at their endpoints into a single Diff-Serv region, making those endpoints virtually contiguous even though intermediate network nodes physically separate them 🌈
The Pipe Model MUST be supported. 🔥
For support of the Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the following manner:
- when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop.
- when performing a push operation for the considered LSP, the LSR:
- encodes Diff-Serv Information corresponding to the OUTGOING PHB in the transmitted label entry corresponding to the pushed label.
- encodes Diff-Serv Information corresponding to the INCOMING PHB in the encapsulated header (swapped label entry or IP header).
- when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label
- when performing a pop operation for the considered LSP, the LSR does not perform Encoding of Diff-Serv Information into the header exposed by the pop operation (i.e., the LSR leaves the exposed header "as is").
2.6.2.1. Short Pipe Model 🦋
The Short Pipe Model is an optional variation of the Pipe Model we just covered. The only difference is that with the Short Pipe Model, the Diff-Serv forwarding treatment at the LSP Egress is applied based on the "Tunneled Diff-Serv Information" (i.e., Diff-Serv information conveyed in the encapsulated header) instead of the "LSP Diff-Serv information" (i.e., Diff-Serv information conveyed in the encapsulating header). It's the plot twist 👑
Operation of the Short Pipe Model without PHP is illustrated below:
========== LSP =============================>
---Swap--(M)--...--Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).....................Pop--(m)-->
I (inner header) E
(M) represents the "LSP Diff-Serv information"
(m) represents the "Tunneled Diff-Serv information"
I represents the LSP ingress node
E represents the LSP egress nodeSince the LSP Egress applies its forwarding treatment based on the "Tunneled Diff-Serv Information", the "LSP Diff-Serv information" doesn't need to be conveyed by the penultimate node to the LSP Egress. Thus the Short Pipe Model can also operate with PHP 🍓
Operation of the Short Pipe Model with PHP is illustrated below:
=========== LSP ============================>
---Swap--(M)--...--Swap------
/ (outer header) \
(M) (M)
/ \
>--(m)-Push.................(m).............Pop-(m)--E--(m)-->
I (inner header) P (M*)
(M) represents the "LSP Diff-Serv information"
(m) represents the "Tunneled Diff-Serv information"
(*) The Penultimate LSR considers the LSP Diff-Serv information
received in the outer header (i.e., before the pop) in order to
apply its Diff-Serv forwarding treatment (i.e., actual PHB)
I represents the LSP ingress node
P represents the LSP penultimate node
E represents the LSP egress nodeThe Short Pipe Model is especially giving for environments in which:
- the cloud upstream of the incoming interface of the LSP Ingress and the cloud downstream of the outgoing interface of the LSP Egress are in Diff-Serv domains which use a common set of Diff-Serv service provisioning policies and PHB definitions, while the LSP spans one (or more) Diff-Serv domain(s) which use(s) a different set of Diff-Serv service provisioning policies and PHB definitions
- the outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it.
Since each outgoing interface of the LSP Egress is in the same Diff-Serv domain as the cloud downstream of it, each outgoing interface may potentially be in a different Diff-Serv domain, and the LSP Egress needs to be configured with awareness of every corresponding Diff-Serv policy. That's extra operational overhead, but it's justified in some situations where the respective downstream Diff-Serv policies are better suited to offering service differentiation over each egress interface than the common Diff-Serv policy used on the LSP span. An example is a Service Provider offering an MPLS VPN service where some VPN users request that their own VPN Diff-Serv policy control service differentiation on the dedicated link from the LSP Egress to the destination VPN site, instead of the Service Provider's Diff-Serv policy. It's giving customization 💅✨
The Short Pipe Model MAY be supported. 🌸
For support of the Short Pipe Model over a given LSP without PHP, an LSR performs the Incoming PHB Determination and the Diff-Serv information Encoding in the same manner as with the Pipe Model, with the following exception:
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the header (label entry or IP header) which is used to do the actual forwarding. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination AFTER the pop.
For support of the Short Pipe Model over a given LSP with PHP, an LSR performs Incoming PHB Determination and Diff-Serv information Encoding in the same manner as without PHP, with the following exceptions:
- the Penultimate LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In other words, when a pop operation is to be performed for the considered LSP, the Penultimate LSR performs Incoming PHB Determination BEFORE the pop.
Note that the behavior of the Penultimate LSR in the Short Pipe Mode with PHP is identical to the behavior of the LSP Egress in the Pipe Mode (necessarily without PHP) 🧚💜
2.6.3 Uniform Model ✨
okay bestie, the Uniform Model is giving "MPLS who?" 💅 From the Diff-Serv point of view, MPLS tunnels (aka LSPs) are basically just artifacts of the end-to-end path 🦋. Tunnels can be used for forwarding, but they don't really make a dent in Diff-Serv. In this model, every packet carries exactly one piece of Diff-Serv info that actually matters, and it always lives in the outermost label entry (or in the IP DSCP when the packet is sent unlabelled, like at the LSP egress). Any Diff-Serv info chilling in deeper label entries is not significant to intermediate nodes or to the tunnel egress, so it gets ignored 🙈. And if Traffic Conditioning at intermediate nodes on the LSP span changes the "outer" Diff-Serv info, that updated info is the one that counts at the LSP egress. The outer header is the main character 👑
Operation of the Uniform Model without PHP looks like this 🎀:
========== LSP =============================>
---Swap--(M)--...-Swap--(M)--Swap----
/ (outer header) \
(M) (M)
/ \
>--(M)--Push...............(x).......................Pop--(M)->
I (inner header) E(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node E represents the LSP egress node
And here's the Uniform Model with PHP 🌸:
========== LSP =========================>
---Swap-(M)-...-Swap------
/ (outer header) \
(M) (M)
/ \
>--(M)--Push..............(x)............Pop-(M)--E--(M)->
I (inner header) P(M) represents the Meaningful Diff-Serv information encoded in the corresponding header. (x) represents non-meaningful Diff-Serv information. I represents the LSP ingress node P represents the LSP penultimate node E represents the LSP egress node
The Uniform Model for Diff-Serv over MPLS is so clean: from the Diff-Serv perspective, everything works exactly the same as if MPLS wasn't being used at all 😭🫶. MPLS is entirely transparent to the Diff-Serv operations, periodt.
Use of the Uniform Model lets LSPs span Diff-Serv domain boundaries without needing any other measure in place, apart from an inter-domain Traffic Conditioning Agreement at the physical boundary between the Diff-Serv domains. Everything operates exclusively on the "outer" header, because the meaningful Diff-Serv information is always visible and modifiable in the outmost label entry. It's giving efficiency 🧚
The Uniform Model MAY be supported. ⭐
For support of the Uniform Model over a given LSP, an LSR handles Incoming PHB Determination and Diff-Serv information Encoding like this 💖:
- when receiving an unlabelled packet, the LSR performs Incoming PHB Determination considering the received IP Header.
- when receiving a labeled packet, the LSR performs Incoming PHB Determination considering the outer label entry in the received label stack. In particular, when a pop operation is to be performed for the considered LSP, the LSR performs Incoming PHB Determination BEFORE the pop. 👀
- when performing a push operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry corresponding to the pushed label. The Diff-Serv Information encoded in the encapsulated header (swapped label entry or IP Header) is of no importance. not even a little 💅
- when performing a swap-only operation for the considered LSP, the LSR encodes Diff-Serv Information in the transmitted label entry that contains the swapped label.
- when PHP is used, the Penultimate LSR needs to be aware of the "Set of PHB-->Encaps mappings" for the label corresponding to the exposed header (or the `PHB-->DSCP mapping') in order to perform Diff-Serv Information Encoding. Methods for providing this mapping awareness are outside the scope of this specification. As an example, the "PHB-->DSCP mapping" may be locally configured. As another example, in some environments, it may be appropriate for the Penultimate LSR to assume that the "Set of PHB-->Encaps mappings" to be used for the outgoing label in the exposed header is the "Set of PHB-->Encaps mappings" that would be used by the LSR if the LSR was not doing PHP. Note also that this specification assumes that the Penultimate LSR does not perform label swapping over the label entry exposed by the pop operation (and in fact that it does not even look at the exposed label). Consequently, restrictions may apply to the Diff-Serv Information Encoding that the Penultimate LSR can perform. For example, this specification does not allow situations where the Penultimate LSR pops a label corresponding to an E-LSP supporting two PSCs, while the header exposed by the pop contains label values for two L-LSPs each supporting one PSC, since the Diff-Serv Information Encoding would require selecting one label or the other. 🥺
Note that LSR behaviors for the Pipe, the Short Pipe and the Uniform Model only differ when doing a push or a pop 🧠. So Intermediate LSRs that perform swap-only operations for an LSP behave in exactly the same way, regardless of whether they're in the Pipe, Short Pipe or Uniform model. With a Diff-Serv implementation supporting multiple Tunneling Models, only LSRs acting as LSP Ingress, Penultimate LSR or LSP Egress need to be configured to operate in a particular Model. Signaling to associate a Diff-Serv tunneling model on a per-LSP basis is not within the scope of this specification. 💜
2.6.4 Hierarchy
Through the label stack mechanism, MPLS allows LSP tunneling to nest to any depth 🪆. With that nesting, the push of level N+1 takes place on a subsequent (or the same) LSR to the LSR doing the push for level N, while the pop of level N+1 takes place on a previous (or the same) LSR to the LSR doing the pop of level N. For a given level N LSP, the Ingress LSR doing the push and the LSR doing the pop (Penultimate LSR or LSP Egress) must operate in the same Tunneling Model (i.e., Pipe, Short Pipe or Uniform). However, there is no requirement for consistent tunneling models across levels, so LSPs at different levels may be operating in different Tunneling Models. mix and match, bestie 🌈
Hierarchical operations in the case of two levels of tunnels look like this:
+--------Swap--...---+
/ (outmost header) \
/ \
Push(2).................(2)Pop
/ (outer header) \
/ \
>>---Push(1)........................(1)Pop-->>
(inner header)(1) Tunneling Model 1 (2) Tunneling Model 2
Tunneling Model 2 may be the same as or may be different from Tunneling Model 1.
For a given LSP of level N, the LSR must perform the Incoming PHB Determination and the Diff-Serv information Encoding as specified in section 2.6.2, 2.6.2.1 and 2.6.3, according to the Tunneling Model of this level N LSP and independently of the Tunneling Model of other level LSPs. Each level gets its own vibe 💅✨
3. Detailed Operations of E-LSPs ✨
3.1 E-LSP Definition
E-LSPs are defined in section 1.2. 📖
Within a given MPLS Diff-Serv domain, all the E-LSPs relying on the pre-configured mapping are capable of transporting the same common set of 8, or fewer, BAs. Each of those E-LSPs may actually transport this full set of BAs or any arbitrary subset of it. 🎀
For a given FEC, two given E-LSPs using a signaled `EXP<-->PHB mapping' can support the same or different sets of Ordered Aggregates. Different E-LSPs, different vibes 🦋
3.2 Populating the `Encaps-->PHB mapping' for an incoming E-LSP
This section defines how the `Encaps-->PHB mapping' of the Diff-Serv Context is populated for an incoming E-LSP, so that Incoming PHB determination can happen 🚪
The Encaps-->PHB mapping' for an E-LSP is always of the form EXP-->PHB mapping'. always 💅
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the EXP-->PHB mapping' is populated based on the Preconfigured `EXP<-->PHB mapping', which is discussed below in section 3.2.1. 🫠
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the EXP-->PHB mapping' is populated as per the signaled `EXP<-->PHB mapping'. ✅
3.2.1 Preconfigured `EXP<-->PHB mapping'
LSRs supporting E-LSPs that use the preconfigured EXP<-->PHB mapping' must allow local configuration of this EXP<-->PHB mapping'. This mapping applies to all the E-LSPs established on this LSR without a mapping explicitly signaled at set-up time. 🛠️
The preconfigured `EXP<-->PHB mapping' must either be consistent at every E-LSP hop throughout the MPLS Diff-Serv domain spanned by the LSP, or appropriate remarking of the EXP field must be performed by the LSR whenever a different preconfigured mapping is used on the ingress and egress interfaces. Consistency is the vibe 🌸
In case the preconfigured EXP<-->PHB mapping' has not actually been configured by the Network Administrator, the LSR should use a default preconfigured EXP<-->PHB mapping' which maps all EXP values to the Default PHB. the fallback is giving safe 🫶
3.3 Incoming PHB Determination On Incoming E-LSP
This section defines how Incoming PHB Determination is carried out when the considered label entry in the received label stack corresponds to an E-LSP. This requires that the `Encaps-->PHB mapping' is populated as defined in section 3.2. 🧩
When considering a label entry corresponding to an incoming E-LSP for Incoming PHB Determination, the LSR:
- determines the
EXP-->PHB mapping' by looking up theEncaps-->PHB mapping' of the Diff-Serv Context associated in the ILM with the considered incoming E-LSP label. 🔍 - determines the incoming PHB by looking up the EXP field of the considered label entry in the `EXP-->PHB mapping' table. 🎯
3.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing E-LSP
This section defines how the `Set of PHB-->Encaps mappings' of the Diff-Serv Context is populated at label setup for an outgoing E-LSP, so that Diff-Serv information can be Encoded in the Encapsulation Layer 📦💖
3.4.1 `PHB-->EXP mapping'
An outgoing E-LSP must always have a PHB-->EXP mapping' as part of the Set of PHB-->Encaps mappings' of its Diff-Serv Context. non-negotiable 🔥
If the label corresponds to an E-LSP for which no EXP<-->PHB mapping' has been explicitly signaled at LSP setup, this PHB-->EXP mapping' is populated based on the Preconfigured `EXP<-->PHB mapping', which is discussed above in section 3.2.1. 🌷
If the label corresponds to an E-LSP for which an EXP<-->PHB mapping' has been explicitly signaled at LSP setup, the PHB-->EXP mapping' is populated as per the signaled `EXP<-->PHB mapping'. 💅
3.4.2 `PHB-->CLP mapping'
okay bestie, so if the LSP is leaving over an ATM interface that is not label switching controlled 🎀, then one PHB-->CLP mapping' gets added to the Set of PHB-->Encaps mappings' for this outgoing LSP. ✨ It gets filled in like this:
- it's a function of the PHBs supported on this LSP, and it can use the relevant entries for those PHBs from the Default
PHB-->CLP mapping'in section 3.4.2.1. other mappings are allowed too. 💅 and if someone standardizes a PHB-to-CLP mapping for Diff-Serv over ATM later, that standard mapping can be used instead.
for example, if the outgoing label is for an LSP supporting the AF1 PSC, the PHB-->CLP mapping' might look like this 🦋:
PHB CLP Field
AF11 ----> 0
AF12 ----> 1
AF13 ----> 1
EF ----> 0notice that the Set of PHB-->Encaps mappings' in this case has both a PHB-->EXP mapping' and a PHB-->CLP mapping'. it's giving two mappings, not one. 💖
3.4.2.1 Default PHB-->CLP mapping'
the default one is the baseline, lowkey the MVP 🌸:
PHB CLP Bit
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 03.4.3 PHB-->DE mapping'
okay so now the Frame Relay version 🧚. if the LSP is leaving over a Frame Relay interface that is not label switching controlled, one PHB-->DE mapping' gets added to the Set of PHB-->Encaps mappings' for this outgoing LSP, and it's filled in like this:
- it's a function of the PHBs supported on this LSP, and it can use the relevant entries for those PHBs from the Default
PHB-->DE mapping'in section 3.4.3.1. other mappings may be used as well. ✨ and if a PHB-to-DE mapping gets standardized for Diff-Serv over Frame Relay in the future, that standardized mapping may then be used.
notice that the Set of PHB-->Encaps mappings' here contains both a PHB-->EXP mapping' and a PHB-->DE mapping'. 🫶
3.4.3.1 Default PHB-->DE mapping'
PHB DE Bit
DF ----> 0
CSn ----> 0
AFn1 ----> 0
AFn2 ----> 1
AFn3 ----> 1
EF ----> 03.4.4 PHB-->802.1 mapping'
and now the LAN bit 🍓. if the LSP is leaving over a LAN interface that supports multiple 802.1 Traffic Classes as per [IEEE_802.1], one PHB-->802.1 mapping' gets added to the Set of PHB-->Encaps mappings' for this outgoing LSP. it gets populated like so:
- it's a function of the PHBs supported on this LSP, and it uses the relevant entries for those PHBs from the Preconfigured
PHB-->802.1 mapping'in section 3.4.4.1.
notice that the Set of PHB-->Encaps mappings' then contains both a PHB-->EXP mapping' and a PHB-->802.1 mapping'. 💅
3.4.4.1 Preconfigured PHB-->802.1 Mapping'
real talk 🙈: at the time this spec was written, there was no standardized mapping from PHBs to 802.1 Traffic Classes. so an LSR that supports multiple 802.1 Traffic Classes over LAN interfaces has to let someone configure a PHB-->802.1 mapping' locally. ⭐ that mapping applies to all the outgoing LSPs the LSR sets up on those LAN interfaces.
3.5 Encoding Diff-Serv information into Encapsulation Layer On Outgoing E-LSP
okay so this part is about how to actually write the Diff-Serv info into the MPLS encapsulation layer for a transmitted label entry on an outgoing E-LSP. 🎀 it only works if the Set of PHB-->Encaps mappings' was populated the way section 3.4 says.
first, the LSR figures out the Set of PHB-->Encaps mappings' in the Diff-Serv Context linked to the matching label in the NHLFE. 💖
3.5.1 PHB-->EXP mapping'
if the Set of PHB-->Encaps mappings' has a PHB-->EXP mapping', then the LSR:
- works out the value for the EXP field of the matching level label entry by looking up the "outgoing PHB" in that
PHB-->EXP mapping'table. 🧚
3.5.2 PHB-->CLP mapping'
if the Set of PHB-->Encaps mappings' has a PHB-->CLP mapping', then the LSR:
- works out the value for the CLP field of the ATM encapsulation header by looking up the "outgoing PHB" in that
PHB-->CLP mapping'table. 🦋
3.5.3 PHB-->DE mapping'
if the Set of PHB-->Encaps mappings' has a PHB-->DE mapping', then the LSR:
- works out the value for the DE field of the Frame Relay encapsulation header by looking up the "outgoing PHB" in that
PHB-->DE mapping'table. 🌈
3.5.4 PHB-->802.1 mapping'
if the Set of PHB-->Encaps mappings' has a PHB-->802.1 mapping', then the LSR:
- works out the value for the User_Priority field of the Tag Control Information in the 802.1 encapsulation header [IEEE_802.1] by looking up the "outgoing PHB" in that
PHB-->802.1 mapping'table. 👑
3.6 E-LSP Merging
okay this one is so iconic 😭. in an MPLS domain, two or more LSPs can be merged into one LSP at a single LSR. E-LSPs work with LSP Merging under one condition:
E-LSPs can only be merged into one LSP if they support the exact same set of BAs.
for E-LSPs using a signaled EXP<-->PHB mapping', LSRs MUST enforce the merge condition above by explicitly checking at label setup that the merged LSPs support the exact same set of PHBs. 🔥
for E-LSPs using the preconfigured EXP<-->PHB mapping', the PHBs supported over the E-LSP aren't signaled at establishment time. so an LSR can't rely on signaling info to enforce the merge. 🙈 but all E-LSPs using the preconfigured EXP<-->PHB mapping' are required to support the same set of Behavior Aggregates within a given MPLS Diff-Serv domain. so merging E-LSPs that use the preconfigured EXP<-->PHB mapping' is allowed within that domain. 🫶
4. Detailed Operation of L-LSPs ✨
4.1 L-LSP Definition
L-LSPs are defined in section 1.3. 🌸
4.2 Populating the `Encaps-->PHB mapping' for an incoming L-LSP
this section explains how the Encaps-->PHB mapping' of the Diff-Serv Context gets populated at label setup for an incoming L-LSP, so incoming PHB determination can happen. 💅
4.2.1 EXP-->PHB mapping'
if the LSR terminates the MPLS Shim Layer over this incoming L-LSP, and the L-LSP ingresses on an interface that is neither ATM nor Frame Relay, then the Encaps-->PHB mapping' gets populated like this:
- it's actually an
EXP-->PHB mapping'. - this mapping is a function of the PSC carried on this LSP, and must use the relevant entries for this PSC from the Mandatory
EXP/PSC-->PHB mapping'in Section 4.2.1.1.
for example, if the incoming label is for an L-LSP supporting the AF1 PSC, the Encaps-->PHB mapping' will be populated with:
EXP Field PHB
001 ----> AF11
010 ----> AF12
011 ----> AF13an LSR that supports L-LSPs over PPP interfaces and LAN interfaces is an example of an LSR terminating the Shim layer over ingress interfaces that are neither ATM nor Frame Relay. 🦋
if the LSR terminates the MPLS Shim Layer over this incoming L-LSP, and the L-LSP ingresses on an ATM or Frame Relay interface, then the Encaps-->PHB mapping' gets populated like so:
- it should actually be an
EXP-->PHB mapping'. alternative optional ways of populating theEncaps-->PHB mapping'might be defined in the future (e.g., using a 'CLP/EXP--> PHB mapping' or a 'DE/EXP-->PHB mapping'), but those are outside the scope of this document. 🍓 - when the
Encaps-->PHB mapping'is anEXP-->PHB mapping', that mapping is a function of the PSC carried on the L-LSP, and must use the relevant entries for this PSC from the MandatoryEXP/PSC-->PHB mapping'defined in Section 4.2.1.1.
an Edge-LSR of an ATM-MPLS domain or of a FR-MPLS domain is an example of an LSR terminating the shim layer over an ingress ATM/FR interface. 🌈
4.2.1.1 Mandatory EXP/PSC --> PHB mapping'
EXP Field PSC PHB
000 DF ----> DF
000 CSn ----> CSn
001 AFn ----> AFn1
010 AFn ----> AFn2
011 AFn ----> AFn3
000 EF ----> EF4.2.2 CLP-->PHB mapping'
if the LSR doesn't terminate an MPLS Shim Layer over this incoming label, and it uses ATM encapsulation (so it's an ATM-LSR), then the Encaps-->PHB mapping' for this incoming L-LSP gets populated like this:
- it's actually a
CLP-->PHB mapping'. - the mapping is a function of the PSC carried on this LSP, and should use the relevant entries for this PSC from the Default
CLP/PSC-->PHB mapping'in Section 4.2.2.1. 👑
for example, if the incoming label is for an L-LSP supporting the AF1 PSC, the Encaps-->PHB mapping' should be populated with:
CLP Field PHB
0 ----> AF11
1 ----> AF124.2.2.1 Default CLP/PSC --> PHB mapping'
CLP Bit PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF4.2.3 DE-->PHB mapping'
if the LSR doesn't terminate an MPLS Shim Layer over this incoming label, and it uses Frame Relay encapsulation (so it's a FR-LSR), then the Encaps-->PHB mapping' for this incoming L-LSP gets populated like this:
- it's actually a
DE-->PHB mapping'. - the mapping is a function of the PSC carried on this LSP, and should use the relevant entries for this PSC from the Default
DE/PSC-->PHB mapping'in Section 4.2.3.1. 🧚
4.2.3.1 Default DE/PSC --> PHB mapping'
DE Bit PSC PHB
0 DF ----> DF
0 CSn ----> CSn
0 AFn ----> AFn1
1 AFn ----> AFn2
0 EF ----> EF4.3 Incoming PHB Determination On Incoming L-LSP
this section explains how incoming PHB determination works when the label entry being considered in the received label stack corresponds to an L-LSP. it requires that the Encaps-->PHB mapping' gets populated as section 4.2 defines. 🦋
when an LSR is considering a label entry for an incoming L-LSP for incoming PHB determination, it first figures out the Encaps-->PHB mapping' linked to that label. 💖
4.3.1 EXP-->PHB mapping'
if the Encaps-->PHB mapping' is an EXP-->PHB mapping', then the LSR:
- works out the incoming PHB by looking at the EXP field of the label entry being considered and using the
EXP-->PHB mapping'. ✨
4.3.2 CLP-->PHB mapping'
if the Encaps-->PHB mapping' is a CLP-->PHB mapping', then the LSR:
- works out the incoming PHB by looking at the CLP field of the ATM Layer encapsulation and using the
CLP-->PHB mapping'. 🌸
4.3.3 `DE-->PHB mapping'
okay so if the Encaps-->PHB mapping' is the DE-->PHB mapping' type 💅, the LSR:
- figures out the incoming PHB by checking the DE field of the Frame Relay encapsulation and then running it through the
DE-->PHB mapping'🫶
4.4 Populating the `Set of PHB-->Encaps mappings' for an outgoing L-LSP
this section is all about how the Set of PHB-->Encaps mappings' of the Diff-Serv Context gets filled in at label setup for an outgoing L-LSP 🎀 so that Diff-Serv info can be encoded later. it's giving setup prep ✨
4.4.1 `PHB-->EXP mapping'
if the LSR runs an MPLS Shim Layer over this outgoing L-LSP, then one PHB-->EXP mapping' gets added to the Set of PHB-->Encaps mappings' for this outgoing L-LSP 🦋 and it gets filled in like this:
- it depends on the PSC supported on this LSP, and it must use the entries for that PSC from the Mandatory
PHB-->EXP mapping'in section 4.4.1.1.
for example, if the outgoing label is for an L-LSP supporting the AF1 PSC, then this PHB-->EXP mapping' gets added to the Set of PHB-->Encaps mappings':
PHB EXP Field
AF11 ----> 001
AF12 ----> 010
AF13 ----> 0114.4.1.1 Mandatory `PHB-->EXP mapping'
PHB EXP Field
DF ----> 000
CSn ----> 000
AFn1 ----> 001
AFn2 ----> 010
AFn3 ----> 011
EF ----> 0004.4.2 `PHB-->CLP mapping'
if the L-LSP is leaving on an ATM interface (so it's an ATM-LSR, or a frame-based LSR sending packets on an LC-ATM interface, or on an ATM interface that isn't label switching controlled) 🌸, then one PHB-->CLP mapping' gets added to the Set of PHB-->Encaps mappings' for this outgoing L-LSP.
if the L-LSP is leaving over an ATM interface that isn't label-controlled, the PHB-->CLP mapping' is filled in as per section 3.4.2 📦
if the L-LSP is leaving over an LC-ATM interface, the PHB-->CLP mapping' is filled in like this:
- it depends on the PSC supported on this LSP, and it should use the relevant entries for that PSC from the Default
PHB-->CLP mapping'in section 3.4.2.1.
heads up 👀: if the LSR is a frame-based LSR supporting an L-LSP leaving over an ATM interface, then the Set of PHB-->Encaps mappings' holds both a PHB-->EXP mapping' and a PHB-->CLP mapping'. if the LSR is an ATM-LSR supporting an L-LSP, then the Set of PHB-->Encaps mappings' only holds a PHB-->CLP mapping' 💖
4.4.3 `PHB-->DE mapping'
if the L-LSP is leaving over a Frame Relay interface (so it's an LSR sending packets on an LC-FR interface, or on a Frame Relay interface that isn't label switching controlled) 🧚, one PHB-->DE mapping' gets added to the Set of PHB-->Encaps mappings' for this outgoing L-LSP.
if the L-LSP is leaving over an FR interface that isn't label switching controlled, the PHB-->DE mapping' is filled in as per section 3.4.3 💜
if the L-LSP is leaving over an LC-FR interface, the PHB-->DE mapping' is filled in like this:
- it depends on the PSC supported on this LSP, and it should use the relevant entries for that PSC from the Default
PHB-->DE mapping'in section 3.4.3.1.
the tea ☕: if the LSR is an Edge-LSR supporting an L-LSP leaving over an LC-FR interface, then the Set of PHB-->Encaps mappings' holds both a PHB-->EXP mapping' and a PHB-->DE mapping'. if the LSR is a FR-LSR supporting an L-LSP, then the Set of PHB-->Encaps mappings' only holds a PHB-->DE mapping' 🌈
4.4.4 `PHB-->802.1 mapping'
if the LSP is leaving over a LAN interface that supports multiple 802.1 Traffic Classes, as defined in [IEEE_802.1], then one PHB-->802.1 mapping' gets added as per section 3.4.4 🍓
4.5 Encoding Diff-Serv Information into Encapsulation Layer on Outgoing L-LSP
this section explains how to encode Diff-Serv info into the MPLS encapsulation Layer for a transmitted label entry on an outgoing L-LSP ✨. it needs the Set of PHB-->Encaps mappings' to already be populated as defined in section 4.4 🫶
the LSR first looks up the Set of PHB-->Encaps mappings' of the Diff-Serv Context linked to the matching label in the NHLFE, and then does the matching encoding as specified in sections 3.5.1, 3.5.2, 3.5.3 and 3.5.4 💅
4.6 L-LSP Merging
in an MPLS domain, two or more LSPs can be merged into one LSP at one LSR 🦋. L-LSPs work with LSP Merging under this one condition:
L-LSPs can only be merged into one L-LSP if they support the same PSC.
and that merge condition MUST be enforced by LSRs 🔥, by explicitly checking at label setup that the same PSC is supported on the merged LSPs.
⚠️ bestie, pay attention here: when L-LSPs merge, the bandwidth available for the PSC downstream of the merge point must be sufficient to carry the sum of the merged traffic. this matters a LOT for EF traffic 😭. it can be ensured in a few ways (like provisioning, or bandwidth signaling and explicit admission control).
5. RSVP Extension for Diff-Serv Support ✨
the MPLS architecture doesn't assume a single label distribution protocol 🌸. [RSVP_MPLS_TE] defines the RSVP extension for setting up LSPs in MPLS networks. this section specifies the RSVP extensions, beyond those in [RSVP_MPLS_TE], for setting up LSPs that support Differentiated Services in MPLS networks 👑.
5.1 Diff-Serv related RSVP Messages Format
one new RSVP Object is defined in this document: the DIFFSERV Object 🎀. the details are below. this new Object applies to Path messages. this spec only defines using the DIFFSERV Object in Path messages used to set up LSP Tunnels per [RSVP_MPLS_TE], so those messages contain a Session Object with a C-Type equal to LSP_TUNNEL_IPv4 and a LABEL_REQUEST object.
the restrictions in [RSVP_MPLS_TE] for setting up LSP Tunnels via RSVP also apply to LSP Tunnels that support Diff-Serv: for instance, only unicast LSPs are supported, and Multicast LSPs are for further study 🧚.
the new DIFFSERV object is optional with respect to RSVP, so general RSVP implementations that don't care about MPLS LSP setup don't have to support it 🦋.
the DIFFSERV Object is optional for supporting LSP Tunnels as defined in [RSVP_MPLS_TE]. a Diff-Serv capable LSR supporting E-LSPs using the preconfigured EXP<-->PHB mapping' in compliance with this specification MAY support the DIFFSERV Object 💖. a Diff-Serv capable LSR supporting E-LSPs using a signaled EXP<-->PHB mapping' in compliance with this specification MUST support the DIFFSERV Object 🔥. a Diff-Serv capable LSR supporting L-LSPs in compliance with this specification MUST support the DIFFSERV Object 🫶.
5.1.1 Path Message Format
here's what the Path message looks like 📝:
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <DIFFSERV> ]
[ <POLICY_DATA> ... ]
[ <sender descriptor> ]
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ]
[ <RECORD_ROUTE> ]5.2 DIFFSERV Object
the DIFFSERV object formats are below 🌷. right now there are two possible C_Types. Type 1 is a DIFFSERV object for an E-LSP, and Type 2 is a DIFFSERV object for an L-LSP.
5.2.1. DIFFSERV object for an E-LSP:
class = 65, C_Type = 1
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 | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// ... //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved : 28 bits This field is reserved. it must be set to zero on transmission and must be ignored on receipt.
MAPnb : 4 bits Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 0 to 8.
MAP : 32 bits Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format:
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 | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved : 13 bits This field is reserved. it must be set to zero on transmission and must be ignored on receipt.
EXP : 3 bits This field contains the value of the EXP field for the `EXP<-->PHB mapping' defined in this MAP entry.
PHBID : 16 bits This field contains the PHBID of the PHB for the `EXP<-->PHB mapping' defined in this MAP entry. The PHBID is encoded as specified in [PHBID].
5.2.2 DIFFSERV object for an L-LSP:
class = 65, C_Type = 2
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 | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Reserved : 16 bits This field is reserved. it must be set to zero on transmission and must be ignored on receipt.
PSC : 16 bits The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in [PHBID].
5.3 Handling DIFFSERV Object ✨
okay so bestie, to set up an LSP tunnel with RSVP, the sender makes a Path message with a session type of LSP_Tunnel_IPv4 and a LABEL_REQUEST object, following [RSVP_MPLS_TE]. simple, iconic 💅
for an E-LSP tunnel with RSVP that uses the Preconfigured `EXP<-->PHB mapping'> 🎀, the sender makes a Path message:
- with a session type of
LSP_Tunnel_IPv4, - with the
LABEL_REQUESTobject, and - without the
DIFFSERVobject.
same E-LSP vibe, but the sender MAY alternatively make a Path message:
- with a session type of
LSP_Tunnel_IPv4, - with the
LABEL_REQUESTobject, and - with the
DIFFSERVobject for an E-LSP containing no MAP entries.
for an E-LSP tunnel using a signaled `EXP<-->PHB mapping'> 🦋, the sender makes a Path message:
- with a session type of
LSP_Tunnel_IPv4, - with the
LABEL_REQUESTobject, - with the
DIFFSERVobject for an E-LSP containing one MAP entry for each EXP value to be supported on this E-LSP.
and for an L-LSP tunnel with RSVP 🌸, the sender makes a Path message:
- with a session type of
LSP_Tunnel_IPv4, - with the
LABEL_REQUESTobject, - with the
DIFFSERVobject for an L-LSP containing the PHB Scheduling Class (PSC) supported on this L-LSP.
⚠️ if a Path message has multiple DIFFSERV objects, only the first one is meaningful. the rest must be ignored and not forwarded. no duplicates allowed, bestie 🙅♀️
every LSR along the path records the DIFFSERV object (when one is there) in its path state block 🧚
if the Path message has no DIFFSERV object, the LSR SHOULD read that as a request for an E-LSP using the Preconfigured `EXP<-->PHB mapping'>. ✨ BUT, for backward compatibility with the other non-Diff-Serv QoS options that [RSVP_MPLS_TE] allows, like Integrated Services Controlled Load or Guaranteed Services 💜, the LSR MAY support a configurable "override option". when that "override option" is configured, the LSR reads a Path message without a Diff-Serv object as a request for an LSP with that non-Diff-Serv QoS. ngl this is lowkey clever 🙈
if a DIFFSERV object for an E-LSP with no MAP entry shows up in the Path message, the LSR MUST read it as a request for an E-LSP using the Preconfigured EXP<-->PHB mapping'>. 💖 this means an LSR with the "override option" configured can support E-LSPs with Preconfigured EXP<-->PHB mapping'> AND LSPs with non-Diff-Serv QoS at the same time. both at once, iconic 👑
if a DIFFSERV object for an E-LSP with at least one MAP entry shows up in the Path message, the LSR MUST read it as a request for an E-LSP with signaled `EXP<-->PHB mapping'>. 🌈
if a DIFFSERV object for an L-LSP shows up in the Path message, the LSR MUST read it as a request for an L-LSP. 🔥
the destination LSR of an E-LSP or L-LSP answers the Path message that has the LABEL_REQUEST object by sending a Resv message:
- with the
LABELobject - without a
DIFFSERVobject.
if the label request is accepted and a label gets allocated, the Diff-Serv LSRs (sender, destination, and intermediate nodes) must:
- update the Diff-Serv Context tied to the established LSPs in their ILM/FTN, as described in the earlier sections (incoming and outgoing label),
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label). 🎀
an LSR that recognizes the DIFFSERV object, and gets a Path message that has the DIFFSERV object but NO LABEL_REQUEST object (or a session type that isn't LSP_Tunnel_IPv4), sends a PathErr back toward the sender with the error code Diff-Serv Error and the error value Unexpected DIFFSERV object. 🙃 these are defined in section 5.5 below.
an LSR that gets a Path message with the DIFFSERV object for an E-LSP, recognizes it, but doesn't support the particular PHB encoded in one or more of the MAP entries, sends a PathErr back toward the sender with the error code Diff-Serv Error and the error value Unsupported PHB. 💀 also defined in section 5.5.
an LSR that gets a Path message with the DIFFSERV object for an E-LSP, recognizes it, but decides the signaled EXP<-->PHB mapping'> is invalid, sends a PathErr back toward the sender with the error code Diff-Serv Errorand the error value InvalidEXP<-->PHB mapping'>. the EXP<-->PHB mapping'>, as signaled in the DIFFSERV` object for an E-LSP, is invalid when:
- the
MAPnbfield is not within the range 0 to 8, or - a given EXP value appears in more than one MAP entry, or
- the
PHBIDencoding is invalid.
defined in section 5.5, obviously 🙈
an LSR that gets a Path message with the DIFFSERV object for an L-LSP, recognizes it, but doesn't support the particular PSC encoded in the PSC field, sends a PathErr back toward the sender with the error code Diff-Serv Error and the error value Unsupported PSC. section 5.5 again 🧚
an LSR that gets a Path message with the DIFFSERV object, recognizes it, but can't allocate the required per-LSP Diff-Serv context, sends a PathErr with the error code "Diff-Serv Error" and the error value "Per-LSP context allocation failure". 😭 yup, section 5.5.
a Diff-Serv LSR MUST handle the situations where the label request can not be accepted for reasons other than the ones already covered in this section, following [RSVP_MPLS_TE] (for example, reservation rejected by admission control, or a label can not be associated). no skipping this one, periodt 💅
5.4 Non-support of the DIFFSERV Object
an LSR that does not recognize the DIFFSERV object Class-Num MUST behave as [RSVP] says for an unknown Class-Num whose format is 0bbbbbbb. so it must send a PathErr with the error code Unknown object class back toward the sender. 🥀
an LSR that recognizes the DIFFSERV object Class-Num but does not recognize the DIFFSERV object C-Type must behave as [RSVP] says for an unknown C-type. so it must send a PathErr with the error code Unknown object C-Type back toward the sender. 🙃
in both cases, the path setup fails 💔. the sender should notify management that an L-LSP can not be established, and should possibly try again without the DIFFSERV object (for example, fall back to E-LSPs with Preconfigured `EXP<-->PHB mapping'>). ✨ fallback era.
5.5 Error Codes For Diff-Serv
in the procedures above, certain errors must be reported as a Diff-Serv Error. the value of the Diff-Serv Error error code is 27. 🔢
the following error values are defined for the Diff-Serv Error:
Value Error
1 Unexpected DIFFSERV object
2 Unsupported PHB
3 Invalid `EXP<-->PHB mapping'
4 Unsupported PSC
5 Per-LSP context allocation failure5.6 Intserv Service Type
both E-LSPs and L-LSPs can be set up with or without bandwidth reservation 🌷.
as [RSVP_MPLS_TE] specifies, to set up an E-LSP or an L-LSP with bandwidth reservation, Int-Serv's Controlled Load service (or possibly Guaranteed Service) is used, and the bandwidth is signaled in the SENDER_TSPEC (respectively FLOWSPEC) of the Path (respectively Resv) message. 💪
as [RSVP_MPLS_TE] specifies, to set up an E-LSP or an L-LSP without bandwidth reservation, the Null Service specified in [NULL] is used. 🫶
note that this spec defines E-LSPs and L-LSPs only for supporting the Diff-Serv service. no matter which Intserv service is used (Controlled Load, Null Service, Guaranteed Service, and so on), and no matter whether the reservation has bandwidth or not, E-LSPs and L-LSPs here are for Diff-Serv services. supporting Int-Serv services over an MPLS Diff-Serv backbone is outside the scope of this spec 🚫.
also, this spec doesn't cover the DCLASS object defined in [DCLASS], since that object carries DSCP values, which don't matter inside the MPLS network 🧚.
6. LDP Extensions for Diff-Serv Support ✨
the MPLS architecture doesn't assume one single label distribution protocol. [LDP] defines the Label Distribution Protocol and how it's used to set up label switched paths (LSPs) in MPLS networks. this section specifies the extensions to LDP that set up LSPs supporting Differentiated Services in MPLS networks. 🦋
one new LDP TLV is defined in this document:
- the Diff-Serv TLV
we'll get into the details of this TLV below 👀.
the new Diff-Serv TLV is optional with respect to LDP. a Diff-Serv capable LSR that supports E-LSPs using the Preconfigured EXP<-->PHB mapping'> in compliance with this spec MAY support the Diff-Serv TLV. 💜 a Diff-Serv capable LSR that supports E-LSPs using the signaled EXP<-->PHB mapping'> in compliance with this spec MUST support the Diff-Serv TLV. 🔥 and a Diff-Serv capable LSR that supports L-LSPs in compliance with this spec MUST support the Diff-Serv TLV. 👑
6.1 Diff-Serv TLV 🎀
okay so the Diff-Serv TLV comes in two flavors, one for E-LSPs and one for L-LSPs 💅
Diff-Serv TLV for an E-LSP:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Diff-Serv (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | MAPnb |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAP (MAPnb) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- T:1 bit: LSP Type. This is set to 0 for an E-LSP.
- Reserved : 27 bits: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
- MAPnb : 4 bits: Indicates the number of MAP entries included in the DIFFSERV Object. This can be set to any value from 1 to 8.
- MAP : 32 bits: Each MAP entry defines the mapping between one EXP field value and one PHB. The MAP entry has the following format:
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 | EXP | PHBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Reserved : 13 bits: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
- EXP : 3 bits: This field contains the value of the EXP field for the `EXP<-->PHB mapping' defined in this MAP entry.
- PHBID : 16 bits: This field contains the PHBID of the PHB for the `EXP<-->PHB mapping' defined in this MAP entry. The PHBID is encoded as specified in [PHBID].
Diff-Serv TLV for an L-LSP:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type = PSC (0x0901) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Reserved | PSC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- T:1 bit: LSP Type. This is set to 1 for an L-LSP.
- Reserved : 15 bits: This field is reserved. It MUST be set to zero on transmission and MUST be ignored on receipt.
- PSC : 16 bits: The PSC indicates a PHB Scheduling Class to be supported by the LSP. The PSC is encoded as specified in [PHBID].
6.2 Diff-Serv Status Code Values ✨
the Status Code field of the Status TLV has these values, and they're iconic 👑
Status Code E Status Data
Unexpected Diff-Serv TLV 0 0x01000001
Unsupported PHB 0 0x01000002
Invalid `EXP<-->PHB mapping' 0 0x01000003
Unsupported PSC 0 0x01000004
Per-LSP context allocation failure 0 0x010000056.3 Diff-Serv Related LDP Messages 🦋
6.3.1 Label Request Message
the Label Request message gets extended so it can optionally include the Diff-Serv TLV 🌸
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Request (0x0401) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.3.2 Label Mapping Message
same vibe for the Label Mapping message, which also optionally gets the Diff-Serv TLV 🧚
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Mapping (0x0400) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.3.3 Label Release Message
the Label Release message gets extended to optionally include the Status TLV 💜
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Label Release (0x0403) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FEC TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Label TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.3.4 Notification Message
and the Notification message optionally picks up the Diff-Serv TLV too 🍓
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Optional Parameters |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Diff-Serv TLV (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+6.4 Handling of the Diff-Serv TLV 🫶
6.4.1 Handling of the Diff-Serv TLV in Downstream Unsolicited Mode
this part covers what happens when Downstream Unsolicited Mode is in use 🌈
When allocating a label for an E-LSP which is to use the preconfigured `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label Mapping message without the Diff-Serv TLV.
When allocating a label for an E-LSP which is to use a signaled `EXP<-->PHB mapping', a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an E-LSP which contains one MAP entry for each EXP value to be supported on this E-LSP.
When allocating a label for an L-LSP, a downstream Diff-Serv LSR issues a Label Mapping message with the Diff-Serv TLV for an L-LSP which contains the PHB Scheduling Class (PSC) to be supported on this L-LSP.
Assuming the label set-up is successful, the downstream and upstream LSRs MUST:
- update the Diff-Serv Context associated with the established LSPs in their ILM/FTN as specified in previous sections (incoming and outgoing label),
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
An upstream Diff-Serv LSR receiving a Label Mapping message with multiple Diff-Serv TLVs only considers the first one as meaningful. The LSR MUST ignore and not forward the subsequent Diff-Serv TLV(s).
An upstream Diff-Serv LSR which receives a Label Mapping message, with the Diff-Serv TLV for an E-LSP and does not support the particular PHB encoded in one or more of the MAP entries, MUST reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PHB'.
An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an E-LSP and determining that the signaled EXP<-->PHB mapping' is invalid, MUST reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of Invalid EXP<-->PHB mapping'. The `EXP<-->PHB mapping' signaled in the DIFFSERV Object for an E-LSP is invalid when:
- the MAPnb field is not within the range 1 to 8, or
- a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
An upstream Diff-Serv LSR receiving a Label Mapping message with the Diff-Serv TLV for an L-LSP containing a PSC value which is not supported, MUST reject the mapping by sending a Label Release message which includes the Label TLV and the Status TLV with a Status Code of `Unsupported PSC'.
6.4.2 Handling of the Diff-Serv TLV in Downstream on Demand Mode ✨
Okay bestie, this part is all about what happens when Downstream on Demand Mode is the mode in use 💅 Let's get into it.
When an upstream Diff-Serv LSR asks for a label for an E-LSP that uses the preconfigured `EXP<-->PHB mapping' 🌸, it sends a Label Request message without the Diff-Serv TLV. Simple, clean, no notes needed.
When an upstream Diff-Serv LSR asks for a label for an E-LSP that uses a signaled `EXP<-->PHB mapping' 🦋, it sends a Label Request message with the Diff-Serv TLV. That TLV is for an E-LSP and has one MAP entry for each EXP value that should be supported on this E-LSP.
When an upstream Diff-Serv LSR asks for a label for an L-LSP 🧚, it sends a Label Request message with the Diff-Serv TLV for an L-LSP. That TLV holds the PSC that should be supported on this L-LSP.
A downstream Diff-Serv LSR that sends a Label Mapping message in reply to a Label Request for an E-LSP or an L-LSP must not include a Diff-Serv TLV in that Label Mapping message. If the label setup works out, the downstream and upstream LSRs must:
- update the Diff-Serv Context linked to the established LSPs in their ILM/FTN, as described in the earlier sections (incoming and outgoing label),
- install the required Diff-Serv forwarding treatment (scheduling and dropping behavior) for this NHLFE (outgoing label).
If an upstream Diff-Serv LSR gets a Label Mapping message that has a Diff-Serv TLV in it, replying to its Label Request, it must reject that mapping. It does this by sending a Label Release message that includes the Label TLV and the Status TLV with a Status Code of `Unexpected Diff-Serv TLV' . Not vibing with that TLV, periodt 🙅♀️
A downstream Diff-Serv LSR that receives a Label Request message with multiple Diff-Serv TLVs only treats the first one as meaningful. It must ignore the subsequent Diff-Serv TLV(s) and must not forward them.
A downstream Diff-Serv LSR that gets a Label Request message with the Diff-Serv TLV for an E-LSP, and that doesn't support the particular PHB encoded in one (or more) of the MAP entries, must reject the request. It does this by sending a Notification message that includes the Status TLV with a Status Code of `Unsupported PHB' . 💀
A downstream Diff-Serv LSR that receives a Label Request message with the Diff-Serv TLV for an E-LSP, and that works out the signaled EXP<-->PHB mapping' `` `` is invalid, must reject the request. It does this by sending a Notification message that includes the Status TLV with a Status Code of Invalid `` `` EXP<-->PHB mapping' . The `EXP<-->PHB mapping' signaled in the DIFFSERV TLV for an E-LSP is invalid when:
- the
MAPnbfield is not within the range 1 to 8, or - a given EXP value appears in more than one MAP entry, or
- the PHBID encoding is invalid
A downstream Diff-Serv LSR that gets a Label Request message with the Diff-Serv TLV for an L-LSP, where the PSC value is not supported, must reject the request. It does this by sending a Notification message that includes the Status TLV with a Status Code of `Unsupported PSC' . 🫶
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message, but can't allocate the per-LSP context information it needs, must reject the request. It does this by sending a Notification message that includes the Status TLV with a Status Code of `Per-LSP context allocation failure' . That's a whole vibe check on memory, bestie 🧠
A downstream Diff-Serv LSR that recognizes the Diff-Serv TLV Type in a Label Request message and supports the requested PSC, but can't satisfy the label request for other reasons (for example, no label available), must send a Notification message following the existing LDP procedures [LDP] (for example, with a `No Label Resource' Status Code). This Notification message must include the requested Diff-Serv TLV. 🎀
6.5 Non-Handling of the Diff-Serv TLV 🙈
An LSR that doesn't recognize the Diff-Serv TLV Type, when it receives a Label Request message or a Label Mapping message containing the Diff-Serv TLV, must behave according to the procedures in [LDP] for an unknown TLV whose U Bit and F Bit are set to 0, i.e., it must ignore the message and return a Notification message with `Unknown TLV' Status. Ignored but still acknowledged, that's giving polite but unbothered 😌
6.6 Bandwidth Information 💜
Bandwidth information can also be signaled when an E-LSP or L-LSP is being set up, for example for Traffic Engineering purposes, using the Traffic Parameters TLV described in [MPLS CR LDP]. Main character energy for traffic planning 👑
7. MPLS Support of Diff-Serv over PPP, LAN, Non-LC-ATM and Non-LC-FR Interfaces 🌈
The general operations for MPLS support of Diff-Serv, including label forwarding and LSP setup, are covered in the earlier sections. This section describes the specific operations needed for MPLS support of Diff-Serv over PPP interfaces, LAN interfaces, ATM interfaces that aren't label controlled, and Frame Relay interfaces that aren't label controlled. ✨
On these interfaces, this specification allows any of the following LSP combinations per FEC:
- Zero or any number of E-LSP, and
- Zero or any number of L-LSPs.
A Diff-Serv capable LSR MUST support E-LSPs that use preconfigured `EXP<-->PHB mapping' over these interfaces. No excuses, this one is required 🫡
A Diff-Serv capable LSR MAY support E-LSPs that use signaled `EXP<-->PHB mapping' and L-LSPs over these interfaces. Optional but iconic if you do 🦋
8. MPLS Support of Diff-Serv over LC-ATM Interfaces 🍓
This section describes the specific operations needed for MPLS support of Diff-Serv over label switching controlled ATM (LC-ATM) interfaces. 🌸
This document allows any number of L-LSPs per FEC within an MPLS ATM Diff-Serv domain. E-LSPs are not supported over LC-ATM interfaces. Not on the guest list, sorry E-LSPs 🙅♀️
8.1 Use of ATM Traffic Classes and Traffic Management mechanisms 🧁
Using the "ATM service categories" specified by the ATM Forum, the "ATM Transfer Capabilities" specified by the ITU-T, or vendor-specific ATM traffic classes is outside the scope of this specification. The only requirement for a compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the ATM LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. That's the one non-negotiable, bestie 🔒
Since there is only one bit (CLP) for encoding the PHB drop precedence value over ATM links, only two different drop precedence levels are supported in ATM LSRs. Sections 4.2.2 and 4.4.2 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two ATM drop precedence levels. This mapping follows the requirements in [DIFF_AF] for the case when only two drop precedence levels are supported. Two levels only, it's giving minimalism 🤍
To avoid discarding parts of the packets, frame discard mechanisms, such as Early Packet Discard (EPD) (see [ATMF_TM]), SHOULD be enabled in the ATM-LSRs for all PHBs described in this document. Super recommended, not a hard rule, but you'd be lowkey wild not to 💅
8.2 LSR Implementation With LC-ATM Interfaces 🛠️
A Diff-Serv capable LSR MUST support L-LSPs over LC-ATM interfaces. This specification assumes that Edge-LSRs of the ATM-LSR domain use the "shim header" encapsulation method defined in [MPLS_ATM]. Operations without the "shim header" encapsulation are outside the scope of this specification. Shim header or bust, fr fr 🫶
9. MPLS Support of Diff-Serv over LC-FR Interfaces 🦋
This section describes the specific operations needed for MPLS support of Diff-Serv over label switching controlled Frame Relay (LC-FR) interfaces. ✨
This document allows any number of L-LSPs per FEC within an MPLS Frame Relay Diff-Serv domain. E-LSPs are not supported over LC-FR interfaces. Same energy as ATM, no E-LSPs here either 🙃
9.1 Use of Frame Relay Traffic parameters and Traffic Management mechanisms 📡
Using the Frame Relay traffic parameters specified by ITU-T and the Frame Relay Forum, or vendor-specific Frame Relay traffic management mechanisms, is outside the scope of this specification. The only requirement for a compliant implementation is that the forwarding behavior experienced by a Behavior Aggregate forwarded over an L-LSP by the Frame Relay LSR MUST be compliant with the corresponding Diff-Serv PHB specifications. Same non-negotiable rule, no skipping it 💖
Since there is only one bit (DE) for encoding the PHB drop precedence value over Frame Relay links, only two different drop precedence levels are supported in Frame Relay LSRs. Sections 4.2.3 and 4.4.3 define how the three drop precedence levels of the AFn Ordered Aggregates are mapped to these two Frame Relay drop precedence levels. This mapping follows the requirements in [DIFF_AF] for the case when only two drop precedence levels are supported. Two levels, again, we stan a consistent queue 👑
9.2 LSR Implementation With LC-FR Interfaces 🌷
A Diff-Serv capable LSR MUST support L-LSPs over LC-Frame Relay interfaces.
This specification assumes that Edge-LSRs of the FR-LSR domain use the "generic encapsulation" method recommended in [MPLS_FR]. Operations without the "generic encapsulation" are outside the scope of this specification. Generic encapsulation, you love to see it 🎀
10. IANA Considerations 🧾
This document defines a number of objects with implications for IANA. Paperwork moment, but make it cute 📋
This document defines, in section 5.2, a new RSVP object, the DIFFSERV object. This object required a number from the space defined in [RSVP] for those objects which, 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. Within that space, this object required a number from the "IETF Consensus" space. "65" has been allocated by IANA for the DIFFSERV object. 🔢
This document defines, in section 5.5, a new RSVP error code, "Diffserv Error". Error code "27" has been assigned by IANA to the "Diffserv Error". This document defines values 1 through 5 of the value field to be used within the ERROR_SPEC object for this error code. Future allocations of values in this space should be handled by IANA using the First Come First Served policy defined in [IANA]. Future-proof and organized, a 10/10 🌈
This document defines, in section 6.1, a new LDP TLV, the Diffserv TLV. The number for this TLV has been assigned by working group consensus according to the policies defined in [LDP]. ✨
This document defines, in section 6.2, five new LDP Status Code values for Diffserv-related error conditions. The values for the Status Code have been assigned by working group consensus according to the policies defined in [LDP]. Five new error codes, five new reasons to be dramatic about errors 😭
11. Security Considerations 🔐
This document does not introduce any new security issues beyond those inherent in Diff-Serv, MPLS and RSVP, and may use the same mechanisms proposed for those technologies. 💀 Okay, this is the part where we don't invent new drama. The security stuff comes from Diff-Serv, MPLS and RSVP themselves, so the same protections for those technologies are what you'd lean on 🛡️
12. Acknowledgments 🫶
This document has benefited from discussions with Eric Rosen, Angela Chiu and Carol Iturralde. It has also borrowed from the work done by D. Black regarding Diff-Serv and IP Tunnels interaction. Thank you to the whole squad 💖
APPENDIX A. Example Deployment Scenarios 🧚
This section does not provide additional specification and is only here to provide examples of how this flexible approach for Diff-Serv support over MPLS may be deployed. Pros and cons of various deployment options for particular environments are beyond the scope of this document. Examples only, bestie, you'll have to decide the rest yourself 🌸
A.1 Scenario 1: 8 (or fewer) BAs, no Traffic Engineering, no MPLS Protection
okay so picture a Service Provider running 8 (or fewer) BAs over MPLS 🎀. They're not doing Traffic engineering, they're not using MPLS protection, and they're using MPLS Shim Header encapsulation. Totally valid! They can run Diff-Serv over MPLS with a single E-LSP per FEC established via LDP, and they can also use the preconfigured `EXP<-->PHB mapping'. ✨
Here's how it goes:
- the Service Provider sets up, at every LSR, the bi-directional mapping between each PHB and a value of the EXP field (e.g.,
000<-->AF11,001<-->AF12,010<-->AF13) 💖 - the Service Provider sets up, at every LSR and on every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13) 🧚
- LSRs signal the establishment of a single E-LSP per FEC using LDP, following the specification above (so no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping) 🫶
A.2 Scenario 2: More than 8 BAs, no Traffic Engineering, no MPLS Protection
so this one is giving "more than 8 BAs" energy 👑. A Service Provider running more than 8 BAs over MPLS, not doing Traffic Engineering, not using MPLS protection, and using MPLS Shim encapsulation can run Diff-Serv over MPLS. For each FEC, they get:
- one E-LSP established via LDP that uses the preconfigured mapping to support a set of 8 (or less) BAs, AND
- one L-LSP per
<FEC,OA>established via LDP to support the other BAs. 🌸
Operations look like this:
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs transported over the E-LSP
- the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB
- the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal the establishment of a single E-LSP per FEC for the set of E-LSP transported BAs using LDP, as specified above (so no Diff-Serv TLV in LDP Label Request/Label Mapping messages to implicitly indicate that the LSP is an E-LSP and that it uses the preconfigured mapping) 🍓
- LSRs signal the establishment of one L-LSP per
<FEC,OA>for the other BAs using LDP, as specified above (so a Diff-Serv TLV in LDP Label Request/Label Mapping messages indicates the L-LSP's PSC) 💅
A.3 Scenario 3: 8 (or fewer) BAs, Aggregate Traffic Engineering, Aggregate MPLS Protection
okay this one has main character energy 🦋. A Service Provider running 8 (or fewer) BAs over MPLS, doing aggregate Traffic Engineering (so one common path selection for all BAs), using aggregate MPLS protection (restoring service to all PSCs jointly), and using MPLS Shim Header encapsulation, can run Diff-Serv over MPLS with a single E-LSP per FEC. That E-LSP is established via RSVP [RSVP_MPLS_TE] or CR-LDP [CR-LDP_MPLS_TE], and it uses the preconfigured mapping. ✨
Operations, in brief:
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g.,
000<-->AF11,001<-->AF12,010<-->AF13) 🎀 - the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) 🧚
- LSRs signal the establishment of a single E-LSP per FEC, which will use the preconfigured mapping:
- using the RSVP protocol as specified above (so no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
- using the CR-LDP protocol as specified above (so no Diff-Serv TLV in LDP Label Request/Label Mapping messages). 💖
- protection is activated on all the E-LSPs to achieve MPLS protection via mechanisms outside the scope of this document 🛡️
A.4 Scenario 4: per-OA Traffic Engineering/MPLS Protection
this is the per-OA glow-up 🌈. A Service Provider running any number of BAs over MPLS, doing per-OA Traffic Engineering (so a separate path selection for each OA) and per-OA MPLS protection (protection with potentially different levels for the different OAs), can run Diff-Serv over MPLS using one L-LSP per <FEC,OA> pair established via RSVP or CR-LDP. 🫶
Operations, summed up:
- the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13)
- LSRs signal the establishment of one L-LSP per
<FEC,OA>:- using RSVP as specified above to signal the L-LSP's PSC (so a DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR
- using the CR-LDP protocol as specified above to signal the L-LSP PSC (so a Diff-Serv TLV in LDP Label Request/Label Mapping messages). 🍓
- the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection for each PSC) via mechanisms outside the scope of this document 👑
A.5 Scenario 5: 8 (or fewer) BAs, per-OA Traffic Engineering/MPLS Protection
ngl this one is a bit of a combo 🥹. A Service Provider running 8 (or fewer) BAs over MPLS, doing per-OA Traffic Engineering (a separate path selection for each OA) and per-OA MPLS protection (potentially different protection levels for the different OAs), can run Diff-Serv over MPLS using one E-LSP per <FEC,OA> pair established via RSVP or CR-LDP. The Service Provider may also use the preconfigured mapping on all the E-LSPs. 🌷
Operations look like this:
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field (e.g.,
000<-->AF11,001<-->AF12,010<-->AF13) 💜 - the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (eg drop profile for AF11, AF12, AF13) 🧚
- LSRs signal the establishment of one E-LSP per
<FEC,OA>:- using the RSVP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (so no DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST), OR
- using the CR-LDP protocol as specified above to signal that the LSP is an E-LSP which uses the preconfigured mapping (so no Diff-Serv TLV in LDP Label Request/Label Mapping messages) 🎀
- the Service Provider configures, for each E-LSP, at the head-end of that E-LSP, a filtering/forwarding criteria so that only the packets belonging to a given OA are forwarded on the E-LSP established for the corresponding FEC and corresponding OA 🔥
- the appropriate level of protection is activated on the different E-LSPs (potentially with a different level of protection depending on the PSC actually transported over each E-LSP) via mechanisms outside the scope of this document 🫶
A.6 Scenario 6: no Traffic Engineering/MPLS Protection on 8 BAs, per-OA Traffic Engineering/MPLS Protection on other BAs.
this is a mixed-bag situation and honestly it's iconic 🍒. A Service Provider that is not doing Traffic Engineering or MPLS protection on 8 (or fewer) BAs, but is doing per-OA Traffic Engineering and MPLS protection on the other BAs, can do the following. Each separate path selection is made for each OA covering the other BAs, and MPLS protection can use a potentially different policy for each of those OAs. The network uses MPLS Shim encapsulation, and it can run Diff-Serv over MPLS with, for each FEC:
- one E-LSP using the preconfigured mapping, established via LDP, to support the set of 8 (or fewer) non-traffic-engineered/non-protected BAs, AND
- one L-LSP per
<FEC,OA>pair established via RSVP or CR-LDP for support of the other BAs. 💖
Operations look like this:
- the Service Provider configures at every LSR the bi-directional mapping between each PHB and a value of the EXP field for the BAs supported over the E-LSP
- the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC supported over the E-LSP and the dropping behavior for each corresponding PHB
- the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC supported over the L-LSPs and the dropping behavior for each corresponding PHB
- LSRs signal the establishment of a single E-LSP per FEC for the non-traffic engineered BAs using LDP, as specified above (so no Diff-Serv TLV in LDP Label Request/Label Mapping messages) 🧚
- LSRs signal the establishment of one L-LSP per
<FEC,OA>for the other BAs:- using the RSVP protocol as specified above to signal the L-LSP PSC (so a DIFFSERV RSVP Object in the PATH message containing the LABEL_REQUEST Object), OR
- using the CR-LDP protocol as specified above to signal the L-LSP PSC (so a Diff-Serv TLV in LDP Label Request/Label Mapping messages). 🌸
- protection is not activated on the E-LSPs. 🙈
- the appropriate level of protection is activated on the different L-LSPs (potentially with a different level of protection depending on the L-LSP's PSC) via mechanisms outside the scope of this document 👑
A.7 Scenario 7: More than 8 BAs, no Traffic Engineering, no MPLS Protection
last but not least, the "more than 8 BAs" squad is back 🦋. A Service Provider running more than 8 BAs over MPLS, not doing Traffic engineering, not doing MPLS protection, and using MPLS Shim Header encapsulation, can run Diff-Serv over MPLS using two E-LSPs per FEC. Those E-LSPs are established via LDP and use signaled `EXP<-->PHB mapping'. ✨
Operations, quick and iconic:
- the Service Provider configures at every LSR, and on every interface, the scheduling behavior for each PSC (e.g., bandwidth allocated to AF1) and the dropping behavior for each PHB (e.g., drop profile for AF11, AF12, AF13) 🎀
- LSRs signal the establishment of two E-LSPs per FEC using LDP, following the specification above (so a Diff-Serv TLV in LDP Label Request/Label Mapping messages explicitly indicates that the LSP is an E-LSP and its `EXP<-->PHB mapping'). The signaled mapping indicates the subset of 8 (or less) BAs to be transported on each E-LSP, and which EXP values are mapped to each BA on each E-LSP. 🫶
APPENDIX B. Example Bandwidth Reservation Scenarios ✨
B.1 Scenario 1: No Bandwidth Reservation
okay so picture this: a network admin decides to 💅
- have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...)
- have Shortest Path Routing used for all the Diff-Serv traffic.
this is the closest thing to provisioned Diff-Serv over non-MPLS IP, bestie 🫶 and in that case, E-LSPs and/or L-LSPs get set up without any signaled bandwidth. no cap, it's giving simple ✨
B.2 Scenario 2: Bandwidth Reservation for per-PSC Admission Control
now let's level up 🔥 same admin, but this time:
- have Diff-Serv resources entirely provisioned off-line (e.g., via Command Line Interface, via SNMP, via COPS,...)
- use L-LSPs
- have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC.
in this one, L-LSPs get established with signaled bandwidth 🦋 and the LSRs use that signaled bandwidth to do admission control at every hop. the goal is making sure the bandwidth-availability constraint for the relevant PSC is actually met, so every hop is checking its work. iconic behavior, honestly 👑
B.3 Scenario 3: Bandwidth Reservation for per-PSC Admission Control and per-PSC Resource Adjustment
the final boss 😭🌈 here the admin elects to:
- use L-LSPs
- have Constraint Based Routing performed separately for each PSC, where one of the constraints is availability of bandwidth from the bandwidth allocated to the relevant PSC.
- have Diff-Serv resources dynamically adjusted
so the L-LSPs are established with signaled bandwidth again, and the LSRs use that bandwidth to try adjusting the resources allocated to the relevant PSC (for example, the scheduling weight). after that, they run admission control so the bandwidth-availability constraint for the relevant PSC still holds after the adjustment. main character energy, fr fr 🎀
References
- [ANSI/IEEE] ANSI/IEEE Std 802.1D, 1993 Edition, incorporating IEEE supplements P802.1p, 802.1j-1996, 802.6k-1992, 802.11c-1998, and P802.12e).
- [ATMF_TM] ATM Forum, "Traffic Management Specification Version 4.1", March 1999.
- [CR-LDP_MPLS_TE] Jamoussi, B., Editor, Andersson, L., Callon, R. and R. Dantu, "Constraint-Based LSP Setup using LDP", RFC 3212, January 2002.
- [DCLASS] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.
- [DIFF_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_EF] Davie, B., Charny, A., Baker, F., Bennet, J., Benson, K., Boudec, J., Chiu, A., Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.
- [DIFF_HEADER] 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.
- [DIFF_NEW] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002.
- [DIFF_TUNNEL] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
- [ECN] Ramakrishnan, K., Floyd, S. and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
- [IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
- [IEEE_802.1] ISO/IEC 15802-3: 1998 ANSI/IEEE Std 802.1D, 1998 Edition (Revision and redesignation of ISO/IEC 10038:98.
- [LDP] Andersson, L., Doolan, D., Feldman, N., Fredette, A. and B. Thomas, "LDP Specification", RFC 3036, January 2001.
- [MPLS_ARCH] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
- [MPLS_ATM] Davie, B., Lawrence, J., McCloghrie, K., Rosen, E., Swallow, G., Rekhter, Y. and P. Doolan, "MPLS using LDP and ATM VC Switching", RFC 3035, January 2001.
- [MPLS_ENCAPS] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
- [MPLS_FR] Conta, A., Doolan, P. and A. Malis, "Use of Label Switching on Frame Relay Networks Specification", RFC 3034, January 2001.
- [MPLS_VPN] Rosen, E., "BGP/MPLS VPNs", Work in Progress.
- [NULL] Bernet, Y., Smith, A. and B. Davie, "Specification of the Null Service Type", RFC 2997, November 2000.
- [PHBID] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes" RFC 3140, June 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.
- [RSVP_MPLS_TE] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. and G. Swallow, "Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
Authors' Addresses
Francois Le Faucheur Cisco Systems 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
Liwen Wu Cisco Systems 3550 Cisco Way San Jose, CA 95134 USA
Phone: +1 (408) 853-4065 EMail: liwwu@cisco.com
Bruce Davie Cisco Systems 250 Apollo Drive, Chelmsford, MA 01824 USA
Phone: +1 (978) 244-8000 EMail: bsd@cisco.com
Shahram Davari PMC-Sierra Inc. 411 Legget Drive Kanata, Ontario K2K 3C9 Canada
Phone: +1 (613) 271-4018 EMail: davari@ieee.org
Pasi Vaananen Nokia 3 Burlington Woods Drive, Suit 250 Burlington, MA 01803 USA
Phone +1 (781) 993-4900 EMail: pasi.vaananen@nokia.com
Ram Krishnan Axiowave Networks 200 Nickerson Road Marlboro, MA 01752
EMail: ram@axiowave.com
Pierrick Cheval Alcatel 5 rue Noel-Pons 92737 Nanterre Cedex France EMail: pierrick.cheval@space.alcatel.ft
Juha Heinanen Song Networks, Inc. Hallituskatu 16 33200 Tampere, Finland
EMail: jh@song.fi
Full Copyright Statement
Legal bits, but we keep every word 🫶
Copyright (C) The Internet Society (2002). 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society. ✨
📦 where this page comes from
- ietf: rfc3270 2002-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms