RFC 2475

An Architecture for Differentiated Services

📅 published December 1998, from ietf

📜 An Architecture for Differentiated Services 🎀

Network Working Group, RFC 2475, Category: Informational, dated December 1998 🌸

Okay bestie, let's start with the basics! This RFC was written by S. Blake (Torrent Networking Technologies), D. Black (EMC Corporation), M. Carlson (Sun Microsystems), E. Davies (Nortel UK), Z. Wang (Bell Labs Lucent Technologies), and W. Weiss (Lucent Technologies). It's an Informational doc, so it's sharing knowledge with the community, not setting a standard 🧚. The title block doesn't list anything it obsoletes or updates, so it's standing on its own vibes ✨.

Status of this Memo ✨

So, the Status of this Memo is giving "this is just info, not a rule." This memo provides information for the Internet community. It does not specify an Internet standard of any kind 🙈. Distribution of this memo is unlimited, so share it with everyone you know 💖.

Copyright (C) The Internet Society (1998). All Rights Reserved. Legally speaking, this one belongs to the Internet Society 💅.

Abstract 🌈

Okay, the Abstract is basically the whole vibe in one go 💜. This document defines an architecture for implementing scalable service differentiation in the Internet. The clever part is how it stays scalable: it aggregates traffic classification state, and that state is carried by IP-layer packet marking using the DS field [DSFIELD] 🧚. Packets get classified and marked so they receive a particular per-hop forwarding behavior on every node along their path 🔥.

The sophisticated stuff, like classification, marking, policing, and shaping, only needs to happen at network boundaries or on hosts 👑. Network resources get allocated to traffic streams by service provisioning policies. Those policies decide how traffic gets marked and conditioned when it enters a differentiated services-capable network, and how that traffic gets forwarded once it's inside 🎀. Honestly? A wide variety of services can be built on top of these building blocks ✨💅.

Table of Contents 📚

   1.  Introduction .................................................  2
     1.1  Overview  .................................................  2
     1.2  Terminology ...............................................  4
     1.3  Requirements ..............................................  8
     1.4  Comparisons with Other Approaches .........................  9
   2.  Differentiated Services Architectural Model .................. 12
     2.1  Differentiated Services Domain ............................ 12
       2.1.1  DS Boundary Nodes and Interior Nodes .................. 12
       2.1.2  DS Ingress Node and Egress Node ....................... 13
     2.2  Differentiated Services Region ............................ 13
     2.3  Traffic Classification and Conditioning ................... 14
       2.3.1  Classifiers ........................................... 14
       2.3.2  Traffic Profiles ...................................... 15
       2.3.3  Traffic Conditioners .................................. 15
         2.3.3.1  Meters ............................................ 16
         2.3.3.2  Markers ........................................... 16
         2.3.3.3  Shapers ........................................... 17
         2.3.3.4  Droppers .......................................... 17
       2.3.4  Location of Traffic Conditioners and MF Classifiers ... 17
         2.3.4.1  Within the Source Domain .......................... 17
         2.3.4.2  At the Boundary of a DS Domain .................... 18
         2.3.4.3  In non-DS-Capable Domains ......................... 18
         2.3.4.4  In Interior DS Nodes .............................. 19
     2.4  Per-Hop Behaviors ......................................... 19
     2.5  Network Resource Allocation ............................... 20
   3.  Per-Hop Behavior Specification Guidelines .................... 21
   4.  Interoperability with Non-Differentiated Services-Compliant
       Nodes ........................................................ 25
   5.  Multicast Considerations ..................................... 26
   6.  Security and Tunneling Considerations ........................ 27
     6.1  Theft and Denial of Service ............................... 28
     6.2  IPsec and Tunneling Interactions .......................... 30
     6.3  Auditing .................................................. 32
   7.  Acknowledgements ............................................. 32
   8.  References ................................................... 33
   Authors' Addresses ............................................... 34
   Full Copyright Statement ......................................... 36

1. Introduction 🌸

1.1. Overview 💖

Let's get into it! This document defines an architecture for implementing scalable service differentiation in the Internet, which is the whole point of the RFC 🦋. A "Service" is basically the significant characteristics of packet transmission in one direction across a set of one or more paths within a network 🧚. Those characteristics can be quantitative or statistical, talking about throughput, delay, jitter, and/or loss. Or they can just be about some relative priority of access to network resources 👑.

Why bother? Because service differentiation is needed to handle heterogeneous application requirements and user expectations, and to allow differentiated pricing of Internet service 💅. Literally different apps have different needs, so it makes sense 🔥.

This architecture is built from a bunch of functional elements living in network nodes ✨. You get a small set of per-hop forwarding behaviors, packet classification functions, and traffic conditioning functions, which include metering, marking, shaping, and policing 🎀. The scalability trick is that complex classification and conditioning only happen at network boundary nodes. Then per-hop behaviors get applied to aggregates of traffic that have been marked using the DS field in the IPv4 or IPv6 headers [DSFIELD] 🦋. Per-hop behaviors are defined so you get a reasonably granular way to allocate buffer and bandwidth resources at each node among competing traffic streams 🌈. And per-application flow or per-customer forwarding state doesn't need to be kept in the core of the network. Not me being like "that's so efficient" 😭.

A distinction is maintained between these four things:

  • the service provided to a traffic aggregate,
  • the conditioning functions and per-hop behaviors used to realize services,
  • the DS field value (DS codepoint) used to mark packets to select a per-hop behavior, and
  • the particular node implementation mechanisms which realize a per-hop behavior.

Service provisioning and traffic conditioning policies are decoupled enough from the forwarding behaviors inside the network interior to allow a wide variety of service behaviors, with room for future expansion 💜. Iconic, right?

Now, quick heads-up 🚨: this architecture only provides service differentiation in one direction of traffic flow, so it's asymmetric 🙈. Developing a complementary symmetric architecture is a topic of current research, but it's outside the scope of this document. See for example [EXPLICIT] 🧚.

Sect. 1.2 is a glossary of terms used within this document 📚. Sec. 1.3 lists requirements addressed by this architecture, and Sec. 1.4 gives a brief comparison to other approaches for service differentiation 🎀. Sec. 2 discusses the components of the architecture in detail 💅. Sec. 3 proposes guidelines for per-hop behavior specifications 🌈. Sec. 4 discusses interoperability issues with nodes and networks that don't implement differentiated services as defined in this document and in [DSFIELD] 🫶. Sec. 5 discusses issues with multicast service delivery 🍓. And Sec. 6 addresses security and tunnel considerations 🔥.

1.2. Terminology 💅

okay bestie, this section is basically our glossary 🎀 it's a quick vibe check on the terms the rest of the doc keeps using. A few of these get a more precise definition later on, so if one feels a bit loose, don't panic ✨

  • Behavior Aggregate (BA): a DS behavior aggregate.
  • BA classifier: a classifier that picks packets based only on the contents of the DS field. 🎯
  • Boundary link: a link that connects the edge nodes of two domains. 🌉
  • Classifier: an entity that selects packets based on the contents of their headers, following defined rules. 🔍
  • DS behavior aggregate: a collection of packets with the same DS codepoint crossing a link in a particular direction. 🚂
  • DS boundary node: a DS node that connects one DS domain to a node either in another DS domain or in a domain that isn't DS-capable. 🚪
  • DS-capable: able to implement differentiated services the way this architecture describes. It's usually used for a domain full of DS-compliant nodes. 💪
  • DS codepoint: a specific value of the DSCP portion of the DS field, used to pick a PHB. 🧩
  • DS-compliant: enabled to support differentiated services functions and behaviors as defined in [DSFIELD], this document, and other differentiated services documents. It's usually used for a node or device. ✅
  • DS domain: a DS-capable domain. It's a contiguous set of nodes that run with a shared set of service provisioning policies and PHB definitions. 🏡
  • DS egress node: a DS boundary node, in its role of handling traffic as it leaves a DS domain. 👋
  • DS ingress node: a DS boundary node, in its role of handling traffic as it enters a DS domain. 🫶
  • DS interior node: a DS node that is not a DS boundary node. 🏠
  • DS field: the IPv4 header TOS octet or the IPv6 Traffic Class octet, when interpreted in line with the definition given in [DSFIELD]. The bits of the DSCP field encode the DS codepoint, while the remaining bits are currently unused. 🎀
  • DS node: a DS-compliant node. 💖
  • DS region: a set of contiguous DS domains that can offer differentiated services over paths across those DS domains. 🗺️
  • Downstream DS domain: the DS domain downstream of traffic flow on a boundary link. ⬇️
  • Dropper: a device that performs dropping. 💧
  • Dropping: the process of discarding packets based on specified rules, aka policing. 🚮
  • Legacy node: a node that implements IPv4 Precedence as defined in [RFC791,RFC1812] but isn't otherwise DS-compliant. 🦕
  • Marker: a device that performs marking. 🖍️
  • Marking: the process of setting the DS codepoint in a packet based on defined rules. This includes pre-marking and re-marking. 🏷️
  • Mechanism: a specific algorithm or operation (e.g., queueing discipline) that's implemented in a node to realize a set of one or more per-hop behaviors. ⚙️
  • Meter: a device that performs metering. 📏
  • Metering: the process of measuring the temporal properties (e.g., rate) of a traffic stream selected by a classifier. The instantaneous state of this process may be used to affect the operation of a marker, shaper, or dropper, and/or may be used for accounting and measurement purposes. 📊
  • Microflow: a single instance of an application-to-application flow of packets, identified by source address, source port, destination address, destination port and protocol ID. 🔗
  • MF Classifier: a multi-field (MF) classifier that selects packets based on the contents of some arbitrary number of header fields. That's usually some combo of source address, destination address, DS field, protocol ID, source port and destination port. 🧺
  • Per-Hop-Behavior (PHB): the externally observable forwarding behavior applied at a DS-compliant node to a DS behavior aggregate. 🦋
  • PHB group: a set of one or more PHBs that can only be meaningfully specified and implemented together, because they share a common constraint, like a queue servicing or queue management policy. A PHB group is a service building block that lets a set of related forwarding behaviors get specified together (e.g., four dropping priorities). A single PHB is just a special case of a PHB group. 👯
  • Policing: the process of discarding packets (by a dropper) within a traffic stream, following the state of a corresponding meter that enforces a traffic profile. 👮
  • Pre-mark: to set the DS codepoint of a packet before it enters a downstream DS domain. 🔖
  • Provider DS domain: the DS-capable provider of services to a source domain. 🏢
  • Re-mark: to change the DS codepoint of a packet, usually done by a marker in line with a TCA. ✏️
  • Service: the overall treatment of a defined subset of a customer's traffic, either within a DS domain or end-to-end. 🛎️
  • Service Level Agreement (SLA): a service contract between a customer and a service provider that specifies the forwarding service the customer should receive. The customer can be a user organization (source domain) or another DS domain (upstream domain). An SLA may include traffic conditioning rules that make up a TCA in whole or in part. 📜
  • Service Provisioning Policy: a policy that defines how traffic conditioners get configured on DS boundary nodes, and how traffic streams get mapped to DS behavior aggregates, so you can get a whole range of services. 🎛️
  • Shaper: a device that performs shaping. 🫧
  • Shaping: the process of delaying packets within a traffic stream so it conforms to some defined traffic profile. 🕰️
  • Source domain: a domain containing the node(s) that originate the traffic receiving a particular service. 🌱
  • Traffic conditioner: an entity that performs traffic conditioning functions and may contain meters, markers, droppers, and shapers. Traffic conditioners are typically deployed in DS boundary nodes only. A traffic conditioner may re-mark a traffic stream, or it may discard or shape packets to alter the temporal characteristics of the stream and bring it into compliance with a traffic profile. 🧴
  • Traffic conditioning: the control functions performed to enforce rules specified in a TCA, including metering, marking, shaping, and policing. 🧘
  • Traffic Conditioning Agreement (TCA): an agreement specifying classifier rules, any corresponding traffic profiles, and metering, marking, discarding and/or shaping rules that apply to the traffic streams the classifier selects. A TCA covers all of the traffic conditioning rules explicitly specified in an SLA, plus all of the rules implied by the relevant service requirements and/or by a DS domain's service provisioning policy. 🤝
  • Traffic profile: a description of the temporal properties of a traffic stream, such as rate and burst size. 📈
  • Traffic stream: an administratively significant set of one or more microflows that traverse a path segment. A traffic stream may consist of the set of active microflows selected by a particular classifier. 🌊
  • Upstream DS domain: the DS domain upstream of traffic flow on a boundary link. ⬆️

2. Differentiated Services Architectural Model 🦋

1.3. Requirements ✨

okay so the internet has been on a constant glow-up 📈. More hosts, more apps, more capacity, and it's not stopping anytime soon 💅. So any scalable way to do service differentiation has to be able to handle that growth, no cap 🔥.

These are the requirements the architecture was built to hit 👑:

  • should accommodate a wide variety of services and provisioning policies, extending end-to-end or within a particular (set of) network(s) 🌈
  • should allow decoupling of the service from the particular application in use 🎀
  • should work with existing applications without the need for application programming interface changes or host software modifications (assuming suitable deployment of classifiers, markers, and other traffic conditioning functions) 🧚
  • should decouple traffic conditioning and service provisioning functions from forwarding behaviors implemented within the core network nodes 💜
  • should not depend on hop-by-hop application signaling 🙈
  • should require only a small set of forwarding behaviors whose implementation complexity does not dominate the cost of a network device, and which will not introduce bottlenecks for future high-speed system implementations ⭐
  • should avoid per-microflow or per-customer state within core network nodes 🦋
  • should utilize only aggregated classification state within the network core 🫶
  • should permit simple packet classification implementations in core network nodes (BA classifier) 🍓
  • should permit reasonable interoperability with non-DS-compliant network nodes 🌸
  • should accommodate incremental deployment 💖

1.4. Comparisons with Other Approaches 💅

Okay, this is the fun part 🤭. The differentiated services architecture in this document has a bunch of rivals, and it's lowkey iconic to see how it stacks up. We sort those alternatives into five categories: relative priority marking, service marking, label switching, Integrated Services/RSVP, and static per-hop classification 🎀.

First up, relative priority marking. This includes IPv4 Precedence marking as defined in [RFC791], 802.5 Token Ring priority [TR], and the default interpretation of 802.1p traffic classes [802.1p]. The vibe here is that the application, host, or proxy node picks a relative priority (a "precedence") for a packet, like delay or discard priority. Then the network nodes along the transit path apply the forwarding behavior that matches that priority value in the packet's header 📦. Honestly, our architecture is basically a glow-up of this model 💖. We spell out the role of boundary nodes and traffic conditioners more clearly, and our per-hop behavior model allows more general forwarding behaviors than just relative delay or discard priority ✨.

Next is the service marking model, which is giving IPv4 TOS as defined in [RFC1349] 🌷. Each packet gets marked with a request for a "type of service," which might be "minimize delay," "maximize throughput," "maximize reliability," or "minimize cost." Network nodes can pick routing paths or forwarding behaviors that are engineered to meet that request. This is subtly different from our architecture, and it's worth noting that we do not describe using the DS field as an input to route selection 🙅‍♀️. The TOS markings in [RFC1349] are super generic and don't cover the full range of possible service semantics. Also, the request is tied to each individual packet, but some service semantics depend on how a whole sequence of packets is treated in aggregate 🧩. This model doesn't handle growth in the number and range of future services very well, since the codepoint space is small. It also means every core node has to be configured with a TOS->forwarding behavior association 😩. Standardizing service markings would mean standardizing service offerings, and that's outside the IETF's scope 🙃. Still, the DS codepoint space is set up to allow locally significant codepoints that a provider can use to support service marking semantics [DSFIELD] 🎀.

Then there's the label switching model, also known as the virtual circuit model. Examples are Frame Relay, ATM, and MPLS [FRELAY, ATM] 🛤️. Here, path forwarding state and traffic management or QoS state gets set up for traffic streams on every hop along a network path. Traffic aggregates of varying granularity get associated with a label switched path at an ingress node. Then the packets or cells on each label switched path get marked with a forwarding label, which is used to look up the next-hop node, the per-hop forwarding behavior, and the replacement label at each hop 🏷️. This model gives finer-grained resource allocation, since label values aren't globally significant and only matter on a single link. So resources can be reserved for the aggregate of packets or cells received on a link with a particular label. The label switching semantics also control next-hop selection, which lets a traffic stream follow a specially engineered path through the network 🗺️. The catch is that you pay for that granularity with extra management and configuration work to establish and maintain the label switched paths 😮‍💨. On top of that, the forwarding state at each node scales in proportion to the number of edge nodes in the network in the best case (assuming multipoint-to-point label switched paths). In the worst case, when edge-edge label switched paths with provisioned resources are used, it scales in proportion to the square of the number of edge nodes 📈💀.

The Integrated Services/RSVP model uses traditional datagram forwarding by default, but it lets sources and receivers exchange signaling messages. Those messages set up extra packet classification and forwarding state on each node along the path between them [RFC1633, RSVP] 🧭. Without state aggregation, the state on each node scales in proportion to the number of concurrent reservations. On high-speed links that number can get really big 😳. This model also needs application support for the RSVP signaling protocol. Differentiated services mechanisms can be used to aggregate Integrated Services/RSVP state in the core of the network [Bernet] 🫧.

A variant of the Integrated Services/RSVP model drops the hop-by-hop signaling requirement by only using "static" classification and forwarding policies, which are implemented in each node along a network path 🧊. These policies get updated on administrative timescales, not in response to the instantaneous mix of microflows active in the network. The state requirements for this variant can be potentially worse than with RSVP, especially in backbone nodes 🏛️. That's because the number of static policies that might apply at a node over time may be larger than the number of active sender-receiver sessions that could have installed reservation state on that node. Sure, large numbers of classifier rules and forwarding policies might be computationally feasible, but the management burden of installing and maintaining those rules on every node in a backbone network that a traffic stream might cross is seriously substantial 😭.

Even though we're contrasting our architecture with all these models, links and nodes using these techniques can still be used to extend differentiated services behaviors and semantics across a layer-2 switched infrastructure (like 802.1p LANs or Frame Relay/ATM backbones) that interconnects DS nodes 🌐. In the case of MPLS, it can even be used as an alternative intra-domain implementation technology 🔁. Constraints from a specific link-layer technology in certain regions of a DS domain (or in a network providing access to DS domains) may mean traffic gets differentiated on a coarser grain basis 🥲. Depending on how PHBs get mapped to different link-layer services, and how packets are scheduled over a restricted set of priority classes (or virtual circuits of different category and capacity), all or only some of the PHBs in use may be supportable. Some of them might even be indistinguishable 🫠.

2. Differentiated Services Architectural Model 🌈

The differentiated services architecture is built on a simple idea 💡. Traffic entering a network gets classified and possibly conditioned at the network's boundaries, then assigned to different behavior aggregates. Each behavior aggregate is identified by a single DS codepoint 🏷️. Inside the core of the network, packets are forwarded according to the per-hop behavior tied to their DS codepoint. In this section we talk about the key components inside a differentiated services region, the traffic classification and conditioning functions, and how differentiated services are achieved by combining traffic conditioning with PHB-based forwarding 🎀✨.

2.1. Differentiated Services Domain 🏰

A DS domain is a contiguous set of DS nodes. They all run with a common service provisioning policy and the same set of PHB groups implemented on each node 🤝. A DS domain has a well-defined boundary made up of DS boundary nodes. Those boundary nodes classify and possibly condition ingress traffic, making sure that packets transiting the domain are marked properly so they select a PHB from one of the PHB groups supported in the domain 🚪. Nodes inside the DS domain pick the forwarding behavior for each packet based on its DS codepoint. They map that value to one of the supported PHBs using either the recommended codepoint->PHB mapping or a locally customized mapping [DSFIELD] 🗂️. Heads up 🚨: including non-DS-compliant nodes inside a DS domain may lead to unpredictable performance, and it may get in the way of satisfying service level agreements (SLAs) 😬.

A DS domain usually consists of one or more networks under the same administration. For example, an organization's intranet or an ISP 🏢. The administration of the domain is responsible for making sure that adequate resources are provisioned and/or reserved to support the SLAs the domain offers 📋💜.

2.1.1. DS Boundary Nodes and Interior Nodes

okay so a DS domain is made of two kinds of nodes: DS boundary nodes 🚪 and DS interior nodes 🏠. Boundary nodes hook the DS domain up to other DS or non-DS-capable domains, while interior nodes only connect to other interior or boundary nodes inside the same DS domain 🫶.

Both boundary and interior nodes must be able to apply the appropriate PHB to packets based on the DS codepoint, or else unpredictable behavior may result 💀. Boundary nodes may also be required to do traffic conditioning as spelled out in a traffic conditioning agreement (TCA) between their DS domain and the peering domain they connect to (see Sec. 2.3.3) 📜.

Interior nodes may be able to do some light traffic conditioning, like DS codepoint re-marking 🎀. Interior nodes that do fancier classification and traffic conditioning are basically acting like DS boundary nodes (see Sec. 2.3.4.4) 💅.

A host in a network containing a DS domain may act as a DS boundary node for traffic from apps running on that host, so we say the host is within the DS domain 🧚. If a host doesn't act as a boundary node, then the DS node topologically closest to that host acts as the boundary node for that host's traffic 🌸.

2.1.2. DS Ingress Node and Egress Node

DS boundary nodes act as both a DS ingress node and a DS egress node, for different directions of traffic 🦋. Traffic enters a DS domain at a DS ingress node and leaves at a DS egress node. An ingress node is responsible for making sure traffic entering the DS domain conforms to any TCA between it and the other domain it's connected to 🔥. An egress node may perform traffic conditioning functions on traffic forwarded to a directly connected peering domain, depending on the TCA details between the two domains ✨. Note that a DS boundary node may act as a DS interior node for some set of interfaces 👑.

2.2. Differentiated Services Region

okay so a differentiated services region (DS Region) is a set of one or more contiguous DS domains 🌈. DS regions can support differentiated services along paths that span the domains within the region 💜.

The DS domains in a DS region may support different PHB groups internally and different codepoint->PHB mappings. However, to permit services that span across the domains, the peering DS domains must each establish a peering SLA that defines (either explicitly or implicitly) a TCA, which specifies how transit traffic from one DS domain to another is conditioned at the boundary between the two DS domains 🤝.

It's possible that several DS domains within a DS region adopt a common service provisioning policy and support a common set of PHB groups and codepoint mappings, which means no traffic conditioning is needed between those domains 🙌.

2.3. Traffic Classification and Conditioning

Differentiated services get extended across a DS domain boundary by setting up a SLA between an upstream network and a downstream DS domain 🎀. The SLA may specify packet classification and re-marking rules, and it may also specify traffic profiles and actions for traffic streams that are in- or out-of-profile (see Sec. 2.3.2). The TCA between the domains is derived (explicitly or implicitly) from this SLA 📜.

The packet classification policy identifies the subset of traffic that may receive a differentiated service by being conditioned and/or mapped to one or more behavior aggregates (by DS codepoint re-marking) within the DS domain 💖.

Traffic conditioning does metering, shaping, policing and/or re-marking so that traffic entering the DS domain follows the TCA rules, per the domain's service provisioning policy 🧁. How much conditioning you need depends on the service offering, and it can range from simple codepoint re-marking all the way to complex policing and shaping 😭. The details of traffic conditioning policies negotiated between networks are outside the scope of this document 🙈.

2.3.1. Classifiers

Packet classifiers pick packets in a traffic stream based on the content of some portion of the packet header 👀. There are two types. The BA (Behavior Aggregate) Classifier classifies packets based on the DS codepoint only. The MF (Multi-Field) classifier selects packets based on the value of a combination of one or more header fields, such as source address, destination address, DS field, protocol ID, source port and destination port numbers, and other info like incoming interface 🫣.

Classifiers are used to "steer" packets matching some specified rule to an element of a traffic conditioner for further processing 🧭. Classifiers must be configured by some management procedure in accordance with the appropriate TCA 📋.

The classifier should authenticate the information it uses to classify the packet (see Sec. 6) 🔐.

Note that if upstream packet fragmentation happens, MF classifiers that examine the contents of transport-layer header fields may incorrectly classify packet fragments after the first one 😬. A possible solution is to maintain fragmentation state, but that isn't a general solution because of the possibility of upstream fragment re-ordering or divergent routing paths 🌀. The policy to apply to packet fragments is outside the scope of this document 🙃.

2.3.2. Traffic Profiles

A traffic profile specifies the temporal properties of a traffic stream selected by a classifier ⏰. It provides rules for deciding whether a particular packet is in-profile or out-of-profile. For example, a profile based on a token bucket may look like:

codepoint=X, use token-bucket r, b

The profile above indicates that all packets marked with DS codepoint X should be measured against a token bucket meter with rate r and burst size b. In this example, out-of-profile packets are those packets in the traffic stream which arrive when insufficient tokens are available in the bucket 🪣. The concept of in- and out-of-profile can be extended to more than two levels, e.g., multiple levels of conformance with a profile may be defined and enforced 🌟.

Different conditioning actions may be applied to in-profile packets and out-of-profile packets, or different accounting actions may be triggered 📊. In-profile packets may be allowed to enter the DS domain without further conditioning; or, alternatively, their DS codepoint may be changed. The latter happens when the DS codepoint is set to a non-Default value for the first time [DSFIELD], or when the packets enter a DS domain that uses a different PHB group or codepoint->PHB mapping policy for this traffic stream 🔄. Out-of-profile packets may be queued until they are in-profile (shaped), discarded (policed), marked with a new codepoint (re-marked), or forwarded unchanged while triggering some accounting procedure 🗑️. Out-of-profile packets may be mapped to one or more behavior aggregates that are "inferior" in some dimension of forwarding performance to the BA into which in-profile packets are mapped 🐢.

Note that a traffic profile is an optional component of a TCA, and its use is dependent on the specifics of the service offering and the domain's service provisioning policy 💅.

2.3.3. Traffic Conditioners

A traffic conditioner may contain the following elements: meter, marker, shaper, and dropper 🧩. A traffic stream is selected by a classifier, which steers the packets to a logical instance of a traffic conditioner. A meter is used (where appropriate) to measure the traffic stream against a traffic profile. The state of the meter with respect to a particular packet (e.g., whether it is in- or out-of-profile) may be used to affect a marking, dropping, or shaping action 📏.

When packets exit the traffic conditioner of a DS boundary node, the DS codepoint of each packet must be set to an appropriate value 🏷️.

Fig. 1 shows the block diagram of a classifier and traffic conditioner. Note that a traffic conditioner may not necessarily contain all four elements. For example, in the case where no traffic profile is in effect, packets may only pass through a classifier and a marker 🖼️.

                               +-------+
                               |       |-------------------+
                        +----->| Meter |                   |
                        |      |       |--+                |
                        |      +-------+  |                |
                        |                 V                V
                  +------------+      +--------+      +---------+
                  |            |      |        |      | Shaper/ |
    packets =====>| Classifier |=====>| Marker |=====>| Dropper |=====>
                  |            |      |        |      |         |
                  +------------+      +--------+      +---------+

Fig. 1: Logical View of a Packet Classifier and Traffic Conditioner

2.3.3.1. Meters

Traffic meters measure the temporal properties of the stream of packets selected by a classifier against a traffic profile specified in a TCA 📐. A meter passes state information to other conditioning functions to trigger a particular action for each packet which is either in- or out-of-profile (to some extent) 🚦.

2.3.3.2. Markers

Packet markers set the DS field of a packet to a particular codepoint, adding the marked packet to a particular DS behavior aggregate 🖍️. The marker may be configured to mark all packets that are steered to it to a single codepoint, or it may be configured to mark a packet to one of a set of codepoints used to select a PHB in a PHB group, according to the state of a meter. When the marker changes the codepoint in a packet, it is said to have "re-marked" the packet 🎨.

2.3.3.3. Shapers

Shapers delay some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile ⏳. A shaper usually has a finite-size buffer, and packets may be discarded if there isn't sufficient buffer space to hold the delayed packets 🫧.

2.3.3.4. Droppers

Droppers discard some or all of the packets in a traffic stream in order to bring the stream into compliance with a traffic profile 🗑️. This process is known as "policing" the stream. Note that a dropper can be implemented as a special case of a shaper by setting the shaper buffer size to zero (or a few) packets 🙌.

2.3.4. Location of Traffic Conditioners and MF Classifiers

Traffic conditioners are usually located within DS ingress and egress boundary nodes, but they may also be located in nodes within the interior of a DS domain, or within a non-DS-capable domain 📍.

2.3.4.1 Within the Source Domain 🌸

okay so the source domain is the domain that holds the node(s) which originate the traffic getting a particular service 💅. Traffic sources and intermediate nodes inside a source domain can do classification and conditioning stuff. Traffic leaving the source domain across a boundary can be marked by the sources themselves or by intermediate nodes before it leaves. This is called initial marking, or "pre-marking" 🎀.

Picture a company with a policy that the CEO's packets get higher priority 👑. The CEO's host can mark the DS field of every outgoing packet with a DS codepoint that means "higher priority." Or the first-hop router right next to the CEO's host can classify the traffic and stamp the correct DS codepoint on the CEO's packets. This high priority traffic can also get conditioned near the source, so there's a limit on how much of it any one source gets forwarded 🫶.

Pre-marking has some serious perks ✨. First, a traffic source can more easily factor in an application's preferences when deciding which packets deserve better treatment 💖. Also, classification is way simpler before traffic gets mixed with packets from other sources, because fewer classification rules have to be applied inside a single node 🧠.

Since marking can be spread across multiple nodes, the source DS domain is responsible for making sure its aggregated traffic heading toward its provider DS domain conforms to the appropriate TCA 😭. Extra allocation mechanisms like bandwidth brokers or RSVP can dynamically allocate resources for a particular DS behavior aggregate inside the provider's network [2BIT, Bernet] 🦋. The boundary node of the source domain should also keep an eye on TCA conformance, and it may police, shape, or re-mark packets as necessary 💅.

2.3.4.2 At the Boundary of a DS Domain 🧚

Traffic streams can be classified, marked, and conditioned on either end of a boundary link: the DS egress node of the upstream domain or the DS ingress node of the downstream domain 🍓. The SLA between the two domains should spell out which domain is responsible for mapping traffic streams to DS behavior aggregates and conditioning those aggregates so they match the appropriate TCA. But a DS ingress node must assume that incoming traffic may not conform to the TCA, and it must be ready to enforce the TCA according to local policy 🔥.

When packets are pre-marked and conditioned in the upstream domain, the downstream DS domain may need way fewer classification and conditioning rules 🙌. In that case, the downstream domain may only need to re-mark or police the incoming behavior aggregates to enforce the TCA. Fancier services that depend on the path or the source may still require MF classification at the downstream domain's ingress nodes 💜.

If a DS ingress node is connected to an upstream non-DS-capable domain, the DS ingress node must be able to perform all the necessary traffic conditioning functions on the incoming traffic 💀.

2.3.4.3 In non-DS-Capable Domains 🙈

Traffic sources or intermediate nodes in a non-DS-capable domain may use traffic conditioners to pre-mark traffic before it reaches the ingress of a downstream DS domain. This way, the local policies for classification and marking can stay under wraps 🤫.

2.3.4.4 In Interior DS Nodes 🌈

The basic architecture assumes that complex classification and traffic conditioning functions only live in a network's ingress and egress boundary nodes, but nothing rules out putting these functions in the interior of the network 🫠. For example, stricter access policies may be enforced on a transoceanic link, which would require MF classification and traffic conditioning in the upstream node on that link. Heads up though: this approach may hit scaling limits, because the number of classification and conditioning rules that might need to be maintained could get huge 😅.

2.4 Per-Hop Behaviors 💖

A per-hop behavior (PHB) is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate. "Forwarding behavior" is a broad concept here 🦋. For example, if only one behavior aggregate occupies a link, the observable forwarding behavior (i.e., loss, delay, jitter) will often depend only on how loaded the link is (assuming the behavior uses a work-conserving scheduling discipline). Useful behavioral distinctions mostly show up when multiple behavior aggregates compete for buffer and bandwidth resources on a node. The PHB is how a node allocates resources to behavior aggregates, and useful differentiated services get built on top of this basic hop-by-hop resource allocation mechanism ✨.

The simplest PHB guarantees a minimal bandwidth allocation of X% of a link (over some reasonable time interval) to a behavior aggregate 🍓. This is pretty easy to measure under a bunch of different competing traffic conditions. A slightly fancier PHB would guarantee a minimal bandwidth allocation of X% of a link, with proportional fair sharing of any excess link capacity 💅. In general, the observable behavior of a PHB may depend on certain constraints on the traffic characteristics of its behavior aggregate, or on the characteristics of other behavior aggregates 🧠.

PHBs can be specified by their resource priority (e.g., buffer, bandwidth) relative to other PHBs, or by their relative observable traffic characteristics (e.g., delay, loss) 🫶. These PHBs work as building blocks for allocating resources, and they should be specified as a group (a PHB group) for consistency 💜. PHB groups will usually share a common constraint that applies to each PHB in the group, like a packet scheduling or buffer management policy. The relationship between PHBs in a group may be absolute or relative priority (e.g., discard priority by means of deterministic or stochastic thresholds), but that's not required (e.g., N equal link shares) 🙃. A single PHB defined on its own is a special case of a PHB group.

PHBs are implemented in nodes by means of some buffer management and packet scheduling mechanisms 🔧. They're defined in terms of behavior characteristics that matter for service provisioning policies, not in terms of particular implementation mechanisms 🌸. In general, a variety of implementation mechanisms may be suitable for implementing a particular PHB group. It's also likely that more than one PHB group may be implemented on a node and used within a domain 👑. PHB groups should be defined so that the proper resource allocation between groups can be inferred, and so that integrated mechanisms can be built that support two or more groups at the same time 🧚. A PHB group definition should point out possible conflicts with previously documented PHB groups that might stop them from running simultaneously 😬.

As described in [DSFIELD], a PHB is selected at a node by mapping the DS codepoint in a received packet 🎀. Standardized PHBs have a recommended codepoint. However, the total space of codepoints is larger than the space available for recommended codepoints for standardized PHBs, and [DSFIELD] leaves room for locally configurable mappings 🌈. A codepoint->PHB mapping table may contain both 1->1 and N->1 mappings. All codepoints must be mapped to some PHB. In the absence of some local policy, codepoints that aren't mapped to a standardized PHB in accordance with that PHB's specification should be mapped to the Default PHB 💖.

2.5 Network Resource Allocation ✨

The implementation, configuration, operation, and administration of the supported PHB groups in the nodes of a DS Domain should effectively partition the resources of those nodes and the inter-node links between behavior aggregates, in line with the domain's service provisioning policy 🏰. Traffic conditioners can further control how these resources get used by enforcing TCAs, and possibly through operational feedback from the nodes and traffic conditioners in the domain 🫶. A range of services can be deployed without complex traffic conditioning functions (e.g., using only static marking policies), but functions like policing, shaping, and dynamic re-marking are what let you deploy services that promise quantitative performance metrics 🔥.

The configuration of, and the interaction between, traffic conditioners and interior nodes should be managed by the administrative control of the domain, and it may require operational control through protocols and a control entity 🧠. There's a wide range of possible control models 🌸.

The precise nature and implementation of the interaction between these components is outside the scope of this architecture 🙈. However, scalability requires that the control of the domain doesn't require micro-management of the network resources 💅. The most scalable control model would operate nodes in open-loop in the operational timeframe, and would only require administrative-timescale management as SLAs are varied 🦋. This simple model may be unsuitable in some circumstances, and some automated but slowly varying operational control (minutes rather than seconds) may be desirable to balance the utilization of the network against the recent load profile 🌈.

3. Per-Hop Behavior Specification Guidelines ✨

Okay so the basic rules for standardizing a per-hop behavior (PHB) live in [DSFIELD]. This section adds extra guidelines for PHB (group) specs so implementers end up building the same thing 🫶 Before a PHB group gets proposed for standardization, it SHOULD satisfy these guidelines, as appropriate, to keep this architecture intact 💅

G.1: A PHB standard MUST specify a recommended DS codepoint picked from the codepoint space reserved for standard mappings [DSFIELD]. Recommended codepoints will be assigned by the IANA 🎀 A PHB proposal MAY recommend a temporary codepoint from the EXP/LU space to help with inter-domain experimentation. Figuring out a packet's PHB MUST NOT require looking at any packet header fields beyond the DS field 👀

G.2: Okay, the spec for each newly proposed PHB group SHOULD include an overview of the behavior and its purpose 🌸 That overview SHOULD include the problem or problems the PHB group is aiming at. It SHOULD also cover the basic concepts behind the group, and those concepts SHOULD include, but are not restricted to, queueing behavior, discard behavior, and output link selection behavior. Lastly, the overview SHOULD spell out how the PHB group solves the problem or problems in the problem statement. Main character energy, literally 👑

G.3: A PHB group specification SHOULD indicate how many individual PHBs it specifies 🧚 If there are multiple PHBs, the interactions between them, and any constraints that every PHB in the group must respect globally, SHOULD be clearly specified. For example, the specification MUST indicate whether the probability of packet reordering within a microflow goes up when different packets in that microflow get marked for different PHBs in the group. That one is a big deal, bestie 😭

G.4: When a PHB group only works properly if certain constraints (like a provisioning restriction) are respected, the PHB definition SHOULD describe the behavior when those constraints get violated 💀 And if things like packet discard or re-marking are required when a constraint is violated, then those actions SHOULD be specifically stipulated 🙈

G.5: A PHB group MAY be specified for local use within a domain, so it can offer some domain-specific functionality or services 🍓 In that case the PHB spec is still useful, because it gives vendors one consistent definition of the group. Any PHB group defined for local use SHOULD NOT be considered for standardization, but it MAY be published as an Informational RFC. A PHB group meant for general use, on the other hand, goes through a much stricter standardization process, so every PHB proposal SHOULD clearly say whether it's meant for general or local use 🫶

It's recognized that PHB groups can be designed to provide host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge services. For consistency, use of the term "end-to-end" in a PHB definition SHOULD be read as "host-to-host" 🦋

Other PHB groups MAY be defined and deployed locally within domains for experimental or operational purposes. There is no requirement that these PHB groups MUST be publicly documented, but they SHOULD use DS codepoints from one of the EXP/LU pools defined in [DSFIELD] ✨

G.6: It MAY be possible or appropriate for a packet marked for a PHB inside a PHB group to be re-marked to select another PHB in that group, either within a domain or across a domain boundary 🌈 Typically there are three reasons for this kind of PHB modification:

  • a. The codepoints associated with the PHB group are collectively meant to carry state about the network,
  • b. Conditions exist which require PHB promotion or demotion of a packet (this assumes the PHBs in the group can be ranked in some order),
  • c. The boundary between two domains isn't covered by an SLA. In that case, the codepoint/PHB to select when crossing the boundary link is decided by the local policy of the upstream domain.

A PHB specification SHOULD clearly state the circumstances under which packets marked for a PHB in a PHB group MAY, or SHOULD, be modified (for example, promoted or demoted) to another PHB in the group 🔥 If it's undesirable for a packet's PHB to change, the specification SHOULD clearly state the consequent risks when the PHB does get modified. One possible risk of changing a packet's PHB, whether inside or outside a PHB group, is a higher probability of packet reordering within a microflow 😬 PHBs in a group MAY carry some host-to-host, WAN edge-to-WAN edge, and/or domain edge-to-domain edge semantics that are hard to duplicate if packets get re-marked to select another PHB from the group (or otherwise) 💅

For certain PHB groups, it MAY be appropriate to reflect a state change in the node by re-marking packets to specify another PHB from within the group. If a PHB group is designed to reflect the state of a network, the PHB definition MUST adequately describe the relationship between the PHBs and the states they reflect. Also, if these PHBs limit the forwarding actions a node can perform in some way, those constraints MAY be specified as actions the node SHOULD, or MUST, perform 🧚

G.7: A PHB group specification SHOULD include a section on how tunneling affects the usefulness of the PHB group 🎀 That section SHOULD cover the implications for the usefulness of the group when a newly created outer header is added and the original DS field of the inner header gets encapsulated in a tunnel. It SHOULD also discuss what changes might be applied to the inner header at the tunnel egress, when both the codepoints from the inner header and the outer header are accessible (see Sec. 6.2) 🦋

G.8: Specifying PHB groups is likely to be incremental, so when new PHB groups are proposed, their known interactions with previously specified PHB groups SHOULD be documented 🌸 A new PHB group can be totally new in scope, or it can be an extension to an existing PHB group. If the PHB group is entirely independent of some or all of the existing PHB specifications, a section SHOULD be included in the PHB specification explaining how the new group can co-exist with the PHB groups already standardized. That section might point out things like the possibility of packet reordering within a microflow for packets marked with codepoints from two separate PHB groups 👀 If running two (or more) different PHB groups concurrently in the same node is impossible or harmful, that SHOULD be stated. And if running them concurrently requires some specific node behaviors when packets marked for PHBs from different groups are processed at the same time, those behaviors SHOULD be stated too 🫶

Care SHOULD be taken to avoid circularity in the definitions of PHB groups 🌀

If the proposed PHB group is an extension to an existing PHB group, a section SHOULD be included in the PHB group specification explaining how the extension interoperates with the behavior it extends. Further, if the extension alters or more narrowly defines the existing behavior in some way, this SHOULD also be clearly indicated ✨

G.9: Each PHB specification SHOULD include a section listing minimal conformance requirements for implementations of the PHB group 🎀 This conformance section exists so you can spell out the details of a behavior while still allowing implementation variation to the extent the PHB spec permits. It can take the form of rules, tables, pseudo-code, or tests 💖

G.10: A PHB specification SHOULD include a section on the security implications of the behavior 🚨 That section SHOULD include a discussion of re-marking the inner header's codepoint at the tunnel egress and how it affects the desired forwarding behavior.

This one is serious, so read it carefully 🙈

Further, this section SHOULD also discuss how the proposed PHB group could be used in denial-of-service attacks, reduction of service contract attacks, and service contract violation attacks. Lastly, this section SHOULD discuss possible means of detecting such attacks as they relate to the proposed behavior 💀

G.11: A PHB specification SHOULD include a section detailing the configuration and management issues that might affect how the PHB operates and that might impact candidate services that could use the PHB 🍓

G.12: It is strongly RECOMMENDED that an appendix be provided with each PHB specification, looking at the implications of the proposed behavior for current and potential services 🌈 These services could include, but are not restricted to, user-specific, device-specific, domain-specific, or end-to-end services. It is also strongly RECOMMENDED that the appendix include a section describing how those services get verified by users, devices, and/or domains 🫶

G.13: It is RECOMMENDED that an appendix be provided with each PHB specification targeted for local use within a domain, giving guidance on PHB selection for packets forwarded into a peer domain that doesn't support the PHB group 🦋

G.14: It is RECOMMENDED that an appendix be provided with each PHB specification that considers the impact of the proposed PHB group on existing higher-layer protocols 💅 In some circumstances, PHBs MAY allow for possible changes to higher-layer protocols, and those changes may increase or decrease the usefulness of the proposed PHB group 🔥

G.15: It is RECOMMENDED that an appendix be provided with each PHB specification that recommends mappings to link-layer QoS mechanisms, so the intended PHB behavior is supported across a shared-medium or switched link layer 🧚 Figuring out the most appropriate mapping between a PHB and a link-layer QoS mechanism depends on lots of factors and is outside the scope of this document, but the specification SHOULD attempt to offer some guidance 💖

4. Interoperability with Non-Differentiated Services-Compliant Nodes ✨

Okay bestie, so first we need a name for the nodes that don't play the DS game. 🎀 A non-DS-compliant node (non-DS-compliant node) is any node that doesn't read the DS field the way [DSFIELD] says, and/or doesn't implement some or all of the standardized PHBs (or the ones used inside a particular DS domain). It could be the hardware, or it could just be how the node is configured. 🧚

Then there's the legacy node, which is a special case of non-DS-compliant node. It does IPv4 Precedence classification and forwarding as defined in [RFC791, RFC1812], but it's otherwise not DS-compliant. 💅 The precedence values in the IPv4 TOS octet were designed on purpose to match the Class Selector Codepoints defined in [DSFIELD], and the precedence forwarding behaviors in [RFC791, RFC1812] follow the Class Selector PHB Requirements also defined in [DSFIELD]. Iconic, right? 😭

Here's the key difference between a legacy node and a DS-compliant node. A legacy node may or may not interpret bits 3-6 of the TOS octet as defined in [RFC1349] (the "DTRC" bits). In practice, it won't interpret those bits as specified in [DSFIELD]. We're also assuming the TOS markings from [RFC1349] are deprecated. 🙈 And any node that is non-DS-compliant but isn't a legacy node may show unpredictable forwarding behaviors for packets with non-zero DS codepoints. Yikes 💀

Now, differentiated services depend on the resource allocation mechanisms that per-hop behavior implementations provide in nodes. So if traffic goes through a non-DS-compliant node, or through a non-DS-capable domain, the quality or statistical assurance level of a service might break down. Not ideal, periodt 😤

We're going to look at two separate cases. 🦋

Case one is using non-DS-compliant nodes inside a DS domain. PHB forwarding is mainly useful for handing out scarce node and link resources in a controlled way. On fast, lightly loaded links, the worst-case packet delay, jitter, and loss might be negligible, so putting a non-DS-compliant node on the upstream end of a link like that might not cause any service degradation. 🌸 In more realistic situations though, a node without PHB forwarding can make it impossible to offer low-delay, low-loss, or provisioned bandwidth services across paths that go through that node. 😬 A legacy node can be an acceptable alternative, though, as long as two things are true: the DS domain only uses the Class Selector Codepoints defined in [DSFIELD], and the specific precedence implementation in the legacy node gives forwarding behaviors that are compatible with the services offered along the paths through it. 🫶

Important note: you have to restrict the codepoints in use to the Class Selector Codepoints. The legacy node may or may not interpret bits 3-5 according to [RFC1349], which could lead to unpredictable forwarding results. Not a vibe 🚫

Case two is about services that travel through non-DS-capable domains. For the sake of argument, we assume that a non-DS-capable domain doesn't deploy traffic conditioning functions on its boundary nodes. So even if the domain is made of legacy or DS-compliant interior nodes, not having traffic enforcement at the boundaries limits how consistently some services can be delivered across the domain. 👑

A DS domain and a non-DS-capable domain can negotiate an agreement about how egress traffic from the DS domain should be marked before it enters the non-DS-capable domain. That agreement might be checked for compliance by traffic sampling instead of rigorous traffic conditioning. 🍓

Another option: if we know the non-DS-capable domain is made of legacy nodes, the upstream DS domain may opportunistically re-mark differentiated services traffic to one or more of the Class Selector Codepoints. 🌈

And if there's no knowledge of the downstream domain's traffic management capabilities and no agreement in place, a DS domain egress node may choose to re-mark DS codepoints to zero. The idea is that the non-DS-capable domain will treat the traffic uniformly with best-effort service. Simple, low-key, works 🤷‍♀️

Last thing for this section: when a non-DS-capable domain peers with a DS domain, traffic flowing from the non-DS-capable domain should be conditioned at the DS ingress node of the DS domain according to the appropriate SLA or policy. ✨

5. Multicast Considerations 🌈

Using differentiated services with multicast traffic brings up a bunch of issues for service provisioning, so buckle up 🎢

First, multicast packets that enter a DS domain at an ingress node may take multiple paths through some segments of the domain at the same time, because of multicast packet replication. That means they eat up more network resources than unicast packets do. 😳 And when multicast group membership is dynamic, it's really hard to predict in advance how many network resources multicast traffic from an upstream network will use for a particular group. Because of that uncertainty, it can be tough to give quantitative service guarantees to multicast senders. Also, it may be necessary to reserve codepoints and PHBs for exclusive use by unicast traffic, so unicast gets resource isolation from multicast. 💜

The second issue is picking the DS codepoint for a multicast packet that arrives at a DS ingress node. That packet might exit the DS domain at multiple DS egress nodes that peer with multiple downstream domains. So the DS codepoint used should not result in a request for service from a downstream DS domain that violates a peering SLA. 🙅‍♀️

When you're setting up classifier and traffic conditioner state at a DS ingress node for an aggregate of traffic getting a differentiated service that crosses the egress boundary of the domain, you can factor in the identity of the adjacent downstream transit domain and the specifics of the matching peering SLA into the configuration decision (subject to routing policy and the stability of the routing infrastructure). 🧠 This way, peering SLAs with downstream DS domains can be partly enforced at the ingress of the upstream domain, which takes some of the classification and traffic conditioning load off the upstream domain's egress node. Smart! 🎀

This isn't so easy for multicast traffic, though, because of the possibility of dynamic group membership. The result is that service guarantees for unicast traffic may be impacted. 😭

One way to deal with this is to set up a separate peering SLA for multicast traffic. You can either use a particular set of codepoints for multicast packets, or implement the necessary classification and traffic conditioning mechanisms in the DS egress nodes. Either way, you get preferential isolation for unicast traffic in conformance with the peering SLA with the downstream domain. 🫶

6. Security and Tunneling Considerations 🔐

Okay this section is serious, but make sure you're hydrated and let's go 💖

This section covers the security issues that come with introducing differentiated services. The big one is the potential for denial-of-service attacks, plus the related potential for theft of service by unauthorized traffic (Sec. 6.1). 🚨 It also talks about how differentiated services work when IPsec is present, and how they interact with IPsec (Sec. 6.2), along with auditing requirements (Sec. 6.3). And this section looks at issues raised by using both IPsec and non-IPsec tunnels. 🦋

6.1 Theft and Denial of Service 🦋

okay so the big goal of differentiated services is to let different levels of service be provided for traffic streams sharing one common network infrastructure 🌈 A bunch of resource management techniques MAY be used to achieve this, but the end result is that some packets get different (ideally better) service than others 💅 The mapping of network traffic to the behaviors that create that difference is mainly indicated by the DS field, so an adversary MAY be able to snag better service by changing the DS field to codepoints for enhanced services, or by injecting packets with the DS field set to those codepoints 😭 Taken to its extreme, this theft of service becomes a denial-of-service attack when the changed or injected traffic eats up the resources available to forward it and everyone else's traffic 💀 The defense against these theft- and denial-of-service attacks is the combo of traffic conditioning at DS boundary nodes plus security and integrity of the network infrastructure inside a DS domain 🫶

As we covered in Sec. 2, DS ingress nodes MUST condition all traffic entering a DS domain so that it has acceptable DS codepoints ✨ That means the codepoints MUST conform to the applicable TCA(s) and the domain's service provisioning policy. So ingress nodes are the primary line of defense against theft- and denial-of-service attacks based on modified DS codepoints (the ones the traffic isn't entitled to), because a successful attack like that is a violation of the applicable TCA(s) and/or service provisioning policy 👑 An important example of an ingress node: any traffic-originating node in a DS domain is the ingress node for that traffic, and it MUST ensure that all originated traffic carries acceptable DS codepoints 💖

Both a domain's service provisioning policy and TCAs MAY require the ingress nodes to change the DS codepoint on some entering packets (e.g., an ingress router MAY set the DS codepoint of a customer's traffic in accordance with the appropriate SLA 🎀). Ingress nodes MUST condition all other inbound traffic to make sure the DS codepoints are acceptable. Packets found with unacceptable codepoints MUST either be discarded or MUST have their DS codepoints modified to acceptable values before being forwarded. For example, an ingress node receiving traffic from a domain with no enhanced service agreement MAY reset the DS codepoint to the Default PHB codepoint [DSFIELD] 🍓 Traffic authentication MAY be required to validate the use of some DS codepoints (e.g., the ones for enhanced services), and that authentication MAY be performed by technical means (e.g., IPsec) and/or non-technical means (e.g., the inbound link is known to be connected to exactly one customer site) 🔐

An inter-domain agreement MAY reduce or eliminate the need for ingress node traffic conditioning by making the upstream domain partly or completely responsible for making sure traffic has DS codepoints acceptable to the downstream domain 🌸 In this case, the ingress node MAY still perform redundant traffic conditioning checks to lean less on the upstream domain (e.g., such checks can stop theft-of-service attacks from crossing the domain boundary 🙈). If such a check fails because the upstream domain isn't holding up its end, that failure is an auditable event. The generated audit log entry SHOULD include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that caused the failure. Realistically, the limited gains from these checks need to be weighed against their potential performance impact when deciding what, if any, checks to run under these circumstances ⭐

Interior nodes in a DS domain MAY rely on the DS field to associate differentiated services traffic with the behaviors used to implement enhanced services 🧚 Any node doing so depends on the correct operation of the DS domain to prevent the arrival of traffic with unacceptable DS codepoints. Robustness concerns dictate that the arrival of packets with unacceptable DS codepoints MUST NOT cause the failure (e.g., crash) of network nodes. Interior nodes are not responsible for enforcing the service provisioning policy (or individual SLAs), and hence are NOT REQUIRED to check DS codepoints before using them. Interior nodes MAY perform some traffic conditioning checks on DS codepoints (e.g., check for DS codepoints that are never used for traffic on a specific link) to improve security and robustness (e.g., resistance to theft-of-service attacks based on DS codepoint modifications) 💜 Any detected failure of such a check is an auditable event, and the generated audit log entry SHOULD include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that caused the failure. In practice, the limited gains from such checks need to be weighed against their potential performance impact when deciding what, if any, checks to perform at interior nodes 🌈

Any link that cannot be adequately secured against modification of DS codepoints or traffic injection by adversaries SHOULD be treated as a boundary link (and hence any arriving traffic on that link is treated as if it were entering the domain at an ingress node) 🔒 Local security policy provides the definition of "adequately secured," and such a definition MAY include a determination that the risks and consequences of DS codepoint modification and/or traffic injection do not justify any additional security measures for a link. Link security can be enhanced via physical access controls and/or software means, such as tunnels that ensure packet integrity 🎀

6.2. IPsec and Tunneling Interactions 🔐

okay so IPsec, as defined in [ESP, AH], does not include the IP header's DS field in any of its cryptographic calculations 🙈 (in tunnel mode, it's the outer IP header's DS field that gets left out). so when a network node changes the DS field, IPsec's end-to-end security doesn't notice at all, because it literally cannot make an integrity check fail 💅. that also means IPsec gives zero defense against an adversary changing the DS field (a man-in-the-middle attack), since the attacker's change has no effect on end-to-end security either 💀. in some environments, being able to edit the DS field without tripping IPsec integrity checks could be a covert channel 👀. if you need to kill that channel or shrink its bandwidth, the DS domains should be configured so the required processing (for example, setting all DS fields on sensitive traffic to a single value) happens at DS egress nodes, where traffic leaves higher security domains ✨.

IPsec's tunnel mode does provide security for the encapsulated IP header's DS field 🎀. a tunnel mode IPsec packet has two IP headers: an outer header from the tunnel ingress node, and an encapsulated inner header from the packet's original source 🧚. when an IPsec tunnel runs (fully or partly) over a differentiated services network, the intermediate nodes operate on the DS field in the outer header 🦋. at the tunnel egress node, IPsec processing includes stripping the outer header and forwarding the packet (if required) using the inner header. if the inner IP header hasn't already been processed by a DS ingress node for the tunnel egress node's DS domain, then the tunnel egress node is the DS ingress node for traffic exiting the tunnel, so it must carry out the matching traffic conditioning responsibilities (see Sec. 6.1) 😤. if the IPsec processing includes a sufficiently strong cryptographic integrity check of the encapsulated packet (with "sufficiently" decided by local security policy), the tunnel egress node can safely assume the inner header's DS field has the same value it had at the tunnel ingress node 🔥. that means a tunnel egress node in the same DS domain as the tunnel ingress node can safely treat a packet that passes the check as if it came from another node inside that DS domain, skipping the DS ingress traffic conditioning that would otherwise be required 🌸. the big takeaway: otherwise insecure links inside a DS domain can be secured by a sufficiently strong IPsec tunnel 🫶.

This analysis and its implications apply to any tunneling protocol that performs integrity checks, but how much you can trust the inner header's DS field depends on how strong that protocol's integrity check is 💜. without sufficient assurance for a tunnel that might transit nodes outside the current DS domain (or is otherwise vulnerable), the encapsulated packet must be treated as if it had arrived at a DS ingress node from outside the domain 🚧.

The IPsec protocol currently requires that the inner header's DS field not be changed by IPsec decapsulation processing at a tunnel egress node 🔒. this makes sure an adversary's DS field tampering can't be used to launch theft- or denial-of-service attacks across an IPsec tunnel endpoint, since any such changes get discarded right at the endpoint 🙌. this document makes no change to that IPsec requirement 💅.

If the IPsec specifications ever get modified to let a tunnel egress node change the DS field in an inner IP header based on the DS field value in the outer header (for example, copying part or all of the outer DS field into the inner DS field), then additional considerations would apply 👀. for a tunnel contained entirely within a single DS domain, where the links are adequately secured against modifications of the outer DS field, the only limits on inner DS field modifications would be those imposed by the domain's service provisioning policy ✨. otherwise, the tunnel egress node doing those modifications would be acting as a DS ingress node for traffic exiting the tunnel, and it must carry out the traffic conditioning responsibilities of an ingress node, including defense against theft- and denial-of-service attacks (See Sec. 6.1) 😭. if the tunnel enters the DS domain at a node different from the tunnel egress node, the tunnel egress node may depend on the upstream DS ingress node having ensured that the outer DS field values are acceptable 🧡. even then, some checks can only be performed by the tunnel egress node (for example, a consistency check between the inner and outer DS codepoints for an encrypted tunnel) 🔍. any detected failure of such a check is an auditable event, and the generated audit log entry should include the date/time the packet was received, the source and destination IP addresses, and the DS codepoint that was unacceptable 📝.

An IPsec tunnel can be viewed in at least two different ways from an architectural perspective 🌈. if the tunnel is viewed as a logical single hop "virtual wire", then the actions of intermediate nodes in forwarding the tunneled traffic should not be visible beyond the ends of the tunnel, so the DS field should not be modified as part of decapsulation processing 🫧. on the other hand, if the tunnel is viewed as a multi-hop participant in forwarding traffic, then modifying the DS field as part of tunnel decapsulation processing may be desirable 💖. a specific example of the latter happens when a tunnel terminates at an interior node of a DS domain where the domain administrator doesn't want to deploy traffic conditioning logic (for example, to simplify traffic management) 🍓. this could be supported by using the DS codepoint in the outer IP header (which was subject to traffic conditioning at the DS ingress node) to reset the DS codepoint in the inner IP header. that effectively moves DS ingress traffic conditioning responsibilities from the IPsec tunnel egress node to the appropriate upstream DS ingress node, which must already perform that function for unencapsulated traffic 👑.

6.3. Auditing 📋

not every system that supports differentiated services will implement auditing 🤷‍♀️. but if differentiated services support gets built into a system that does support auditing, then the differentiated services implementation should also support auditing too 🫶. if that support is there, the implementation must allow a system administrator to enable or disable auditing for differentiated services as a whole, and it may allow auditing to be turned on or off in part ⭐.

for the most part, how granular auditing is counts as a local matter 🎀. however, several auditable events are identified in this document, and for each one, a minimum set of information that should be included in an audit log is defined 💅. extra information (for example, packets related to the one that triggered the auditable event) may also go in the audit log for each of these events, and additional events not explicitly called out in this specification also may result in audit log entries 🧚. there's no requirement for the receiver to send any message back to the purported sender in response to detecting an auditable event, because doing that could invite a denial of service 🙈🔥.

7. Acknowledgements 💌

this document has benefitted from earlier drafts by Steven Blake, David Clark, Ed Ellesson, Paul Ferguson, Juha Heinanen, Van Jacobson, Kalevi Kilkki, Kathleen Nichols, Walter Weiss, John Wroclawski, and Lixia Zhang 🌸.

the authors would also like to shout out the following people for their helpful comments and suggestions: Kathleen Nichols, Brian Carpenter, Konstantinos Dovrolis, Shivkumar Kalyana, Wu-chang Feng, Marty Borden, Yoram Bernet, Ronald Bonica, James Binder, Borje Ohlman, Alessio Casati, Scott Brim, Curtis Villamizar, Hamid Ould-Brahi, Andrew Smith, John Renwick, Werner Almesberger, Alan O'Neill, James Fu, and Bob Braden 👑✨.

8. References 📚

  • [802.1p] ISO/IEC Final CD 15802-3 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 3: Media Access Control (MAC) bridges, (current draft available as IEEE P802.1D/D15).
  • [AH] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
  • [ATM] ATM Traffic Management Specification Version 4.0 <af-tm-0056.000>, ATM Forum, April 1996.
  • [Bernet] Y. Bernet, R. Yavatkar, P. Ford, F. Baker, L. Zhang, K. Nichols, and M. Speer, "A Framework for Use of RSVP with Diff-serv Networks", Work in Progress.
  • [DSFIELD] 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.
  • [EXPLICIT] D. Clark and W. Fang, "Explicit Allocation of Best Effort Packet Delivery Service", IEEE/ACM Trans. on Networking, vol. 6, no. 4, August 1998, pp. 362-373.
  • [ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
  • [FRELAY] ANSI T1S1, "DSSI Core Aspects of Frame Rely", March 1990.
  • [RFC791] Postel, J., Editor, "Internet Protocol", STD 5, RFC 791, September 1981.
  • [RFC1349] Almquist, P., "Type of Service in the Internet Protocol Suite", RFC 1349, July 1992.
  • [RFC1633] Braden, R., Clark, D. and S. Shenker, "Integrated Services in the Internet Architecture: An Overview", RFC 1633, July 1994.
  • [RFC1812] Baker, F., Editor, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
  • [RSVP] Braden, B., Zhang, L., Berson S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
  • [2BIT] K. Nichols, V. Jacobson, and L. Zhang, "A Two-bit Differentiated Services Architecture for the Internet", ftp://ftp.ee.lbl.gov/papers/dsarch.pdf, November 1997.
  • [TR] ISO/IEC 8802-5 Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Common specifications - Part 5: Token Ring Access Method and Physical Layer Specifications, (also ANSI/IEEE Std 802.5-1995), 1995.

Authors' Addresses 💅

Steven Blake 🦋

Steven Blake
Torrent Networking Technologies
3000 Aerial Center, Suite 140
Morrisville, NC  27560

Phone:  +1-919-468-8466 x232
EMail: slblake@torrentnet.com

David L. Black 🌸

David L. Black
EMC Corporation
35 Parkwood Drive
Hopkinton, MA  01748

Phone:  +1-508-435-1000 x76140
EMail: black_david@emc.com

Mark A. Carlson 🧚

Mark A. Carlson
Sun Microsystems, Inc.
2990 Center Green Court South
Boulder, CO  80301

Phone:  +1-303-448-0048 x115
EMail: mark.carlson@sun.com

Elwyn Davies ✨

Elwyn Davies
Nortel UK
London Road
Harlow, Essex  CM17 9NA, UK

Phone:  +44-1279-405498
EMail: elwynd@nortel.co.uk

Zheng Wang 💖

Zheng Wang
Bell Labs Lucent Technologies
101 Crawfords Corner Road
Holmdel, NJ  07733

EMail: zhwang@bell-labs.com

Walter Weiss 🌈

Walter Weiss
Lucent Technologies
300 Baker Avenue, Suite 100
Concord, MA  01742-2168

EMail: wweiss@lucent.com

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

Okay so the copyright bit is giving legal but it's actually pretty chill ngl 💅. You're totally allowed to copy this document and hand it to people, and you can make derivative works that comment on it, explain it, or help with implementing it, and you can publish and distribute those however you like, in whole or in part, no restrictions of any kind. The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🫶.

What you can't do is modify this document itself. You can't strip out the copyright notice or the references to the Internet Society or other Internet organizations, UNLESS you're using it to develop Internet standards, in which case the Internet Standards process copyright procedures have to be followed. You're also allowed to translate it into languages other than English 🌍.

The limited permissions above are perpetual, which means the Internet Society and its successors or assigns won't revoke them, ever 🦋.

Last but not least, the whole document and everything in it is provided "AS IS" 😭, 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. Periodt 👑.

📦 where this page comes from