RFC 8100
Diffserv-Interconnection Classes and Practice
RFC 8100: Diffserv-Interconnection Classes and Practice 🎀
Okay bestie, this one is from March 2017 and it's an Informational RFC, so it's published for information and isn't an Internet Standards Track spec 📚. R. Geib (Ed.) from Deutsche Telekom edited it, and D. Black from Dell EMC co-wrote it 🌸. It doesn't obsolete or update anything, since the header has no Obsoletes or Updates line. It's also ISSN 2070-1721 if you want to look it up 💜.
Abstract 💖
So this doc defines a small, shared set of Diffserv Per-Hop Behaviors (PHBs) and Diffserv Codepoints (DSCPs) that get applied where two networks that are run separately meet and connect 🔗. It also explains how doing it this way can make network configuration and operation way simpler ✨. A lot of network providers run Multiprotocol Label Switching (MPLS) and use Treatment Aggregates for traffic marked with different Diffserv PHBs, and they use MPLS to connect with other networks too 🦋. This document gives a simple interconnection approach that can make Diffserv easier to run between providers who use MPLS and the Short Pipe Model 💅. It was motivated by what MPLS operators using Short Pipe Model tunnels need, but it works for other networks too, MPLS or not 🫶.
Status of This Memo 📜
Not gonna lie, the status part is a little formal, but here's the tea: this document is not an Internet Standards Track specification, it's just published for information purposes 💀.
It's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agreed on 🌈. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. Not every IESG-approved doc is eligible for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🙈.
For the current status, any errata, and how to send feedback, look at http://www.rfc-editor.org/info/rfc8100 🔥.
Copyright Notice 💜
The copyright is Copyright (c) 2017 IETF Trust and the persons identified as the document authors, all rights reserved 🌸. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they were on the publication date, so please read those carefully because they explain your rights and restrictions for this doc 🧚. Any Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in that license 💅.
Table of Contents 🍓
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Related Work . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Applicability Statement . . . . . . . . . . . . . . . . . 5
1.3. Document Organization . . . . . . . . . . . . . . . . . . 5
2. MPLS and Short Pipe Model Tunnels . . . . . . . . . . . . . . 6
3. Relationship to RFC 5127 . . . . . . . . . . . . . . . . . . 7
3.1. Background of RFC 5127 . . . . . . . . . . . . . . . . . 7
3.2. Differences from RFC 5127 . . . . . . . . . . . . . . . . 7
4. The Diffserv-Intercon Interconnection Classes . . . . . . . . 8
4.1. Diffserv-Intercon Example . . . . . . . . . . . . . . . . 11
4.2. End-to-End PHB and DSCP Transparency . . . . . . . . . . 13
4.3. Treatment of Network Control Traffic at Carrier
Interconnection Interfaces . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Normative References . . . . . . . . . . . . . . . . . . 16
7.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. The MPLS Short Pipe Model and IP Traffic . . . . . . 18
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 211. Introduction ✨
Diffserv is already deployed in tons of networks 🌍. It gives you differentiated forwarding based on the Diffserv Codepoint (DSCP) field, which lives in the IP header [RFC2474] 💖. This document defines a set of common Diffserv classes (Per-Hop Behaviors (PHBs)) and codepoints for interconnection points, where locally used classes and codepoints should get mapped to and from 🦋.
Section 2.3.4.2 of [RFC2475] says re-marking packets at domain boundaries is a Diffserv feature 💅. Now, if you get traffic marked with an unknown or unexpected DSCP, [RFC2474] recommends forwarding it with default (best-effort) treatment and leaving the DSCP markings alone 🫶. That helps incremental Diffserv deployment in existing networks, and also covers routers that don't support Diffserv or aren't configured for it 🌸. But lots of networks don't follow that advice. They re-mark unknown or unexpected DSCPs to zero when they receive them, for default (best-effort) forwarding, following the guidance in [RFC2475], so the DSCPs used inside a Diffserv domain stay appropriate 🔥. This document goes with the second approach 💜. It defines extra DSCPs that are known and expected at network interconnection interfaces, so there's less traffic getting re-marked to zero 👑.
This document came from needs for IP network interconnection with Diffserv support between providers who run Multiprotocol Label Switching (MPLS) in their backbones 🌈. It also works for other technologies ✨. The simplifications and methods here help line up IP Diffserv with MPLS limits that come from the widely deployed Short Pipe Model for MPLS tunnel operation [RFC3270] 🙈. And here's the cute part: by limiting Diffserv to a small number of Treatment Aggregates, traffic can leave a network with the same DSCP value it came in with, even if a different DSCP is used inside the network 🦋. That's a chance to keep Diffserv treatment consistent across network boundaries 💖.
Okay so, using a defined set of interconnection PHBs and DSCPs might look like extra work for a network operator in isolation 😭. The big payoff is that the mapping to and from the interconnection PHBs and DSCPs gets specified once, for all the interconnections to other networks that can use this approach 💅. Without it, the PHBs and DSCPs would have to be negotiated and configured separately for every network interconnection, and that has poor administrative and operational scaling 💀. Plus, consistent end-to-end Diffserv treatment is more likely when you use an interconnection codepoint scheme, because traffic gets re-marked to the same DSCPs at all network interconnections 🧚.
The interconnection approach in this document (called "Diffserv-Intercon") uses a set of PHBs, mapped to four corresponding MPLS Treatment Aggregates 🎀. It also uses a set of interconnection DSCPs that allow straightforward rewriting to domain-internal DSCPs, plus defined DSCP markings for traffic forwarded to interconnected domains 🫶. The solution can be used in other contexts that benefit from a defined Diffserv interconnection interface ✨.
The basic idea is that traffic sent with a Diffserv-Intercon PHB and DSCP gets restored to that same PHB and DSCP at each network interconnection, even though a different PHB and DSCP might be used inside each network involved 🔁. The key requirement is that the DSCP of the network ingress interconnect gets restored at the network egress 🔑. The key observation is that this only works in general for a small number of DSCPs 👑. Traffic sent with other DSCPs can be re-marked to an interconnect DSCP, or handled through additional agreement(s) among the operators of the interconnected networks 💜. The MPLS Short Pipe Model favors re-marking unexpected DSCPs to zero when there's no additional agreement, as explained further in this document 🌸.
Beyond the shared interconnecting PHBs and DSCPs, interconnecting operators also need to agree on the tunneling technology used for interconnection (for example MPLS, if it's used) and control or mitigate how tunneling affects reliability and MTU 🦋.
1.1. Related Work 🦋
Besides the activities that kicked this off, there are other RFCs and Internet-Drafts that could benefit from an interconnection PHB and DSCP scheme 🌈. [RFC5160] suggests Meta-QoS-Classes to help enable deployment of standardized end-to-end QoS classes 💖. The Diffserv-Intercon class and codepoint scheme is meant to complement that work, for example by enabling a defined set of interconnection DSCPs and PHBs ✨.
Border Gateway Protocol (BGP) support for signaling Class of Service at interconnection interfaces [BGP-INTERCONNECTION] [SLA-EXCHANGE] is complementary to Diffserv-Intercon 🫶. Those two BGP docs focus on exchanging Service Level Agreement (SLA) and traffic conditioning parameters 💅. They assume that common PHBs, identified by the signaled DSCPs, are already set up (for example through the Diffserv-Intercon DSCPs) before BGP signals the PHB id codes 🧚.
1.2. Applicability Statement 💅
This document applies to Differentiated Services used for interconnection traffic between networks, and it's especially good for connecting MPLS-based networks that use MPLS Short Pipe Model tunnels 🎀. It also applies to other network technologies, but it isn't meant for use inside an individual network, where the approach in [RFC5127] is one of the possible alternatives. See Section 3 for more on that 🙈.
The Diffserv-Intercon approach in this document simplifies IP-based interconnection to domains running the MPLS Short Pipe Model for IP traffic 🔥. That covers traffic that terminates inside the domain and traffic that transits on to another domain 🌸. Transiting traffic is received and sent with the same PHB and DSCP 💜. Terminating traffic keeps the PHB it was received with, but the DSCP can change 👑.
Diffserv-Intercon also applies to Pipe Model tunneling [RFC2983] [RFC3270], but it doesn't apply to Uniform Model tunneling [RFC2983] [RFC3270] 🧚.
The Diffserv-Intercon approach defines a set of four PHBs for use at interconnections (or network boundaries in general) 🌈. The corresponding DSCPs for use at an interconnection interface are defined too ✨. Diffserv-Intercon allows a simple mapping of PHBs and DSCPs to MPLS Treatment Aggregates 🦋. It can be extended through IETF standardization, which means additional PHBs and DSCPs can be specified for the Diffserv-Intercon scheme 💖. There's coding space left for private interconnection agreements or provider internal services, because only a single digit number of standard DSCPs are applied by the Diffserv-Intercon approach 🫶.
1.3. Document Organization 🗺️✨
okay so here's the map of this doc, bestie 💅 Section 2 reviews the MPLS Short Pipe Model for Diffserv Tunnels [RFC3270], because effective support for that model is a crucial goal of Diffserv-Intercon. Section 3 gives background on the approach in RFC 5127 to Traffic Class (TC) aggregation within a Diffserv network domain and contrasts it with the Diffserv-Intercon approach. Section 4 introduces Diffserv-Intercon Treatment Aggregates, along with the PHBs and DSCPs they use, and explains how other PHBs (and associated DSCPs) may be mapped to these Treatment Aggregates. Section 4 also talks about treatment of IP traffic, MPLS VPN Diffserv considerations, and handling of high-priority network management traffic. Appendix A describes how the MPLS Short Pipe Model (Penultimate Hop Popping (PHP)) impacts DSCP marking for IP interconnections. 🧚
2. MPLS and Short Pipe Model Tunnels 🎀
This section gives a summary of what MPLS Short Pipe Model tunnels mean, and in particular how their use of PHP (see RFC 3270) changes the Diffserv tunnel framework described in RFC 2983. 🌸 The Pipe and Uniform Models for Differentiated Services and Tunnels are defined in [RFC2983]. RFC 3270 adds the Short Pipe Model to reflect the impact of MPLS PHP, mainly for MPLS-based IP tunnels and VPNs. The Short Pipe Model and PHP have since become super popular with network providers that run MPLS networks, and they're now widely used to transport unencapsulated IP traffic. That has big implications for Diffserv functionality in MPLS networks, so pay attention 👀
Per RFC 2474, the recommendation to forward traffic with unrecognized DSCPs using default (best-effort) service, without rewriting the DSCP, has not been widely deployed in practice. 💀 Network operation and management get simpler when there's a 1-1 match between the DSCP marked on the packet and the forwarding treatment (PHB) applied by network nodes. When that's done, CS0 (the all-zero DSCP) is the only DSCP used for default forwarding of best-effort traffic, and a common practice is to re-mark to CS0 any traffic received with unrecognized or unsupported DSCPs at network edges. Clean and simple, periodt ✨
MPLS networks are a little more subtle about this, because it's possible to encode the provider's DSCP in the MPLS TC field and let that differ from the PHB indicated by the DSCP in the MPLS-encapsulated IP packet. If the MPLS label with the provider's TC field is present at all hops within the provider network, this approach would let an unrecognized DSCP be carried edge-to-edge over an MPLS network, because the effective DSCP used by the provider's MPLS network would be encoded in the MPLS label TC field (and also carried edge-to-edge). Unfortunately, this is only true for Pipe Model tunnels. 😭
Short Pipe Model tunnels and PHP behave differently, because PHP removes and discards the MPLS provider label carrying the provider's TC field before the traffic exits the provider's network. That discard happens one hop upstream of the MPLS tunnel endpoint (which is usually at the network edge), so there's no provider TC information available at the tunnel egress. 🫠 To make sure traffic is handled consistently at the tunnel egress, the DSCP field in the MPLS-encapsulated IP header has to contain a DSCP that is valid for the provider's network, so the IP header can't be used to carry a different DSCP edge-to-edge. See Appendix A for a more detailed discussion. 📖
3. Relationship to RFC 5127 🦋
This document draws heavily on the approach to aggregating Diffserv TCs for use within a network that's described in RFC 5127 🙌 but there are important differences, because the characteristics of network interconnects are different from links inside a network.
3.1. Background of RFC 5127 🌈
Many providers run MPLS-based backbones that use backbone traffic engineering, so that if a major link, switch, or router fails, the result is a routed network that keeps on functioning. Building on that foundation, [RFC5127] introduced the concept of Diffserv Treatment Aggregates, which let traffic marked with multiple DSCPs be forwarded in a single MPLS TC, thanks to robust provider backbone traffic engineering. This allows differentiated forwarding behaviors within a domain without eating up a huge number of MPLS TCs. Smart, right? 🧠💜
RFC 5127 gives an example that aggregates Diffserv service classes into four Treatment Aggregates. A small number of aggregates is used because:
- The available coding space for carrying TC information (e.g., Diffserv PHB) in MPLS (and Ethernet) is only 3 bits in size, and it's meant for more than just Diffserv purposes (see, e.g., [RFC5129]).
- The common interconnection DSCPs ought not to use all 8 possible values. This leaves space for future standards, private bilateral agreements, and local use PHBs and DSCPs.
- Migrations from one DSCP scheme to a different one are another possible application of otherwise unused DSCPs.
3.2. Differences from RFC 5127 💅
Like RFC 5127, this document also uses four Treatment Aggregates, but it differs from RFC 5127 in some important ways:
- It follows RFC 2475 in allowing the DSCPs used within a network to differ from those used to exchange traffic with other networks (at network edges). It also gives support for restoring ingress DSCP values if one of the recommended interconnect DSCPs in this document is used. This results in DSCP re-marking at both network ingress and network egress, and this document assumes that such re-marking at network edges is possible for all interface types. 🔁
- Diffserv-Intercon suggests limiting the number of interconnection PHBs per Treatment Aggregate to the minimum required. As further discussed below, the number of PHBs per Treatment Aggregate is no more than two. When two PHBs are specified for a Diffserv-Intercon Treatment Aggregate, the expectation is that the provider network supports DSCPs for both PHBs but uses a single MPLS TC for the Treatment Aggregate that contains the two PHBs. 🎯
- Diffserv-Intercon suggests mapping other PHBs and DSCPs into the interconnection Treatment Aggregates, as further discussed below. 🧩
- Diffserv-Intercon treats network control (NC) traffic as a special case. Inside a provider's network, the CS6 DSCP is used for local network control traffic (routing protocols and Operations, Administration, and Maintenance (OAM) traffic that is essential to network operation, administration, control, and management) that may be destined for any node within the network. In contrast, network control traffic exchanged between networks (e.g., BGP) usually terminates at or close to a network edge and isn't forwarded through the network, because it isn't part of internal routing or OAM for the receiving network. Also, such traffic is unlikely to be covered by standard interconnection agreements. It's more likely to be specifically configured (e.g., most networks impose restrictions on use of BGP with other networks, for obvious reasons). See Section 4.2 for further discussion. 🚧
- Because RFC 5127 used a Treatment Aggregate for network control traffic, Diffserv-Intercon can instead define a fourth Treatment Aggregate for use at network interconnections, in place of the Network Control Treatment Aggregate in RFC 5127. Network control traffic may still be exchanged across network interconnections, as further discussed in Section 4.2. Diffserv-Intercon uses this fourth Treatment Aggregate for Voice over IP (VoIP) traffic, where network-provided service differentiation is crucial, because even minor glitches are immediately obvious to the humans in the conversation. 📞🫶
4. The Diffserv-Intercon Interconnection Classes ✨
Okay bestie, when two networks meet at an interconnection, they have to agree on which PHBs they'll use for the handoff and the exact DSCP for each one 💅. This doc defines four interconnection Treatment Aggregates with set DSCPs that get bundled together under them 🦋. The sending party re-marks its internal DSCPs into these interconnection codepoints, and the receiving party re-marks them into its own internal usage 🔁. The interconnect SLA is where the two domains write down the DSCPs and PHBs they both support, plus what happens to any PHB or DSCP the receiving domain doesn't recognise 📝.
Similar approaches that use a small number of Treatment Aggregates (including recognition of how important VoIP traffic is) have shown up in related standards and recommendations from outside the IETF too 🌸. Think Y.1566 [Y.1566], the Global System for Mobile Communications Association (GSMA) IR.34 [IR.34], and MEF23.1 [MEF23.1]. Same energy, different group chat 💜.
Here's the list of the four Diffserv-Intercon Treatment Aggregates 👑. It calls out where things differ from RFC 5127 and suggests how all the RFC 4594 TCs map onto them 🧚.
Telephony Service Treatment Aggregate: This one is PHB Expedited Forwarding (EF), DSCP 101 110, and PHB VOICE-ADMIT, DSCP 101 100 (see [RFC3246], [RFC4594], and [RFC5865]). It matches the Real-Time Treatment Aggregate definition from RFC 5127 when it comes to queuing, where both delay and jitter should be minimised 🎀. The difference is that this aggregate is restricted to carrying Telephony service class traffic in the sense of [RFC4594] 📞.
Bulk Real-Time Treatment Aggregate: This one is designed to carry PHB AF41, DSCP 100 010 (the other AF4 PHB group PHBs and DSCPs may be used for future extension of the set of DSCPs carried by this Treatment Aggregate) 🎥. It's meant to provide Diffserv-Intercon network interconnection for a subset of the Real-Time Treatment Aggregate defined in RFC 5127, specifically the parts that eat up lots of bandwidth 🍓. The traffic is expected to be made up of these RFC 4594 classes: Broadcast Video, Real-Time Interactive, and Multimedia Conferencing 📺. This Treatment Aggregate should be configured with a rate-based queue, which lines up with the recommendation for the transported TCs in RFC 4594 ⭐. Compared to RFC 5127, the number of DSCPs has been cut down to one (initially) ✂️. The AF42 and AF43 PHBs could be added if there's a need for three-color marked Multimedia Conferencing traffic 🌈.
Assured Elastic Treatment Aggregate: This one is made up of PHBs AF31 and AF32 (i.e., DSCPs 011 010 and 011 100) 💖. Compared to RFC 5127, the number of DSCPs has been reduced to two 🦋. This document suggests transporting signaling marked by AF31 (e.g., as recommended by GSMA IR.34 [IR.34]) 📡. AF33 is reserved for extending the PHBs that get aggregated here 🔮. For Diffserv-Intercon network interconnection, the following service classes (per RFC 4594) should be mapped to the Assured Elastic Treatment Aggregate: the Signaling service class (being marked for lowest loss probability), the Multimedia Streaming service class, the Low-Latency Data service class, and the High-Throughput Data service class 🫶.
Default / Elastic Treatment Aggregate: This one carries the Default PHB, CS0 with DSCP 000 000 🩶. An example in RFC 5127 calls this Treatment Aggregate the "Elastic Treatment Aggregate" 🙈. The big difference from RFC 5127 is that any traffic with unrecognised or unsupported DSCPs may be re-marked to this DSCP 🧹. For Diffserv-Intercon network interconnection, the Standard service class and the Low-Priority Data service class defined in RFC 4594 should be mapped to this Treatment Aggregate 🍼. This document doesn't specify an interconnection class for Low-Priority Data (also defined in RFC 4594) 🤷♀️. That traffic may be forwarded with a Lower Effort PHB in one domain (e.g., the PHB proposed by Informational [RFC3662]), but the methods in this document re-mark it with DSCP CS0 at a Diffserv-Intercon network interconnection 🐢. The result is that Low-Priority Data gets treated the same as data sent using the Standard service class 🤝. (Note: In a network that implements RFC 2474, Low-Priority traffic marked as CS1 would otherwise get better treatment than Standard traffic using the default PHB 👀.)
RFC 2475 says that ingress nodes must condition all inbound traffic to make sure the DS codepoints are acceptable 🚪. Packets with unacceptable codepoints must either be discarded or have their DS codepoints changed to acceptable values before they're forwarded 🗑️. For example, an ingress node receiving traffic from a domain with no enhanced service agreement in place may reset the DS codepoint to CS0 🔄. So an interconnect SLA needs to spell out not just how traffic arriving with a supported interconnect DSCP is treated, but also how traffic arriving with unsupported or unexpected DSCPs is treated 🧐. Re-marking to CS0 is a widely deployed behavior, so it's definitely part of the convo 💅.
When a Diffserv interconnection is being set up, both networks should define the set of acceptable and unacceptable DSCPs and specify how traffic marked with each DSCP gets treated 📋.
Diffserv-Intercon lets you modify unacceptable DSCPs, but there's a catch 🚨. If traffic using one or more PHBs in a PHB group (e.g., AF3x, which consists of AF31, AF32, and AF33) is accepted as part of a supported Diffserv-Intercon Treatment Aggregate, then traffic using other PHBs from that same PHB group should not be modified to use PHBs outside that group 🙅♀️. Especially, it should not be re-marked to CS0 unless the entire PHB group is re-marked to CS0 🛑. This avoids unexpected forwarding behavior (and potential reordering; see also [RFC7657]) when using Assured Forwarding (AF) PHBs [RFC2597] 🌀. Keep the group together, babe 🫶.
4.1. Diffserv-Intercon Example
The overall approach to DSCP marking at network interconnections is shown in this example 🎬. Provider O, provider W, and provider F are all peered with provider T 🧑🤝🧑. They've agreed on a Diffserv interconnection SLA 📜.
Traffic from provider O terminates inside provider T's network, while provider W's traffic transits through provider T's network on its way to provider F 🛣️. This example assumes that every provider uses its own internal PHB and codepoint (DSCP) that corresponds to the AF31 PHB in the Diffserv-Intercon Assured Elastic Treatment Aggregate (AF21, CS2, and AF11 are used in the example) 🎀.
Provider O Provider W
| |
+----------+ +----------+
| AF21 | | CS2 |
+----------+ +----------+
V V
+~~~~~~~+ +~~~~~~~+
|Rtr PrO| |Rtr PrW| Rtr: Router
+~~~~~~~+ +~~~~~~~+ Pr[L]: Provider[L]
| Diffserv |
+----------+ +----------+
| AF31 | | AF31 |
+----------+ +----------+
V Intercon V
+~~~~~~~+ |
|RtrPrTI|------------------+ Router Provider T Ingress
+~~~~~~~+
| Provider T Domain
+------------------+
| MPLS TC 2, AF21 |
+------------------+
| | +----------+ +~~~~~~~+
V `--->| AF21 |->-|RtrDstH| Router Destination Host
+----------+ +----------+ +~~~~~~~+
| AF21 | Local DSCPs Provider T
+----------+
|
+~~~~~~~+
|RtrPrTE| Router Provider T Egress
+~~~~~~~+
| Diffserv
+----------+
| AF31 |
+----------+
| Intercon
+~~~~~~~+
|RtrPrF | Router Provider F
+~~~~~~~+
|
+----------+
| AF11 | Provider F
+----------+
Figure 1: Diffserv-Intercon ExampleProviders only need to deploy mappings from internal DSCPs to Diffserv-Intercon DSCPs (and back), so they can swap traffic using the PHBs they want 🔁. In the example, provider O has decided that the properties of its internal class AF21 are best met by the Diffserv-Intercon Assured Elastic Treatment Aggregate, PHB AF31 🎯. On the outgoing peering interface connecting provider O with provider T, the peering router of provider O re-marks AF21 traffic to AF31 ✈️. The domain-internal PHB of provider T that meets the requirements of the Diffserv-Intercon Assured Elastic Treatment Aggregate comes from the AF2x PHB group 💜. So AF31 traffic received at the interconnection with provider T gets re-marked to AF21 by the peering router of domain T, and domain T has chosen to use MPLS TC value 2 for this aggregate 🌟. At the penultimate MPLS node, the top MPLS label is removed, which exposes the IP header marked with the DSCP that was set at the network ingress 🏷️. The peering router connecting domain T with domain F classifies the packet by its domain-T-internal DSCP AF21 🔍. As the packet leaves domain T on the interface to domain F, its DSCP gets re-marked to AF31 💫. The peering router of domain F classifies the packet for domain-F-internal PHB AF11, since that's the PHB whose properties match the Diffserv-Intercon Assured Elastic Treatment Aggregate 🥰.
This example can be extended 🌷. The figure shows provider W using CS2 for traffic that corresponds to the Diffserv-Intercon Assured Elastic Treatment Aggregate PHB AF31, and that traffic gets mapped to AF31 at the Diffserv-Intercon interconnection to provider T 🧁. Also, say provider O supports a PHB marked by AF22, and this PHB is supposed to get Diffserv transport within provider T's domain 🚀. Then provider O will re-mark it with DSCP AF32 for interconnection to provider T 💅.
Finally, say provider W supports CS3 for internal use only 🏠. Then no Diffserv-Intercon DSCP mapping needs to be configured at the peering router 🙌. If provider W sends traffic to provider T marked by CS3 due to a misconfiguration, provider T may re-mark it to CS0 😭.
4.2. End-to-End PHB and DSCP Transparency ✨
Okay so this bit is all about end-to-end Diffserv approaches for the Uniform, Pipe, and Short Pipe Model tunnels [RFC2983] [RFC3270] when they're used edge-to-edge in a network. It's giving tunnel drama 🎀
- Uniform Model 🌸: neither the DSCP nor the PHB changes at all. So a network management packet that shows up with a
CS6DSCP gets forwarded with an MPLS TC matchingCS6. Uniform is outside the scope of this doc, so we're not going deeper here, bestie. - Pipe Model 🦋: the inner tunnel DSCP stays exactly the same, but an outer tunnel DSCP and the PHB could change. Example: a packet arriving with a (network-specific)
CS1DSCP gets transported by a Default PHB and, if MPLS is applicable, forwarded with an MPLS TC matching the Default PHB. TheCS1DSCP is not rewritten, ✨ no cap. Transporting a large variety of DSCPs (much greater than four) may be required across an interconnected network running MPLS Short Pipe Model transport for IP traffic. In that case, a tunnel based on the Pipe Model is among the possible approaches. The Pipe Model is outside the scope of this document 💅 - Short Pipe Model 💜: the DSCP likely changes, and the PHB might change too. This document describes a method to simplify Diffserv network interconnection when a DSCP rewrite can't be avoided. Honestly the most relatable one 😭
4.3. Treatment of Network Control Traffic at Carrier Interconnection Interfaces 🧚
Per Section 3.2 of RFC 4594, NC traffic marked by CS6 is expected at some interconnection interfaces. This document does not change RFC 4594, but it does point out that network control traffic received at a network ingress is generally different from the network control traffic inside a network, which is the main use of CS6 that RFC 4594 had in mind. For example, some CS6 traffic exchanged across carrier interconnections gets terminated right at the network ingress node, like when BGP runs between the two routers on opposite ends of an interconnection link. In that case, the operators would enter into a bilateral agreement to use CS6 for that BGP traffic 🤝
The end-to-end discussion in Section 4.2 is generally inapplicable to network control traffic. Network control traffic is generally meant to control a network, not to be transported between networks 🙈 One exception: network control traffic does make sense for a purchased transit agreement, and keeping the CS6 DSCP marking on transiting network control traffic is reasonable in some cases. Still, it's generally inappropriate to use CS6 for forwarding that traffic within the network providing the transit. Using an IP tunnel is suggested so the CS6 markings on transiting network control traffic are hidden from the network providing the transit. In that case, the Pipe Model for Diffserv tunneling is used 🌈
If the MPLS Short Pipe Model is deployed for unencapsulated IPv4 traffic, an IP network provider should limit access to the CS6 and CS7 DSCPs. That way, they're only used for network control traffic for the provider's own network 🔒
Interconnecting carriers should specify how to treat CS6-marked traffic received at a carrier interconnection that is going to be forwarded beyond the ingress node. An SLA covering the following cases is recommended when a provider wants to send CS6-marked traffic across an interconnection link and that traffic's destination is beyond the interconnected ingress node:
- Classification of traffic that is network control traffic for both domains 👑: this traffic should be classified and marked for the
CS6DSCP. - Classification of traffic that is network control traffic for the sending domain only 🍓: this traffic should be forwarded with a PHB that is appropriate for transiting NC service class traffic [RFC4594] in the receiving domain, e.g.,
AF31as specified by this document. For instance, GSMA IR.34 recommends an Interactive class /AF31to carry SIP and DIAMETER traffic. While this is service control traffic of high importance to interconnected Mobile Network Operators, it is certainly not network control traffic for a fixed network providing transit among such operators, so it should not receiveCS6treatment in that transit network 💀 - Any other
CS6-marked traffic 🫶: should be re-marked or dropped.
5. IANA Considerations 🎀
This document does not require any IANA actions. Nothing to register here, bestie ✨
6. Security Considerations 🔥
The DSCP field in the IP header can expose additional traffic classification information at network interconnections, compared to using a zero DSCP for all interconnect traffic. So if traffic classification information is sensitive, the DSCP field could be re-marked to zero to hide the classification as a countermeasure. The cost is losing Diffserv information and differentiated traffic handling on the interconnect and on subsequent networks. When AF PHBs are used, any such re-marking should respect AF PHB group boundaries, as further discussed at the end of Section 4. Treat this one seriously, it's a whole vibe 😭⚠️
This document does not introduce new features. It describes how to use existing ones. The Diffserv security considerations in [RFC2475] and [RFC4594] apply 🔐
7. References 📚
7.1. Normative References
Here are the normative references, all in one spot:
[RFC2474] 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,
DOI 10.17487/RFC2474, December 1998,
<http://www.rfc-editor.org/info/rfc2474>.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597,
DOI 10.17487/RFC2597, June 1999,
<http://www.rfc-editor.org/info/rfc2597>.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, DOI 10.17487/RFC3246, March 2002,
<http://www.rfc-editor.org/info/rfc3246>.
[RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen,
P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-
Protocol Label Switching (MPLS) Support of Differentiated
Services", RFC 3270, DOI 10.17487/RFC3270, May 2002,
<http://www.rfc-editor.org/info/rfc3270>.
[RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion
Marking in MPLS", RFC 5129, DOI 10.17487/RFC5129, January
2008, <http://www.rfc-editor.org/info/rfc5129>.
[RFC5865] Baker, F., Polk, J., and M. Dolly, "A Differentiated
Services Code Point (DSCP) for Capacity-Admitted Traffic",
RFC 5865, DOI 10.17487/RFC5865, May 2010,
<http://www.rfc-editor.org/info/rfc5865>.7.2. Informative References
And now the informative ones, for extra credit 🌸
[BGP-INTERCONNECTION]
Knoll, T., "BGP Class of Service Interconnection", Work in
Progress, draft-knoll-idr-cos-interconnect-17, November
2016.
[IR.34] GSMA, "Guidelines for IPX Provider networks (Previously
Inter-Service Provider IP Backbone Guidelines)", Official
Document IR.34, Version 11.0, November 2014,
<http://www.gsma.com/newsroom/wp-content/uploads/
IR.34-v11.0.pdf>.
[MEF23.1] MEF, "Implementation Agreement MEF 23.1: Carrier Ethernet
Class of Service - Phase 2", MEF 23.1, January 2012,
<http://metroethernetforum.org/PDF_Documents/
technical-specifications/MEF_23.1.pdf>.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, DOI 10.17487/RFC2475, December 1998,
<http://www.rfc-editor.org/info/rfc2475>.
[RFC2983] Black, D., "Differentiated Services and Tunnels",
RFC 2983, DOI 10.17487/RFC2983, October 2000,
<http://www.rfc-editor.org/info/rfc2983>.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, DOI 10.17487/RFC3662, December 2003,
<http://www.rfc-editor.org/info/rfc3662>.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594,
DOI 10.17487/RFC4594, August 2006,
<http://www.rfc-editor.org/info/rfc4594>.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
Diffserv Service Classes", RFC 5127, DOI 10.17487/RFC5127,
February 2008, <http://www.rfc-editor.org/info/rfc5127>.
[RFC5160] Levis, P. and M. Boucadair, "Considerations of Provider-
to-Provider Agreements for Internet-Scale Quality of
Service (QoS)", RFC 5160, DOI 10.17487/RFC5160, March
2008, <http://www.rfc-editor.org/info/rfc5160>.
[RFC7657] Black, D., Ed. and P. Jones, "Differentiated Services
(Diffserv) and Real-Time Communication", RFC 7657,
DOI 10.17487/RFC7657, November 2015,
<http://www.rfc-editor.org/info/rfc7657>.
[SLA-EXCHANGE]
Shah, S., Patel, K., Bajaj, S., Tomotaki, L., and M.
Boucadair, "Inter-domain SLA Exchange Attribute", Work in
Progress, draft-ietf-idr-sla-exchange-10, January 2017.
[Y.1566] ITU-T, "Quality of service mapping and interconnection
between Ethernet, Internet protocol and multiprotocol
label switching networks", ITU-T Recommendation Y.1566,
July 2012,
<http://www.itu.int/rec/T-REC-Y.1566-201207-I/en>.Appendix A. The MPLS Short Pipe Model and IP Traffic ✨
okay bestie, this appendix is where the Short Pipe Model gets real 🧚 The MPLS Short Pipe Model (also called penultimate hop label popping) is widely deployed in carrier networks, so it's giving very relevant energy 💅 If unencapsulated IP traffic rides over MPLS Short Pipe, the IP headers show up inside the last section of the MPLS domain. That's a big deal, because it changes how many PHBs and DSCPs a network provider can realistically support 🫶 Check out Figure 2 for the vibe.
For encapsulated IP traffic, only the outer tunnel header matters for forwarding 🎀 If the tunnel doesn't end inside the MPLS network section, only the outer tunnel DSCP is involved. The inner DSCP doesn't affect forwarding behavior, so all DSCPs could be used in the inner IP header without changing network behavior based on the outer MPLS header. Here, the Pipe Model applies 🦋
Layer 2 and Layer 3 VPN traffic all carry an additional MPLS label, so in this case the MPLS tunnel follows the Pipe Model 💜 Classification and queuing inside an MPLS network are always based on an MPLS label, not the outer IP header. No cap, that's a key detail 👑
Carriers often pick PHBs and DSCPs without thinking about interconnection 🙈 So PHBs and DSCPs usually differ between carriers. The exception is best-effort traffic. For everything else, a DSCP change should be expected at an interconnection, at least for unencapsulated IP traffic, even if the carriers have mapped the PHB properly 🍓
Here's the tea: RFC 3270 suggests the Short Pipe Model only applies to VPNs, but current networks also use it to carry non-tunneled IPv4 traffic 😭 Figure 2 shows this where Diffserv-Intercon is not used. The result is that the upstream network's internal DSCPs get exposed to the downstream network across the interconnection 💀
|
\|/ IPv4, DSCP_send
V
|
Peering Router
|
\|/ IPv4, DSCP_send
V
|
MPLS Edge Router
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d)
|
MPLS Core Router (penultimate hop label popping)
| \
| IPv4, DSCP_d | The DSCP needs to be in network-
| ^^^^^^^^| internal Diffserv context. The Core
\|/ > Router may require or enforce
V | that. The Edge Router may wrongly
| | classify, if the DSCP is not in
| / network-internal Diffserv context.
MPLS Edge Router
| \ Traffic leaves the network marked
\|/ IPv4, DSCP_d | with the network-internal
V > DSCP_d that must be dealt with
| | by the next network (downstream).
| /
Peer Router
| Re-mark DSCP to
\|/ IPv4, DSCP_send
V
|
Figure 2: Short Pipe Model / Penultimate Hop Popping ExampleThe packet's IP DSCP must be in a well-understood Diffserv context for schedulers and classifiers on the interfaces of the ultimate MPLS link (last link traversed before leaving the network). 🧠 The necessary Diffserv context is network-internal, and a network running in this mode enforces DSCP usage so it can get robust differentiated forwarding behavior 🔥
Without Diffserv-Intercon treatment, the traffic is likely to leave each network marked with network-internal DSCP. DSCP_send in the figure above has to be re-marked into the first network's Diffserv scheme at the ingress MPLS Edge Router, becoming DSCP_d in the example 🌸
So the traffic leaves this domain marked with the network-internal DSCP_d. This structure requires that every carrier deploys per-peer PHB and DSCP mapping schemes 😩
If Diffserv-Intercon is applied, DSCPs for traffic transiting the domain can be mapped from and remapped to an original DSCP ✨ Figure 3 shows the glow-up. Internal traffic can keep using internal DSCPs (like DSCP_d), and those internal DSCPs may also be used between a carrier and its direct customers 🦋
Internal Router
|
| Outer Header
\|/ IPv4, DSCP_send
V
|
Peering Router
| Re-mark DSCP to
\|/ IPv4, DSCP_ds-int Diffserv-Intercon DSCP and PHB
V
|
MPLS Edge Router
|
| Mark MPLS Label, TC_internal
\|/ Re-mark DSCP to
V (Inner: IPv4, DSCP_d) Domain Internal DSCP for
| the PHB
MPLS Core Router (penultimate hop label popping)
|
| IPv4, DSCP_d
| ^^^^^^
\|/
V
|
|
MPLS Edge Router--------------------+
| |
\|/ Re-mark DSCP to \|/ IPv4, DSCP_d
V IPv4, DSCP_ds-int V
| |
| |
Peer Router Domain Internal Broadband
| Access Router
\|/ Re-mark DSCP to \|/
V IPv4, DSCP_send V IPv4, DSCP_d
| |
Figure 3: Short Pipe Model Example with Diffserv-InterconAcknowledgements 🫶
Bob Briscoe and Gorry Fairhurst reviewed this specification and gave super rich feedback 💖 Brian Carpenter, Fred Baker, Al Morton, and Sebastien Jobert talked through the specification and helped make it better ✨ Mohamed Boucadair and Thomas Knoll helped by adding awareness of related work 🧚 And James Polk's discussion during IETF 89 helped improve the text on how this specification relates to RFCs 4594 and 5127 🌈
Authors' Addresses 📬
Ruediger Geib (editor) Deutsche Telekom Heinrich Hertz Str. 3-7 Darmstadt 64295 Germany
Phone: +49 6151 5812747 Email: Ruediger.Geib@telekom.de
David L. Black Dell EMC 176 South Street Hopkinton, MA United States of America
Phone: +1 (508) 293-7953 Email: david.black@dell.com
📦 where this page comes from
- ietf: rfc8100 2017-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms