RFC 4594
Configuration Guidelines for DiffServ Service Classes
RFC 4594: Configuration Guidelines for DiffServ Service Classes 🎀 (part 1 of 14)
Okay bestie, here's the who's who 💅
- Working group: Network Working Group
- Request for Comments: 4594
- Authors: J. Babiarz (Nortel Networks), K. Chan (Nortel Networks), F. Baker (Cisco Systems)
- Category: Informational
- Date: August 2006
- Obsoletes / updates: the title block doesn't list anything it obsoletes or updates 🌈
Status of This Memo 📜
This memo is info for the Internet community ✨. It does not specify an Internet standard of any kind, so it's not a rulebook you're forced to follow. Distribution of this memo is unlimited, so share it with everyone 💜.
Copyright Notice ⚖️
Copyright (C) The Internet Society (2006).
Abstract 🌸
So this doc is all about service classes configured with Diffserv 🦋. It explains how to use them and how to build them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. Nothing says you have to use particular DSCPs, traffic conditioners, PHBs, or AQM for a given service class. Still, as a policy and for interoperability, it's really useful to apply them consistently, periodt 💅.
Table of Contents 🗂️
1. Introduction ....................................................3
1.1. Requirements Notation ......................................4
1.2. Expected Use in the Network ................................4
1.3. Service Class Definition ...................................5
1.4. Key Differentiated Services Concepts .......................5
1.4.1. Queuing .............................................6
1.4.1.1. Priority Queuing ...........................6
1.4.1.2. Rate Queuing ...............................6
1.4.2. Active Queue Management .............................7
1.4.3. Traffic Conditioning ................................7
1.4.4. Differentiated Services Code Point (DSCP) ...........8
1.4.5. Per-Hop Behavior (PHB) ..............................8
1.5. Key Service Concepts .......................................8
1.5.1. Default Forwarding (DF) .............................9
1.5.2. Assured Forwarding (AF) .............................9
1.5.3. Expedited Forwarding (EF) ..........................10
1.5.4. Class Selector (CS) ................................10
1.5.5. Admission Control ..................................11
2. Service Differentiation ........................................11
2.1. Service Classes ...........................................12
2.2. Categorization of User Service Classes ....................13
2.3. Service Class Characteristics .............................16
2.4. Deployment Scenarios ......................................21
2.4.1. Example 1 ..........................................21
2.4.2. Example 2 ..........................................23
2.4.3. Example 3 ..........................................25
3. Network Control Traffic ........................................27
3.1. Current Practice in the Internet ..........................27
3.2. Network Control Service Class .............................27
3.3. OAM Service Class .........................................29
4. User Traffic ...................................................30
4.1. Telephony Service Class ...................................31
4.2. Signaling Service Class ...................................33
4.3. Multimedia Conferencing Service Class .....................35
4.4. Real-Time Interactive Service Class .......................37
4.5. Multimedia Streaming Service Class ........................39
4.6. Broadcast Video Service Class .............................41
4.7. Low-Latency Data Service Class ............................43
4.8. High-Throughput Data Service Class ........................45
4.9. Standard Service Class ....................................47
4.10. Low-Priority Data ........................................48
5. Additional Information on Service Class Usage ..................49
5.1. Mapping for Signaling .....................................49
5.2. Mapping for NTP ...........................................50
5.3. VPN Service Mapping .......................................50
6. Security Considerations ........................................51
7. Acknowledgements ...............................................52
8. Appendix A .....................................................53
8.1. Explanation of Ring Clipping ..............................53
9. References .....................................................54
9.1. Normative References ......................................54
9.2. Informative References ....................................551. Introduction ✨
Let's talk analogies 🔨. The Differentiated Services specs are basically a toolkit. They give you the equivalent of band saws, planers, drill presses, and other power tools. An expert can build literally anything with them, but that same toolkit can feel super intimidating if you're a non-expert who just wants to build a bookcase 🙈.
So this document is more like a set of "project plans" for building all the (diffserv) furniture you might want 🪑. You get to choose what to build (maybe your non-expert doesn't need a china cabinet yet 🍓), and how to build it. Plans for a non-expert probably won't use mortise/tenon construction, but that doesn't mean mortise/tenon is forbidden or unsound. The authors hope these diffserv "project plans" give Network Administrators a useful guide for using diffserv techniques to set up quality-of-service measures that fit their network's traffic 🫶.
This document describes service classes configured with Diffserv and recommends how they can be used and how to construct them using Differentiated Services Code Points (DSCPs), traffic conditioners, Per-Hop Behaviors (PHBs), and Active Queue Management (AQM) mechanisms. There's no intrinsic requirement that particular DSCPs, traffic conditioners, PHBs, and AQM be used for a certain service class. But as a policy and for interoperability, it's useful to apply them consistently 💖.
Service class definitions are based on the different traffic characteristics and required performance of applications and services. This lets us map current and future applications/services with similar traffic characteristics and performance needs into the same service class 🧚. Since those characteristics and performance requirements are end to end, the service class notion needs to be preserved end to end too. With this approach, you only need a limited set of service classes. For completeness, the document defines twelve service classes: two for network operation/administration and ten for user/subscriber applications/services. Network Administrators will probably implement only the subset that's relevant to their customers and service offerings. They may also find it valuable to add locally defined service classes, though those won't necessarily have the same end-to-end properties 👑.
Section 1 gives an introduction and overview of the technologies used for service differentiation in IP networks. Section 2 is an overview of how service classes are constructed to provide service differentiation, with examples of deployment scenarios. Section 3 gives configuration guidelines for service classes used for stable operation and administration of the network. Section 4 gives configuration guidelines for service classes used to differentiate user/subscriber traffic. Section 5 gives additional guidance on mapping different applications/protocols to service classes. Section 6 covers security considerations 🔐.
1.1. Requirements Notation
The key words "SHOULD", "SHOULD NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 📏
1.2. Expected Use in the Network
Real talk: corporate LANs and ISP WANs are generally not heavily utilized 😴. They're commonly 10% utilized at most. Because of that, congestion, loss, and variation in delay within corporate LANs and ISP backbones are basically unheard of. That clashes with what users actually feel, and there are three very good reasons for it 👀.
- The industry moves through cycles of bandwidth boom and bandwidth bust, depending on market conditions and the periodic rollout of new bandwidth-hungry applications 📈.
- Access networks are often different. That might be because throughput rates are artificially limited or over-subscribed, or because of access network design trade-offs 🚧.
- Other stuff, like database design on web servers (which can create contention points, e.g., in filestore) and how firewalls and routers are configured, often looks externally like a bandwidth limitation 🙃.
The whole point of this document is to give a consistent marking, conditioning, and packet treatment strategy 💅. That way it can be configured and put into service on any link that's itself congested, which is honestly so iconic 🌟.
1.3. Service Class Definition ✨
okay so a "service class" is basically a group of traffic that needs certain delay, loss, and jitter stuff from the network 🎀 Like, apps with similar vibes and similar needs get grouped together. You've got a "High-Throughput Data" class for stuff like the web and email, and a "Telephony" class for real-time traffic like voice calls 📞 A service class can be defined locally inside one Differentiated Services (DS) domain, or it can stretch across multiple DS domains, maybe even all the way end to end 🦋
A service class is really just a statement of what a traffic aggregate needs, lowkey a whole vibe check for the traffic 💅 Those needs can be met using a defined per-hop behavior (PHB) [RFC2474]. The actual description of how a traffic aggregate should be treated inside a domain can also be written down as a per-domain behavior (PDB) [RFC3086] 🌸
Each domain can pick different service classes, or use different behaviors to build them, or group different kinds of traffic into the aggregates, and still hit the characteristics they need 🧚 For example, low delay, loss, and jitter can come from the EF PHB, or from an over-provisioned AF PHB. This must be done with care, bestie, because it may mess with the end-to-end performance that the applications and services need 😭 This document gives recommendations on using PHBs for specific service classes so they get implemented consistently 🫶 These recommendations are NOT to be read as banning other PHBs that create behaviors good enough for the same class of traffic. (Okay, the original says "not to be construed as prohibiting," so no caps here: they are not to be construed as prohibiting other PHBs that realize behaviors sufficient for the relevant class of traffic. Totally fine to use those too 💖)
The Default Forwarding "Standard" service class is REQUIRED, and all the other service classes are OPTIONAL ✨ Network admins are expected to pick how much service differentiation they'll support based on what they actually need, starting with three or four service classes for user traffic and adding more as the need pops up 🍓
1.4. Key Differentiated Services Concepts 🌈
The reader SHOULD be familiar with the principles of the Differentiated Services Architecture [RFC2474] 🎀 We're only recapping the key concepts here as a little bonus for you, bestie. The referenced RFCs are the authoritative definitions, so go to them for the real deal 📚
1.4.1. Queuing 🚦
A queue is a data structure that holds packets waiting to be transmitted 🫧 Packets can get delayed while they sit in the queue, maybe because there isn't enough bandwidth, or because they're low priority. There are lots of ways to build a queue, but a simple model is a set of data structures holding packet data (we'll call those queues), plus a mechanism for picking the next packet out of them (we'll call that a scheduler) 💅
1.4.1.1. Priority Queuing 👑
A priority queuing system is a set of queues plus a scheduler that empties them in priority order 🔥 When asked for a packet, the scheduler checks the highest priority queue, and if there's data in it, it hands back a packet from there. If not, it checks the next highest priority queue, and so on 🏎️ A freeway onramp with a stoplight that lets the high-occupancy-vehicle lane zoom past is a good example of this. That HOV lane is the "queue" with priority ✨
In a priority queuing system, a packet in the highest priority queue gets a delay you can calculate pretty easily 🧮 That delay is based on how much data was still being serialized when the packet arrived, plus all the data already queued ahead of it in the same queue. The whole reason we use a priority queue comes down to this: it limits delay and variation in delay, so it should be used for traffic that needs that 🥹💖
A priority queue or queuing system needs to avoid starving the lower-priority queues 😭 That can be done in a bunch of ways, like admission control, rate control, or good network engineering 🛠️
1.4.1.2. Rate Queuing 🎢
A rate-based queuing system is also a set of queues plus a scheduler, but this one empties each queue at a specified rate 🚗 Think of a road intersection with a stoplight. The stoplight is the scheduler, giving each lane its own chance to send traffic through the intersection 🚦
In a rate-based queuing system, like Weighted Fair Queuing (WFQ) or Weighted Round Robin (WRR), the delay a packet sees in any queue depends on that queue's parameters and occupancy, plus the parameters and occupancy of the queues it's competing with 🫠 A queue whose traffic arrives much slower than it can leave will usually be empty, so its packets see nominal delays 🌿 A queue whose arrival rate is about the same as, or higher than, its departure rate usually won't be empty, and its packets will see more delay 🙈 A scheduler like this can impose a minimum rate, a maximum rate, or both, on any queue it touches 💅
1.4.2. Active Queue Management 🧹
Active Queue Management, or AQM, is a catch-all name for a bunch of procedures that use packet dropping or marking to manage how deep a queue gets 🌊 The classic example is Random Early Detection (RED). A queue gets a minimum and a maximum threshold, and the algorithm keeps a moving average of the queue depth. While the mean queue depth is above the maximum threshold, all arriving traffic gets dropped 💀 While it's above the minimum threshold but not the maximum, a randomly chosen subset of arriving traffic gets marked or dropped 🎲 The point is to tell the sending system to back off, so its congestion avoidance algorithms kick in 🫶 Because of this, it's reasonable to expect that TCP's cyclic behavior gets desynchronized, and that the mean queue depth (and therefore the delay) should normally sit close to the minimum threshold 🧘
Assured Forwarding PHB [RFC2597] does a twist on this. Its behavior aggregate has traffic with multiple DSCP marks all mixed together in one common queue 🍹 Different minimums and maximums get set for each DSCP separately, so traffic going over a stated rate at ingress is more likely to be dropped or marked than traffic within its contracted rate 🎀
1.4.3. Traffic Conditioning 🎛️
Here's another thing: at the first router a packet crosses in a network, arriving traffic may be measured and then dropped or marked according to a policy, or maybe shaped on the way in, like in "A Rate Adaptive Shaper for Differentiated Services" [RFC2963] 🧁 This can be used to bias feedback loops, like in "Assured Forwarding PHB" [RFC2597], or to limit how much traffic is in a system, like in "Expedited Forwarding PHB" [RFC3246] 💫 All of these measurement procedures get collectively called "traffic conditioners" 🫧 Traffic conditioners are usually built from token bucket meters, for example with a committed rate and burst size, as in Section 1.5.3 of the DiffServ Model [RFC3290] 🪣 The Assured Forwarding PHB [RFC2597] uses a twist on a meter that measures multiple rates and burst sizes, so it can test and identify multiple levels of conformance 🔍
Multiple rates and burst sizes can be done with multiple levels of token buckets or with more complex token buckets, and those are implementation details 🛠️ Here are some traffic conditioners you might use when deploying differentiated services 📋
- For Class Selector (CS) PHBs, a single token bucket meter gives you rate plus burst size control 🪣
- For Expedited Forwarding (EF) PHB, a single token bucket meter gives you rate plus burst size control 🪣
- For Assured Forwarding (AF) PHBs, you usually need two token bucket meters, set up to behave the way "Two Rate Three Color Marker (trTCM)" [RFC2698] or "Single Rate Three Color Marker (srTCM)" [RFC2697] describe 🌈 The two-rate, three-color marker enforces two rates, while the single-rate, three-color marker enforces a committed rate with two burst lengths 🎨
1.4.4. Differentiated Services Code Point (DSCP) 🏷️
The DSCP is a number from 0 to 63 (that's the range 0..63) that gets put into an IP packet to mark it with the class of traffic it belongs to 💅 Half of these values are set aside for standardized services, and the other half are available for local definition 🧚
1.4.5. Per-Hop Behavior (PHB) 🌟
In the end, all the mechanisms above get combined to form a specified set of characteristics for handling different kinds of traffic, depending on what the application needs 🫶 This document is all about finding useful traffic aggregates and specifying which PHB should be applied to each one 💖
1.5. Key Service Concepts 👑
Differentiated Services is a general architecture that can be used to build a whole bunch of services, but three fundamental forwarding behaviors have been defined and described for general use ✨ The first is basic Default Forwarding (DF) behavior for elastic traffic. The second is the Assured Forwarding (AF) behavior, and the third is the Expedited Forwarding (EF) behavior for real-time (inelastic) traffic 🎀 The facts that four code points are recommended for AF and one code point is recommended for EF are arbitrary choices, and the architecture allows any reasonable number of AF and EF classes at the same time 🌈 The choice of four AF classes and one EF class in this document is arbitrary too, and operators MAY choose to run more or fewer of either 🍓
The terms "elastic" and "real-time" are defined in [RFC1633], Section 3.1, as a way to understand broad-brush application requirements 🧠 This document should be reviewed to get a broad understanding of the issues in quality of service, just like [RFC2475] should be reviewed to understand the data plane architecture used in today's Internet 🌐
1.5.1. Default Forwarding (DF) 🫧
The basic forwarding behaviors applied to any class of traffic are the ones described in [RFC2474] and [RFC2309] 📜 Best-effort service can be summed up as "I will accept your packets," and it's typically configured with some bandwidth guarantee 🤷♀️ Packets in transit may be lost, reordered, duplicated, or delayed at random 😭 Networks are generally engineered to limit this, but changing traffic loads can push any network into that state anyway 🌪️
Application traffic on the internet that uses default forwarding is expected to be "elastic" in nature 🦋 What that means is the sender will adjust its transmission rate in response to changes in available rate, loss, or delay. Elastic traffic really knows how to read the room 💅
For the basic best-effort service, a single DSCP value identifies the traffic, a queue stores it, and active queue management protects the network from it and limits delays 🛡️✨
1.5.2. Assured Forwarding (AF) 🎀
okay so the Assured Forwarding PHB [RFC2597] is literally modeled on Frame Relay's Discard Eligible (DE) flag or ATM's Cell Loss Priority (CLP) capability 💅. it's meant for networks that offer average-rate Service Level Agreements (SLAs) (as FR and ATM networks do) ✨. this is an enhanced best-effort service, so the traffic is expected to be "elastic" in nature 🦋. the receiver notices loss or variation in delay in the network and sends feedback, so the sender can adjust its transmission rate and get close to the available capacity. it's giving self-correcting 🫶
for this kind of behavior, there are multiple DSCP values (two or three, perhaps more using local values) to identify the traffic 🏷️. there's also a common queue to store the aggregate, and active queue management to protect the network from it and to limit delays 🧹. traffic gets metered as it enters the network, and it gets marked in different ways depending on the arrival rate of the aggregate 📏. the premise is that it's normal for users to occasionally use more capacity than their contract stipulates, perhaps up to some bound 🤷♀️. however, if traffic should be marked or lost to manage the queue, this excess traffic will be marked or lost first 💀
1.5.3. Expedited Forwarding (EF) 🚀
the intent of the Expedited Forwarding PHB [RFC3246] is to be a building block for low-loss, low-delay, and low-jitter services 😭. it can be used to build an enhanced best-effort service, but traffic still remains subject to loss due to line errors and reordering during routing changes 🙈. using queuing techniques, though, the probability of delay or variation in delay is minimized ✨. that's why it's generally used to carry voice and to transport data that needs "wire like" behavior through the IP network 📞. voice is an inelastic "real-time" application that sends packets at the rate the codec produces them, regardless of whether capacity is available 🎧. so this service has the potential to disrupt or congest a network if it isn't controlled, and it also has the potential for abuse 🚨
to protect the network, at minimum one SHOULD police traffic at various points to make sure the design of a queue doesn't get overrun 🛡️. then the traffic SHOULD be given a low-delay queue (often using priority, although it is asserted that a rate-based queue can do this) so that variation in delay isn't an issue and application needs get met 🫶
1.5.4. Class Selector (CS) 🧚
Class Selector is all about supporting historical codepoint definitions and PHB requirements 📜. the Class Selector DS field gives a limited backward compatibility with legacy (pre DiffServ) practice, as described in [RFC2474], Section 4 🕰️. backward compatibility is handled in two ways. first, there are per-hop behaviors that are already in widespread use (for example, those satisfying the IPv4 Precedence queuing requirements specified in [RFC1812]), and we want to keep letting them be used in DS-compliant networks 🙌. second, some codepoints correspond to historical use of the IP Precedence field, and we reserve those codepoints to map to PHBs that meet the general requirements specified in [RFC2474], Section 4.2.2.2 🎀
no attempt is made to keep backward compatibility with the "DTR" or Type of Service (TOS) bits of the IPv4 TOS octet, as defined in [RFC0791] and [RFC1349] 🙅♀️
a DS-compliant network can be deployed with a set of one or more Class Selector-compliant PHB groups 🌸. also, a network administrator may configure the network nodes to map codepoints to PHBs, ignoring bits 3-5 of the DSCP field, to get a network that's compatible with historical IP Precedence use 🍓. so for example, codepoint '011000' would map to the same PHB as codepoint '011010' 💅
1.5.5. Admission Control 🚪
admission control (including refusal when policy thresholds are crossed) can keep communication high-quality by making sure there's enough bandwidth to carry a load 👑. inelastic real-time flows like Voice over Internet Protocol (VoIP) (telephony) or video conferencing can really benefit from an admission control mechanism, because the telephony service is usually configured with over-subscription, which means some users may not be able to make a call during peak periods 📵
for VoIP (telephony) service, a common approach is to use signaling protocols such as SIP, H.323, H.248, MEGACO, and Resource Reservation Protocol (RSVP) to negotiate admittance and use of network transport capabilities 🤝. once a user has been authorized to send voice traffic, that admission procedure has checked that the data rates will be within the capacity of the network that it'll use ✅. a lot of RTP voice payloads are inelastic and can't react to loss or delay in any real way 😩. for these voice payloads, the network SHOULD police at ingress to make sure the voice traffic stays within its negotiated bounds 🔒. once the input rate is predictable, the network may use a priority queue to keep delay and variation in delay nominal 🌈
another approach that may be used in small, bandwidth-constrained networks with a limited number of flows is RSVP [RFC2205] [RFC2996] 🧵. but there's concern about how well this scales in large networks, where aggregation of reservations [RFC3175] is considered to be required 😬
2. Service Differentiation ✨
there are practical limits on the level of service differentiation that should be offered in IP networks 🧐. we think we've defined a practical approach by creating different service classes that networks can choose to support, so they can provide the right level of behavior and performance for current and future applications and services 💖. the structure lets several applications with similar traffic characteristics and performance requirements be grouped into the same service class 🫧. this gives a lot of flexibility in providing the right amount of service differentiation for current and new (yet unknown!) applications, without needing big changes to routers or network configurations every time a new traffic type gets added to the network 🦋
2.1. Service Classes 💅
traffic flowing in a network can be classified in lots of different ways 🌷. we've chosen to split it into two groupings: network control and user/subscriber traffic. to provide service differentiation, different service classes are defined in each grouping 🎀. the network control traffic group can be split further into two service classes (see Section 3 for the detailed definition of each service class):
- "Network Control" is for routing and network control functions 🛣️.
- "OAM" (Operations, Administration, and Management) is for network configuration and management functions ⚙️.
the user/subscriber traffic group is broken down into ten service classes, so every type of application and service gets its own level of differentiation (see Section 4 for the detailed definition of each service class) 👑:
- Telephony service class is best suited for applications that need very low delay variation and are of constant rate, such as IP telephony (VoIP) and circuit emulation over IP applications 📞.
- Signaling service class is best suited for peer-to-peer and client-server signaling and control functions using protocols such as SIP, SIP-T, H.323, H.248, and Media Gateway Control Protocol (MGCP) 🛎️.
- Multimedia Conferencing service class is best suited for applications that need very low delay and can change their encoding rate (rate adaptive), such as H.323/V2 and later video conferencing services 🎥.
- Real-Time Interactive service class is for interactive, variable-rate, inelastic applications that need low jitter and loss and very low delay, such as interactive gaming apps that use RTP/UDP streams for game control commands, and video conferencing apps that can't change encoding rates or mark packets with different importance indications 🎮.
- Multimedia Streaming service class is best suited for variable-rate, elastic streaming media applications where a human is waiting for output and the application can react to packet loss by lowering its transmission rate, such as streaming video and audio and webcasts 📺.
- Broadcast Video service class is best suited for inelastic streaming media applications that may be constant or variable rate and need low jitter and very low packet loss, such as broadcast TV, live events, video surveillance, and security 📡.
- Low-Latency Data service class is best suited for data processing applications where a human is waiting for output, such as web-based ordering or an Enterprise Resource Planning (ERP) application 🛒.
- High-Throughput Data service class is best suited for store and forward applications such as FTP and billing record transfer 📦.
- Standard service class is for traffic that hasn't been identified as needing differentiated treatment, and it's normally referred to as best effort 🫶.
- Low-Priority Data service class is for packet flows where bandwidth assurance isn't required 🐢.
2.2. Categorization of User Service Classes 🎀
Okay so the ten user/subscriber service classes from above can be sorted into a small number of application categories 💅. Some categories got more than one class, because the apps have different traffic characteristics, control functions, and required flow behavior, so they need their own differentiation inside the category 🦋. Figure 1 is basically the cheat sheet for all four categories 📋.
Application Control Category 🎛️
- Signaling is for controlling applications or user endpoints. Protocols like
SIPorH.248for IP telephone service, andSIPor Internet Group Management Protocol (IGMP) for controlling broadcast TV service to subscribers, would use this class. Signaling flows have similar performance needs to Low-Latency Data, but they still need to be told apart and marked with a different DSCP 🫶. The real difference is "administrative control and management" of the traffic, since these protocols are tied to the media stream or session they signal and control 💜.
Media-Oriented Category 🎬
Because there are SO many new (still being deployed) and already-in-use media services on IP networks, five service classes have been defined 🌈.
- Telephony is for IP telephony (VoIP) service 📞. It can also be used for other applications that meet its traffic characteristics and performance requirements.
- Real-Time Interactive is for inelastic video flows, like SIP-based desktop video conferencing and interactive gaming 🎮.
- Multimedia Conferencing is for video conferencing that can lower its transmission rate when it detects congestion, so these flows count as rate adaptive 🦋. Since there are two kinds of video conferencing equipment on IP networks (ones that make inelastic traffic and ones that make rate-adaptive traffic), two classes are needed. Real-Time Interactive should be used for equipment that generates inelastic video flows, and Multimedia Conferencing for equipment that generates rate-adaptive video flows ✨.
- Broadcast Video is for inelastic traffic flows meant for broadcast TV and for carrying live video and audio events 📺.
- Multimedia Streaming is for elastic multimedia flows 🍿. This content is usually stored before it gets sent, and it's buffered at the receiving end before it plays. The buffer is big enough to handle any variation in transmission rate the network throws at it. Multimedia entertainment delivery services that are being developed can generate both elastic and inelastic flows, so two classes cover that space: Multimedia Streaming and Broadcast Video 👑.
Data Category 💾
The data category is split into three service classes 🧚.
- Low-Latency Data is for applications and services that need low delay or latency for bursty but short-lived flows ⚡.
- High-Throughput Data is for applications and services that need good throughput for long-lived bursty flows 🌊. High-Throughput and Multimedia Streaming have pretty similar traffic flow characteristics, except High-Throughput is a bit more bursty and not as long-lived as Multimedia Streaming 🙈.
- Low-Priority Data is for applications or services that can handle short or long interruptions in packet flows 🍓. It's kind of a "don't care" class, to some degree 🤷♀️.
Best-Effort Category 🌍
- All traffic that isn't differentiated in the network lands here and gets mapped into the Standard service class 🫧. If a packet is marked with a DSCP value that the network doesn't support, it SHOULD be forwarded using the Standard service class.
Figure 1 below groups the user/subscriber service classes into those four categories. It also shows which classes use an independent flow for signaling or control, the type of flow behavior (elastic, rate adaptive, or inelastic), and, in the last column, the end user Quality of Service (QoS) rating from ITU-T Recommendation G.1010 📊.
-----------------------------------------------------------------
| Application | Service | Signaled | Flow | G.1010 |
| Categories | Class | | Behavior | Rating |
|-------------+---------------+----------+-----------+------------|
| Application | Signaling | Not | Inelastic | Responsive |
| Control | |applicable| | |
|-------------+---------------+----------+-----------+------------|
| | Telephony | Yes | Inelastic | Interactive|
| |---------------+----------+-----------+------------|
| | Real-Time | Yes | Inelastic | Interactive|
| | Interactive | | | |
| |---------------+----------+-----------+------------|
| Media- | Multimedia | Yes | Rate | Interactive|
| Oriented | Conferencing | | Adaptive | |
| |---------------+----------+-----------+------------|
| |Broadcast Video| Yes | Inelastic | Responsive |
| |---------------+----------+-----------+------------|
| | Multimedia | Yes | Elastic | Timely |
| | Streaming | | | |
|-------------+---------------+----------+-----------+------------|
| | Low-Latency | No | Elastic | Responsive |
| | Data | | | |
| |---------------+----------+-----------+------------|
| Data |High-Throughput| No | Elastic | Timely |
| | Data | | | |
| |---------------+----------+-----------+------------|
| | Low-Priority | No | Elastic |Non-critical|
| | Data | | | |
|-------------+---------------+----------+-----------+------------|
| Best Effort | Standard | Not Specified |Non-critical|
-----------------------------------------------------------------Figure 1. User/Subscriber Service Classes Grouping 🌸
Quick QoS vibe check from ITU-T G.1010 🔍. User traffic gets sorted into four categories: interactive, responsive, timely, and non-critical 💅.
- Interactive traffic is between two humans, and it's the most sensitive to delay, loss, and jitter 🙋♀️. It's also used between two servers that need very low delay and loss 🖥️.
- Responsive traffic is usually between a human and a server, but it can also be between two servers 🫶. It handles jitter better and can tolerate longer delays than interactive traffic 🌷.
- Timely traffic is between servers, or between servers and humans, and its delay tolerance is a lot longer than responsive traffic ⏳.
- Non-critical traffic is normally between servers or machines, where delivery can be delayed for a while 🤖.
2.3. Service Class Characteristics 🌟
Okay, this part is for network administrators who want to set up their network with the right level of service differentiation to meet their QoS needs 💖. Network operators are expected to configure and provide a subset of the defined service classes in their networks 🧁. Our goal is to give guidelines for setting up Differentiated Services for a wide variety of applications, services, and network configurations ✨. On top of that, network administrators can define and deploy other service classes in their network if they want 🦄.
Figure 2 gives a behavior view of the traffic each service class handles 🎀. The traffic characteristics column defines the characteristics and profile of the flows, and the tolerance to loss, delay, and jitter columns define how those flows get treated 🔥. If you want end-to-end quantitative performance requirements, check ITU-T Recommendations Y.1541 and Y.1540 📚.
Okay bestie, the big cheat sheet is next 🧚 Figure 2 shows how each service class behaves: what its traffic looks like and how well it copes with loss, delay and jitter 💅
-------------------------------------------------------------------
|Service Class | | Tolerance to |
| Name | Traffic Characteristics | Loss |Delay |Jitter|
|===============+==============================+======+======+======|
| Network |Variable size packets, mostly | | | |
| Control |inelastic short messages, but | Low | Low | Yes |
| | traffic can also burst (BGP) | | | |
|---------------+------------------------------+------+------+------|
| | Fixed-size small packets, | Very | Very | Very |
| Telephony | constant emission rate, | Low | Low | Low |
| | inelastic and low-rate flows | | | |
|---------------+------------------------------+------+------+------|
| Signaling | Variable size packets, some | Low | Low | Yes |
| | what bursty short-lived flows| | | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, | Low | Very | |
| Conferencing | constant transmit interval, | - | Low | Low |
| |rate adaptive, reacts to loss |Medium| | |
|---------------+------------------------------+------+------+------|
| Real-Time | RTP/UDP streams, inelastic, | Low | Very | Low |
| Interactive | mostly variable rate | | Low | |
|---------------+------------------------------+------+------+------|
| Multimedia | Variable size packets, |Low - |Medium| Yes |
| Streaming | elastic with variable rate |Medium| | |
|---------------+------------------------------+------+------+------|
| Broadcast | Constant and variable rate, | Very |Medium| Low |
| Video | inelastic, non-bursty flows | Low | | |
|---------------+------------------------------+------+------+------|
| Low-Latency | Variable rate, bursty short- | Low |Low - | Yes |
| Data | lived elastic flows | |Medium| |
|---------------+------------------------------+------+------+------|
| OAM | Variable size packets, | Low |Medium| Yes |
| | elastic & inelastic flows | | | |
|---------------+------------------------------+------+------+------|
|High-Throughput| Variable rate, bursty long- | Low |Medium| Yes |
| Data | lived elastic flows | |- High| |
|---------------+------------------------------+------+------+------|
| Standard | A bit of everything | Not Specified |
|---------------+------------------------------+------+------+------|
| Low-Priority | Non-real-time and elastic | High | High | Yes |
| Data | | | | |
-------------------------------------------------------------------Figure 2. Service Class Characteristics
Notes for Figure 2: A "Yes" in the jitter-tolerant column implies that data is buffered in the endpoint, and that a moderate level of network-induced variation in delay will not affect the application ✨ Applications that use TCP as a transport are generally good examples 🌸 Routing protocols and peer-to-peer signaling also fall in this class 🫶 Loss can create problems in setting up calls, but a moderate level of jitter just makes call placement a little less predictable in duration 🙈
Service classes indicate the required traffic forwarding treatment in order to meet user, application, or network expectations 💖 Section 3 defines the service classes that MAY be used for forwarding network control traffic, and Section 4 defines the service classes that MAY be used for forwarding user traffic, with examples of intended application types mapped into each service class 🦋 The application types are only examples and are not meant to be all-inclusive or prescriptive, so don't treat them as the whole story 💅 Also, the service class naming or ordering does not imply any priority ordering, bestie 🙅♀️ They are simply reference names used in this document, with associated QoS behaviors that are optimized for the particular application types they support 🎀 Network administrators MAY choose to assign different service class names to the service classes that they will support 👑
Figure 3 defines the RECOMMENDED relationship between service classes and DS codepoint assignment, with application examples 🌈 It is RECOMMENDED that this relationship be preserved end to end ⭐
------------------------------------------------------------------
| Service | DSCP | DSCP | Application |
| Class Name | Name | Value | Examples |
|===============+=========+=============+==========================|
|Network Control| CS6 | 110000 | Network routing |
|---------------+---------+-------------+--------------------------|
| Telephony | EF | 101110 | IP Telephony bearer |
|---------------+---------+-------------+--------------------------|
| Signaling | CS5 | 101000 | IP Telephony signaling |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF41,AF42|100010,100100| H.323/V2 video |
| Conferencing | AF43 | 100110 | conferencing (adaptive) |
|---------------+---------+-------------+--------------------------|
| Real-Time | CS4 | 100000 | Video conferencing and |
| Interactive | | | Interactive gaming |
|---------------+---------+-------------+--------------------------|
| Multimedia |AF31,AF32|011010,011100| Streaming video and |
| Streaming | AF33 | 011110 | audio on demand |
|---------------+---------+-------------+--------------------------|
|Broadcast Video| CS3 | 011000 |Broadcast TV & live events|
|---------------+---------+-------------+--------------------------|
| Low-Latency |AF21,AF22|010010,010100|Client/server transactions|
| Data | AF23 | 010110 | Web-based ordering |
|---------------+---------+-------------+--------------------------|
| OAM | CS2 | 010000 | OAM&P |
|---------------+---------+-------------+--------------------------|
|High-Throughput|AF11,AF12|001010,001100| Store and forward |
| Data | AF13 | 001110 | applications |
|---------------+---------+-------------+--------------------------|
| Standard | DF (CS0)| 000000 | Undifferentiated |
| | | | applications |
|---------------+---------+-------------+--------------------------|
| Low-Priority | CS1 | 001000 | Any flow that has no BW |
| Data | | | assurance |
------------------------------------------------------------------Figure 3. DSCP to Service Class Mapping
Notes for Figure 3: Default Forwarding (DF) and Class Selector 0 (CS0) provide equivalent behavior and use the same DS codepoint, '000000' 🍓
It is expected that network administrators will base their choice of the service classes they support on their need, starting off with three or four service classes for user traffic and adding others as the need arises 🧁
Figure 4 provides a summary of DiffServ QoS mechanisms that SHOULD be used for the defined service classes, which are further detailed in Sections 3 and 4 of this document 💜 Depending on what applications and services need to be differentiated, network administrators can choose the service class(es) that need to be supported in their network 🌷
------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | Queuing| AQM|
| Class | | DS Edge | Used | | |
|===============+======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 |three-color marker | RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Real-Time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+------+-------------------+---------|--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 |three-color marker | RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | | Yes|
| Throughput | AF12 |three-color marker | RFC2597 | Rate | per|
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+------+-------------------+---------+--------+----|
| Standard | DF | Not applicable | RFC2474 | Rate | Yes|
|---------------+------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
------------------------------------------------------------------Figure 4. Summary of QoS Mechanisms Used for Each Service Class
Notes for Figure 4:
- Conditioning at DS edge means traffic conditioning happens at the edge of the DiffServ network, where untrusted user devices plug in, or between two DiffServ networks. 🎀
sr+bsis a policing mechanism that gives you single rate with burst size control. 💅- The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. 🦋
- The PHB for Real-Time Interactive service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as a second EF PHB that uses relaxed performance parameters and a rate scheduler. 🔥
- The PHB for Broadcast Video service class SHOULD be configured to provide high bandwidth assurance. It MAY be configured as a third EF PHB that uses relaxed performance parameters and a rate scheduler. 📺
- In network segments that use IP precedence marking, only one of the two service classes can be supported, High-Throughput Data or Low-Priority Data. We RECOMMEND that the DSCP value(s) of the unsupported service class be changed to
000xx1on ingress and changed back to the original value(s) on egress of the network segment that uses precedence marking. For example, if Low-Priority Data is mapped to Standard service class, then000001DSCP marking MAY be used to distinguish it from Standard marked packets on egress. 🌸
2.4. Deployment Scenarios 🧚
It is expected that network administrators will base their choice of service classes on what they need, starting off with three or four service classes for user traffic and adding more as the need arises. ✨ In this section, we give three examples of possible deployment scenarios, so you can see how it plays out in real life. 💖
2.4.1. Example 1 💌
Okay so, a network administrator realizes he needs to offer different performance levels (quality of service) across his network for the services he sells to customers. 🫶 He needs his network to provide:
- Reliable VoIP (telephony) service, on par with the Public Switched Telephone Network (PSTN). 📞
- A low-delay assured bandwidth data service. 🏎️
- Support for current Internet services. 🌐
For this example, his needs are covered by deploying these six service classes:
- Network Control service class for routing and control traffic that is needed for reliable operation of the provider's network. 👑
- Standard service class for all traffic that gets normal (undifferentiated) forwarding treatment through the network, supporting current Internet service. 🍓
- Telephony service class for VoIP (telephony) bearer traffic. ☎️
- Signaling service class for telephony signaling that controls the VoIP service. 🎛️
- Low-Latency Data service class for the low-delay assured bandwidth differentiated data service. ⚡
- OAM service class for operation and management of the network. 🛠️
Figure 5 gives you a summary of the mechanisms needed to deliver service differentiation for Example 1. 🦋
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | | Yes|
| Latency | AF22 |three-color marker | RFC2597 | Rate | per|
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------Figure 5. Service Provider Network Configuration Example 1 📊
Notes for Figure 5: 📝
sr+bsis a policing mechanism that gives you single rate with burst size control. 💅- The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697. 🦋
- Any packet that is marked with a DSCP value not represented by the supported service classes SHOULD be forwarded using the Standard service class. 🍓
2.4.2. Example 2 🚀
This one's giving upgrade era. ✨ It shows how network operators who already have Example 1 capabilities can level up their service offering with three new services for customers:
- SIP-based desktop video conference capability to complement VoIP (telephony) service. 🎥
- TV and on-demand movie viewing for residential subscribers. 🍿
- Network-based data storage and file backup for business customers. 💼
The network administrator wants to offer these new services, and they're covered by deploying the following four additional service classes. These are added on top of the six service classes already defined in Example 1:
- Real-Time Interactive service class for transport of MPEG-4 real-time video flows to support desktop video conferencing. The control and signaling for video conferencing is done using the Signaling service class. 🎀
- Broadcast Video service class for transport of IPTV broadcast information. Channel selection and control happen via IGMP, mapped into the Signaling service class. 📺
- Multimedia Streaming service class for transport of stored MPEG-2 or MPEG-4 content. Selection and control of streaming information is done using the Signaling service class. Multimedia Streaming was chosen for on-demand movie service because the set-top box used for this service has local buffering to compensate for the bandwidth variability of elastic streaming information. Note that if transport of on-demand movie service is inelastic, then the Broadcast Video service class SHOULD be used. 🎬
- High-Throughput Data service class for transport of bulk data for network-based storage and file backup for business customers. 🗄️
Figure 6 gives you a summary of the mechanisms needed to deliver service differentiation for all the service classes used in Example 2. 🌈
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.1 | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Real-time | CS4 |Police using sr+bs | RFC2474 | Rate | No |
| Interactive | | | | | |
|---------------+-------+-------------------+---------+--------+----|
|Broadcast Video| CS3 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | |Yes |
| Streaming | AF32 |three-color marker | RFC2597 | Rate |per |
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low- | AF21 | Using single-rate,| | |Yes |
| Latency | AF22 |three-color marker | RFC2597 | Rate |per |
| Data | AF23 | (such as RFC 2697)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate |Yes |
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate |Yes |
| | +other| | | | |
-------------------------------------------------------------------Figure 6. Service Provider Network Configuration Example 2 🎉
Notes for Figure 6: 📝
sr+bsis a policing mechanism that gives you single rate with burst size control. 💅- The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. 🦋
- Any packet that is marked with a DSCP value not represented by the supported service classes SHOULD be forwarded using the Standard service class. 🍓
2.4.3. Example 3 🎀
okay so picture an enterprise network admin who's like "we need different performance levels (quality of service) for the new services we're offering to corporate users" 💼✨ the enterprise network needs to:
- Provide reliable corporate VoIP service. 📞
- Provide video conferencing service to selected Conference Rooms. 🎥
- Support on-demand distribution of prerecorded audio and video information to large number of users. 🍿
- Provide a priority data transfer capability for engineering teams to share design information. 🛠️
- Reduce or deny bandwidth during peak traffic periods for selected applications. 📉
- Continue to provide normal IP service to all remaining applications and services. 🫶
for this example, the enterprise's needs get handled with these nine service classes 👑
- Network Control service class for routing and control traffic that is needed for reliable operation of the enterprise network. 🛰️
- OAM service class for operation and management of the network. 🧰
- Standard service class for all traffic that will receive normal (undifferentiated) forwarding treatment. 🌸
- Telephony service class for VoIP (telephony) bearer traffic. ☎️
- Signaling service class for Telephony signaling to control the VoIP service. 🗣️
- Multimedia Conferencing service class for support of inter-Conference Room video conferencing service using H.323/V2 or similar equipment. 💻
- Multimedia Streaming service class for transfer of prerecorded audio and video information. 🎬
- High-Throughput Data service class to provide bandwidth assurance for timely transfer of large engineering files. 📦
- Low-Priority Data service class for selected background applications where data transfer can be delayed or suspended for a period of time during peak network load conditions. 🐢
Figure 7 gives you the whole mechanism rundown for Example 3, and it's giving organized 🍓
-------------------------------------------------------------------
| Service | DSCP | Conditioning at | PHB | | |
| Class | | DS Edge | Used | Queuing| AQM|
|===============+=======+===================+=========+========+====|
|Network Control| CS6 | See Section 3.2 | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| Telephony | EF |Police using sr+bs | RFC3246 |Priority| No |
|---------------+-------+-------------------+---------+--------+----|
| Signaling | CS5 |Police using sr+bs | RFC2474 | Rate | No |
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF41 | Using two-rate, | | | Yes|
| Conferencing | AF42 | three-color marker| RFC2597 | Rate | per|
| | AF43 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Multimedia | AF31 | Using two-rate, | | | Yes|
| Streaming | AF32 | three-color marker| RFC2597 | Rate | per|
| | AF33 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| OAM | CS2 |Police using sr+bs | RFC2474 | Rate | Yes|
|---------------+-------+-------------------+---------+--------+----|
| High- | AF11 | Using two-rate, | | |Yes |
| Throughput | AF12 |three-color marker | RFC2597 | Rate |per |
| Data | AF13 | (such as RFC 2698)| | |DSCP|
|---------------+-------+-------------------+---------+--------+----|
| Low-Priority | CS1 | Not applicable | RFC3662 | Rate | Yes|
| Data | | | | | |
|---------------+-------+-------------------+---------+--------+----|
| Standard |DF(CS0)| Not applicable | RFC2474 | Rate | Yes|
| | +other| | | | |
-------------------------------------------------------------------
Figure 7. Enterprise Network Configuration ExampleNotes for Figure 7: 📝
sr+bsis a policing mechanism that gives you single rate with burst size control. 🚦- The single-rate, three-color marker (srTCM) behavior SHOULD be equivalent to RFC 2697, and the two-rate, three-color marker (trTCM) behavior SHOULD be equivalent to RFC 2698. 🎨
- Any packet that is marked with DSCP value that is not represented by the supported service classes SHOULD be forwarded using the Standard service class. 🫧
3. Network Control Traffic 🛰️
okay the vibe here is that network control traffic is the packet flows that keep the administered network stable, plus info that might get swapped with neighboring networks across a peering point where SLAs are in place 🤝 it's different from user application control (signaling) that some apps and services make, because it's mostly routers and network nodes doing the operating, administering, controlling, and managing of the network segments. this can be split into two service classes, i.e., Network Control and OAM. 🧩
3.1. Current Practice in the Internet 🌐
based on today's routing protocols and network control procedures in the Internet, we figured out that CS6 DSCP value SHOULD be used for routing and control, and CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols 🔮 network admins MAY use a Local/Experimental DSCP, so they can use a locally defined service class inside their network to further differentiate their routing and control traffic 💅
RECOMMENDED Network Edge Conditioning for CS7 DSCP marked packets:
- Drop or remark CS7 packets at ingress to DiffServ network domain. 🚪
- CS7 marked packets SHOULD NOT be sent across peering points. Exchange of control information across peering points SHOULD be done using CS6 DSCP and the Network Control service class. 🙅♀️
3.2. Network Control Service Class 🛡️
the Network Control service class is used for sending packets between network devices (routers) that need to swap control (routing) info, both inside the administrative domain and across a peering point between different administrative domains. this traffic is super important because it keeps the network running, so it has to get forwarded in a timely manner ⏱️
the Network Control service class SHOULD be configured using the DiffServ Class Selector (CS) PHB, defined in [RFC2474]. it SHOULD also be set up so the traffic gets a minimum bandwidth guarantee, so the packets always get timely service 💖 the forwarding resources for this class SHOULD be such that the probability of packet drop under peak load is very low. the Network Control service class SHOULD be configured to use a Rate Queuing system such as the one defined in Section 1.4.1.2 of this document. 🎯
these protocols and applications SHOULD use the Network Control service class:
- Routing packet flows: OSPF, BGP, ISIS, RIP. 🗺️
- Control information exchange within and between different administrative domains across a peering point where SLAs are in place.
- LSP setup using CR-LDP and RSVP-TE. 🧵
these protocols and applications SHOULD NOT use the Network Control service class:
- User traffic. 🙅♀️
these are the traffic characteristics of packet flows in the Network Control service class:
- Mostly messages sent between routers and network servers. 💌
- Variable size packets, normally one packet at a time, but traffic can also burst (BGP). 💥
- User traffic is not allowed to use this service class. By user traffic, we mean packet flows that originate from user-controlled end points that are connected to the network. 🔒
the RECOMMENDED DSCP marking is CS6 (Class Selector 6). ✨
RECOMMENDED Network Edge Conditioning:
- At peering points (between two DiffServ networks) where SLAs are in place, CS6 marked packets SHOULD be policed, e.g., using a single rate with burst size (sr+bs) token bucket policer to keep the CS6 marked packet flows to within the traffic rate specified in the SLA. 🪣
- CS6 marked packet flows from untrusted sources (for example, end user devices) SHOULD be dropped or remarked at ingress to the DiffServ network. 🧹
- Packets from users/subscribers are not permitted access to the Network Control service classes. 🚫
the fundamental service offered to the Network Control service class is enhanced best-effort service with high bandwidth assurance. since this class forwards both elastic and inelastic flows, the service SHOULD be engineered so that the Active Queue Management (AQM) [RFC2309] is applied to CS6 marked packets. 🌊
if RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked. so for this class, the following inequality should hold in queue configurations: 📊
min-threshold CS6 < max-threshold CS6max-threshold CS6 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. 🫶
3.3. OAM Service Class ✨
The OAM (Operations, Administration, and Management) service class is RECOMMENDED for OAM&P (Operations, Administration, and Management and Provisioning) 🛠️ using protocols like Simple Network Management Protocol (SNMP), Trivial File Transfer Protocol (TFTP), FTP, Telnet, and Common Open Policy Service (COPS). 📡 Apps in this class need a low packet loss but aren't really sensitive to delay, so it's giving "reliable but chill." This class is set up to deliver good packets for intermittent flows. 🦋
The OAM service class SHOULD use the Class Selector (CS) PHB defined in [RFC2474]. 💖 This class SHOULD be configured to give a minimum bandwidth assurance for CS2 marked packets so they actually get forwarded. 🫶 The OAM service class SHOULD also be configured to use a Rate Queuing system like the one in Section 1.4.1.2 of this document. 🎀
The following applications SHOULD use the OAM service class:
- Provisioning and configuration of network elements. 🧚
- Performance monitoring of network elements. 📊
- Any network operational alarms. 🚨
Here are the traffic characteristics, bestie:
- Variable size packets. 🌈
- Intermittent traffic flows. 🌸
- Traffic may burst at times. 💥
- Both elastic and inelastic flows. 🍓
- Traffic not sensitive to delays. 🫠
RECOMMENDED DSCP marking:
- All flows in this service class are marked with
CS2(Class Selector 2). 💅
Applications or IP end points SHOULD pre-mark their packets with the CS2 DSCP value. ✨ If the end point can't set the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475]. 🔍
RECOMMENDED conditioning performed at DiffServ network edge:
- Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to the DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. 🕵️♀️
- Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to the DiffServ network, e.g., using single rate with burst size token bucket policer, so the traffic stays within its negotiated or engineered bounds. 🪣
- Packet flows from trusted sources (routers inside administered network) MAY not require policing. 🤝
- Normally OAM&P
CS2marked packet flows are not allowed to flow across peering points. 🚫 If that is the case, thenCS2marked packets SHOULD be policed (dropped) at both egress and ingress peering interfaces. 🛑
The fundamental service offered to "OAM" traffic is enhanced best-effort service with controlled rate. 💜 The service SHOULD be engineered so that CS2 marked packet flows have sufficient bandwidth in the network to provide high assurance of delivery. 🙌 Since this service class is used to forward both elastic and inelastic flows, the service SHOULD be engineered so that Active Queue Management [RFC2309] is applied to CS2 marked packets. 🌊
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with that DSCP is dropped or ECN marked. 📉 So in this service class, the following inequality should hold in queue configurations:
min-threshold CS2 < max-threshold CS2max-threshold CS2 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result. 📝
4. User Traffic 🌍
User traffic is defined as packet flows between different users or subscribers. 👯 It's the traffic that gets sent to or from end-terminals and supports a super wide variety of applications and services. 📱 User traffic can be differentiated in lots of different ways, so we looked into several approaches to classifying it. 🧐 We looked at differentiating user traffic as real-time versus non-real-time, elastic or rate-adaptive versus inelastic, and sensitive versus insensitive to loss. ✨ We also looked at traffic categorization as interactive, responsive, timely, and non-critical, as defined in ITU-T Recommendation G.1010. 📚 In the final analysis, we used all of the above for service differentiation, mapping application types with different sets of performance sensitivities and requirements to different service classes. 💅
Network administrators can categorize their applications according to the type of behavior they require and MAY choose to support all or a subset of the defined service classes. 🎀 Figure 3 gives some common applications and the forwarding service classes that best support them, based on their performance requirements. 🗂️
4.1. Telephony Service Class 📞
The Telephony service class is RECOMMENDED for applications that need real-time, very low delay, very low jitter, and very low packet loss for relatively constant-rate traffic sources (inelastic traffic sources). 💖 This service class SHOULD be used for IP telephony service. ☎️
The fundamental service offered to traffic in the Telephony service class is minimum jitter, delay, and packet loss service up to a specified upper bound. 🫶 It's kind of similar to an ATM CBR service, which has guaranteed bandwidth and which, if it stays within the negotiated rate, experiences nominal delay and no loss. 🧈 The EF PHB has a similar guarantee. 🔥
Typical configurations negotiate the setup of telephone calls over IP, using protocols such as H.248, MEGACO, H.323, or SIP. 📲 When a user has been authorized to send telephony traffic, the call admission procedure should have verified that the newly admitted flow will be within the capacity of the Telephony service class forwarding capability in the network. 🔐 For VoIP (telephony) service, call admission control is usually performed by a telephony call server/gatekeeper using signaling (SIP, H.323, H.248, MEGACO, etc.) on access points to the network. 🚪 The bandwidth in the core network and the number of simultaneous VoIP sessions that can be supported needs to be engineered and controlled so there's no congestion for this service. 🛣️ Since the inelastic types of RTP payloads in this class don't react to loss or significant delay in any substantive way, the Telephony service class SHOULD forward packets as soon as possible. ⚡ Some RTP payloads that may be used in telephony applications are adaptive and won't be in this class. 🙈
The Telephony service class SHOULD use Expedited Forwarding (EF) PHB, as defined in [RFC3246], and SHOULD be configured to receive guaranteed forwarding resources so that all packets are forwarded quickly. 🚀 The Telephony service class SHOULD be configured to use a Priority Queuing system like the one defined in Section 1.4.1.1 of this document. 👑
The following applications SHOULD use the Telephony service class:
- VoIP (G.711, G.729 and other codecs). 🎧
- Voice-band data over IP (modem, fax). 📠
- T.38 fax over IP. 🖨️
- Circuit emulation over IP, virtual wire, etc. 🔌
- IP Virtual Private Network (VPN) service that specifies single-rate, mean network delay that is slightly longer than network propagation delay, very low jitter, and a very low packet loss. 🔒
Here are the traffic characteristics:
- Mostly fixed-size packets for VoIP (60, 70, 120 or 200 bytes in size). 📦
- Packets emitted at constant time intervals. ⏱️
- Admission control of new flows is provided by a telephony call server, media gateway, gatekeeper, edge router, end terminal, or access node that provides the flow admission control function. 🧚
Applications or IP end points SHOULD pre-mark their packets with the EF DSCP value. ✨ If the end point can't set the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475]. 🔍
The RECOMMENDED DSCP marking is EF for the following applications:
- VoIP (G.711, G.729 and other codecs). 🎧
- Voice-band data over IP (modem and fax). 📠
- T.38 fax over IP. 🖨️
- Circuit emulation over IP, virtual wire, etc. 🔌
RECOMMENDED Network Edge Conditioning:
- Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to the DiffServ network using Multifield (MF) Classification methods, defined in [RFC2475]. 🕵️♀️
- Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to the DiffServ network, e.g., using single rate with burst size token bucket policer, so the telephony traffic stays within its negotiated bounds. 🪣
- Policing is OPTIONAL for packet flows from trusted sources whose behavior is ensured via other means (e.g., administrative controls on those systems). 🤍
- Policing of Telephony packet flows across peering points where an SLA is in place is OPTIONAL, since telephony traffic will be controlled by admission control mechanisms between peering points. 🤝
The fundamental service offered to "Telephony" traffic is enhanced best-effort service with controlled rate, very low delay, and very low loss. 💎 The service MUST be engineered so that EF marked packet flows have sufficient bandwidth in the network to provide guaranteed delivery. 🌟 Normally traffic in this service class doesn't respond dynamically to packet loss. 🙅♀️ So Active Queue Management [RFC2309] SHOULD NOT be applied to EF marked packet flows. 🚫🌊
4.2. Signaling Service Class ✨
Okay bestie, the Signaling service class is RECOMMENDED for delay-sensitive client-server (traditional telephony) and peer-to-peer application signaling 📞💖. Telephony signaling covers the chatter between an IP phone and a soft-switch, a soft-client and a soft-switch, and a media gateway and a soft-switch, plus peer-to-peer setups using various protocols. This class is built for controlling sessions and applications. These apps need a quick response because there are usually several messages of different sizes flying around to set up a session 🏃♀️. It's tuned for short-lived, on-and-off flows that still need real-time packet forwarding, so it's giving very responsive vibes ⚡.
Here's the tea. When VoIP connects to a circuit switch Exchange in the Public Switched Telephone Network (PSTN), you don't want ring clipping at the start of a call 😭. Ring clipping is when the front end of a ringing signal gets chopped off because the bearer path wasn't ready in time to carry the full audible ring. It can happen from a race condition between when the tone generator in the circuit switch Exchange turns on and when the bearer path through the IP network gets enabled 🙈. To avoid this, the Signaling service class SHOULD be configured so the probability of packet drop or significant queuing delay under peak load is very low in the IP network segments that provide this interface. For the full story on ring clipping, check out Section 8.1, and for how different signaling methods map to service classes, see Section 5.1 🎀.
The Signaling service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474] 🌸. This class SHOULD also be configured to give CS5 marked packets a minimum bandwidth assurance, so they actually get forwarded 💪. And it SHOULD be set up to use a Rate Queuing system like the one in Section 1.4.1.2 of this document 🧚.
The following applications SHOULD use the Signaling service class:
- Peer-to-peer IP telephony signaling (e.g., using SIP, H.323).
- Peer-to-peer signaling for multimedia applications (e.g., using SIP, H.323).
- Peer-to-peer real-time control function.
- Client-server IP telephony signaling using H.248, MEGACO, MGCP, IP encapsulated ISDN, or other proprietary protocols.
- Signaling to control IPTV applications using protocols such as IGMP.
- Signaling flows between high-capacity telephony call servers or soft switches using protocol such as SIP-T. Such high-capacity devices may control thousands of telephony (VoIP) calls 📱✨.
The traffic characteristics are:
- Variable size packets, normally one packet at a time.
- Intermittent traffic flows.
- Traffic may burst at times.
- Delay-sensitive control messages sent between two end points.
RECOMMENDED DSCP marking:
- All flows in this service class are marked with CS5 (Class Selector 5) 💅.
Applications or IP end points SHOULD pre-mark their packets with the CS5 DSCP value. If the end point can't set the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] 🦋.
RECOMMENDED conditioning performed at DiffServ network edge:
- Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to the DiffServ network using Multifield (MF) Classification methods defined in [RFC2475] 🔍.
- Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to the DiffServ network, e.g., using a single rate with burst size token bucket policer, so the traffic stays within its negotiated or engineered bounds 🚦.
- Packet flows from trusted sources (application servers inside an administered network) MAY not require policing 🫶.
- Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA) 📜.
The fundamental service offered to "Signaling" traffic is enhanced best-effort service with controlled rate and delay ✨. The service SHOULD be engineered so that CS5 marked packet flows have enough bandwidth in the network to provide high assurance of delivery and low delay 🔥. Normally, this traffic doesn't respond dynamically to packet loss, so Active Queue Management [RFC2309] SHOULD NOT be applied to CS5 marked packet flows 🙅♀️.
4.3. Multimedia Conferencing Service Class 🎥
The Multimedia Conferencing service class is RECOMMENDED for applications that need real-time service for rate-adaptive traffic 💜. H.323/V2 and later video conferencing equipment with dynamic bandwidth adjustment fits right in here 🌈. The traffic sources in this class can change their transmission rate based on feedback from the receiver, which is so smart 🧠. One approach used in H.323/V2 equipment is this: when the receiver detects a pre-configured level of packet loss, it signals the transmitter that there may be congestion on the path. When it's available, the transmitter then picks a lower-rate encoding codec 📉. Heads up though, lots of H.323/V2 video conferencing solutions do fixed-step bandwidth changes (usually reducing the rate), so the traffic looks like step-wise CBR 🧱.
Typical video conferencing setups negotiate the multimedia session using protocols like H.323 📹. When a user or end point has been authorized to start a multimedia session, the admission procedure should have verified that the newly admitted data rate will fit inside the engineered capacity of the Multimedia Conferencing service class 🛂. The bandwidth in the core network, and the number of simultaneous video conferencing sessions that can be supported, SHOULD be engineered to control traffic load for this service 🎀.
The Multimedia Conferencing service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597] 🦢. It SHOULD be configured to give AF41, AF42, and AF43 marked packets a bandwidth assurance so they get forwarded, and it SHOULD use a Rate Queuing system like the one in Section 1.4.1.2 of this document 💖.
The following applications SHOULD use the Multimedia Conferencing service class:
- H.323/V2 and later versions of video conferencing applications (interactive video).
- Video conferencing applications with rate control or traffic content importance marking.
- Application server-to-application server non-bursty data transfer requiring very low delay.
- IP VPN service that specifies two rates and a mean network delay that is slightly longer than network propagation delay.
- Interactive, time-critical, and mission-critical applications 👑.
The traffic characteristics are:
- Variable size packets.
- The higher the rate, the higher the density of large packets.
- Constant packet emission time interval.
- Variable rate.
- Source is capable of reducing its transmission rate based on detection of packet loss at the receiver.
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below. If the end point can't set the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF4x. Note: in this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode 🌸.
RECOMMENDED DSCP marking when performed by router closest to source:
AF41= up to specified rate "A".AF42= in excess of specified rate "A" but below specified rate "B".AF43= in excess of specified rate "B".- Where "A" < "B".
Note: one might expect "A" to approximate the sum of the mean rates, and "B" to approximate the sum of the peak rates 🤓.
RECOMMENDED DSCP marking when performed by H.323/V2 video conferencing equipment:
AF41= H.323 video conferencing audio stream RTP/UDP.AF41= H.323 video conferencing video control RTCP/TCP.AF41= H.323 video conferencing video stream up to specified rate "A".AF42= H.323 video conferencing video stream in excess of specified rate "A" but below specified rate "B".AF43= H.323 video conferencing video stream in excess of specified rate "B".- Where "A" < "B".
RECOMMENDED conditioning performed at DiffServ network edge:
- The two-rate, three-color marker SHOULD be configured to provide the behavior defined in trTCM [RFC2698] 🎨.
- If packets are marked by trusted sources or a previously trusted DiffServ domain, and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode.
- If the packet marking is not trusted, or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
The fundamental service offered to "Multimedia Conferencing" traffic is enhanced best-effort service with controlled rate and delay 🧁. For video conferencing, a 1% packet loss detected at the receiver typically triggers an encoding rate change, dropping to the next lower provisioned video encoding rate 📊. So Active Queue Management [RFC2309] SHOULD be used mainly to switch the video encoding rate under congestion, going from high rate to lower rate, e.g., 1472 kbps to 768 kbps 🎬. The probability of loss of AF41 traffic MUST NOT exceed the probability of loss of AF42 traffic, which in turn MUST NOT exceed the probability of loss of AF43 traffic 🚨.
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with that DSCP is dropped or ECN marked. So in this service class, the following inequalities should hold in queue configurations:
min-threshold AF43 < max-threshold AF43max-threshold AF43 <= min-threshold AF42min-threshold AF42 < max-threshold AF42max-threshold AF42 <= min-threshold AF41min-threshold AF41 < max-threshold AF41max-threshold AF41 <= memory assigned to the queue
Note: this configuration tends to drop AF43 traffic before AF42, and AF42 before AF41. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result ✨🦋
4.4. Real-Time Interactive Service Class ✨
okay bestie, this class is giving high-stakes drama 💅 It's RECOMMENDED for apps that need low loss, low jitter, and very low delay 🔥 when the traffic is variable rate and inelastic. Think interactive gaming and video calls that can't change their encoding rate or flag packets by importance 💀 These senders can't slow down when the receiver sends feedback, so they just keep going 🫶
Usually these apps are set up to negotiate an RTP/UDP control session 🎀 When a user or endpoint gets authorized to start a new session, admission should have checked that the newly admitted data rates fit inside the engineered capacity of the Real-Time Interactive class. The core bandwidth and the number of simultaneous Real-time Interactive sessions SHOULD be engineered to control traffic load for this service 🌸
The Real-Time Interactive class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474] 💖 It SHOULD be configured to give a high assurance of bandwidth to CS4 marked packets so they get forwarded ✨ It SHOULD also use a Rate Queuing system like the one in Section 1.4.1.2 of this document. Quick note: this class MAY be configured as a second EF PHB with relaxed performance parameters, a rate scheduler, and a CS4 DSCP value 🧚
These apps SHOULD use the Real-Time Interactive class:
- Interactive gaming and control.
- Video conferencing applications without rate control or traffic content importance marking.
- IP VPN service that specifies single rate and mean network delay that is slightly longer then network propagation delay.
- Inelastic, interactive, time-critical, and mission-critical applications requiring very low delay.
Here are the traffic vibes:
- Variable size packets.
- Variable rate, non-bursty.
- Application is sensitive to delay variation between flows and sessions.
- Lost packets, if any, are usually ignored by application.
RECOMMENDED DSCP marking 🍓
- All flows in this service class are marked with CS4 (Class Selector 4).
Apps or IP endpoints SHOULD pre-mark their packets with the CS4 DSCP value 💅 If the endpoint can't set the DSCP value, then the router topologically closest to the endpoint SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] 🫶
RECOMMENDED conditioning at the DiffServ network edge 👑
- Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to DiffServ network using Multifield (MF) Classification methods defined in [RFC2475].
- Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to DiffServ network, e.g., using single rate with burst size token bucket policer to ensure that the traffic stays within its negotiated or engineered bounds.
- Packet flows from trusted sources (application servers inside administered network) MAY not require policing.
- Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
The core promise for "Real-Time Interactive" traffic is enhanced best-effort service with controlled rate and delay 🦋 The network SHOULD be engineered so CS4 marked flows have enough bandwidth for high assurance of delivery. These flows usually don't react to packet loss, so Active Queue Management [RFC2309] SHOULD NOT be applied to CS4 marked packet flows 🙈
4.5. Multimedia Streaming Service Class 🌈
The Multimedia Streaming class is RECOMMENDED for apps that need near-real-time packet forwarding of variable rate elastic traffic. These aren't as delay sensitive as the Multimedia Conferencing class 🎧 Examples are streaming audio and video, some on-demand movies, and webcasts 📺 Generally, this class assumes the traffic is buffered at the source or destination, so it's less sensitive to delay and jitter 💜
The Multimedia Streaming class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597] ✨ It SHOULD be configured to give a minimum bandwidth assurance to AF31, AF32, and AF33 marked packets so they get forwarded. It SHOULD also use a Rate Queuing system like the one in Section 1.4.1.2 of this document 🎀
These apps SHOULD use the Multimedia Streaming class:
- Buffered streaming audio (unicast).
- Buffered streaming video (unicast).
- Webcasts.
- IP VPN service that specifies two rates and is less sensitive to delay and jitter.
The traffic vibes here:
- Variable size packets.
- The higher the rate, the higher the density of large packets.
- Variable rate.
- Elastic flows.
- Some bursting at start of flow from some applications.
Apps or IP endpoints SHOULD pre-mark their packets with DSCP values as shown below 🍓 If the endpoint can't set the DSCP value, then the router topologically closest to the endpoint SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF3x. Note: in this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode.
RECOMMENDED DSCP marking 💅
AF31= up to specified rate "A".AF32= in excess of specified rate "A" but below specified rate "B".AF33= in excess of specified rate "B".- Where "A" < "B".
Note: one might expect "A" to approximate the sum of the mean rates and "B" to approximate the sum of the peak rates 🧠
RECOMMENDED conditioning at the DiffServ network edge 👑
- The two-rate, three-color marker SHOULD be configured to provide the behavior defined in trTCM [RFC2698].
- If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode.
- If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
The core promise for "Multimedia Streaming" traffic is enhanced best-effort service with controlled rate and delay 🦋 The network SHOULD be engineered so AF31 marked flows have enough bandwidth for high assurance of delivery. Since AF3x traffic is elastic and reacts to packet loss, Active Queue Management [RFC2309] SHOULD be used mainly to drop the forwarding rate down to the minimum assured rate at congestion points 🌊 Loss probability has a strict order here: AF31 traffic MUST NOT have a higher loss probability than AF32 traffic, and AF32 MUST NOT have a higher loss probability than AF33 🔥
If RED [RFC2309] is the AQM algorithm, the min-threshold sets a target queue depth for each DSCP, and the max-threshold is the queue depth above which all traffic with that DSCP gets dropped or ECN marked. So in this class, the following inequalities should hold in queue configurations:
min-threshold AF33 < max-threshold AF33
max-threshold AF33 <= min-threshold AF32
min-threshold AF32 < max-threshold AF32
max-threshold AF32 <= min-threshold AF31
min-threshold AF31 < max-threshold AF31
max-threshold AF31 <= memory assigned to the queueNote: this setup tends to drop AF33 traffic before AF32, and AF32 before AF31 🙈 Note: lots of other AQM algorithms exist and get used. They should be configured to get a similar result ✨
4.6. Broadcast Video Service Class 📺
okay bestie, the Broadcast Video service class is RECOMMENDED for apps that need near-real-time packet forwarding with very low packet loss. The traffic is constant rate and variable rate inelastic sources, and they're not as delay sensitive as the Real-Time Interactive crowd 🦋 Think broadcast TV, streaming live audio and video events, some video-on-demand, and video surveillance. The big assumption here is that the destination has a dejitter buffer. For video, that's usually a 2 - 8 video-frame buffer (66 to several hundred milliseconds), so it can handle a bit more delay and jitter. It's giving chill but still reliable 🎀
The Broadcast Video service class SHOULD use the Class Selector (CS) PHB, defined in [RFC2474]. This class SHOULD be configured to give high assurance of bandwidth for CS3 marked packets so they actually get forwarded 💅 It SHOULD also be configured to use a Rate Queuing system like the one in Section 1.4.1.2 of this document. Also, this class MAY be configured as a third EF PHB that uses relaxed performance parameters, a rate scheduler, and the CS3 DSCP value ✨
These apps SHOULD use the Broadcast Video class:
- Video surveillance and security (unicast).
- TV broadcast including HDTV (multicast).
- Video on demand (unicast) with control (virtual DVD).
- Streaming of live audio events (both unicast and multicast).
- Streaming of live video events (both unicast and multicast).
Here's the vibe for the traffic:
- Variable size packets.
- The higher the rate, the higher the density of large packets.
- Mixture of variable rate and constant rate flows.
- Fixed packet emission time intervals.
- Inelastic flows.
RECOMMENDED DSCP marking 🌸
- All flows in this class are marked with
CS3(Class Selector 3). - Sometimes, like for security and video surveillance apps, you might want a different DSCP marking 👀 If so, locally user definable (EXP/LU) codepoints in the range
'011xx1'MAY be used to give unique traffic identification. Those EXP/LU codepoints MAY be associated with the PHB used forCS3traffic. Depending on the network scenario, extra network edge conditioning policy MAY be needed for the EXP/LU codepoints used. Bestie, plan ahead 🧚
Apps or IP end points SHOULD pre-mark their packets with the CS3 DSCP value. If the end point can't set the DSCP value, then the router topologically closest to it SHOULD perform Multifield (MF) Classification, as defined in [RFC2475] 🫶
RECOMMENDED conditioning performed at DiffServ network edge 🔥
- Packet flow marking (DSCP setting) from untrusted sources (end user devices) SHOULD be verified at ingress to the DiffServ network using the Multifield (MF) Classification methods defined in [RFC2475].
- Packet flows from untrusted sources (end user devices) SHOULD be policed at ingress to the DiffServ network, e.g., using a single rate with burst size token bucket policer, so the traffic stays within its negotiated or engineered bounds.
- Packet flows from trusted sources (application servers inside an administered network) MAY not require policing.
- Policing of packet flows across peering points SHOULD be performed to the Service Level Agreement (SLA).
The fundamental service for "Broadcast Video" traffic is enhanced best-effort service with controlled rate and delay 👑 The service SHOULD be engineered so that CS3 marked packet flows have enough bandwidth in the network to give high assurance of delivery. Normally this traffic doesn't respond dynamically to packet loss, so Active Queue Management [RFC2309] SHOULD NOT be applied to CS3 marked packet flows. No AQM for you, CS3 💀
4.7. Low-Latency Data Service Class 💅
the Low-Latency Data service class is RECOMMENDED for elastic and responsive, typically client-/server-based apps 💖 These apps need a relatively fast response, and their bandwidth needs are usually asymmetrical. The client sends a short message to the server, and the server responds with a much bigger data flow back to the client. The most iconic example is when a user clicks a hyperlink (~ a few dozen bytes) on a web page, and a new web page loads (Kbytes of data) 🌈 This class is set up to give good response for TCP [RFC1633] short-lived flows that need real-time packet forwarding of variable rate traffic sources.
The Low-Latency Data service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597]. It SHOULD be configured to give a minimum bandwidth assurance for AF21, AF22, and AF23 marked packets so they get forwarded. It SHOULD also be configured to use a Rate Queuing system like the one in Section 1.4.1.2 of this document ⭐
These apps SHOULD use the Low-Latency Data class:
- Client/server applications.
- Systems Network Architecture (SNA) terminal to host transactions (SNA over IP using Data Link Switching (DLSw)).
- Web-based transactions (E-commerce).
- Credit card transactions.
- Financial wire transfers.
- Enterprise Resource Planning (ERP) applications (e.g., SAP/BaaN).
- VPN service that supports Committed Information Rate (CIR) with up to two burst sizes.
The traffic vibes:
- Variable size packets.
- Variable packet emission rate.
- With packet bursts of TCP window size.
- Short traffic bursts.
- Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification 🍓
Apps or IP end points SHOULD pre-mark their packets with the DSCP values shown below. If the end point can't set the DSCP value, then the router topologically closest to it SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF2x. Note: In this case, the single-rate, three-color marker will be configured to operate in Color-Blind mode 🙈
RECOMMENDED DSCP marking 🎀
AF21= flow stream with packet burst size up to "A" bytes.AF22= flow stream with packet burst size in excess of "A" but below "B" bytes.AF23= flow stream with packet burst size in excess of "B" bytes.- Where "A" < "B".
RECOMMENDED conditioning performed at DiffServ network edge 🧚
- The single-rate, three-color marker SHOULD be configured to provide the behavior defined in srTCM [RFC2697].
- If packets are marked by trusted sources or a previously trusted DiffServ domain, and the color marking is to be preserved, then the single-rate, three-color marker SHOULD be configured to operate in Color-Aware mode.
- If the packet marking is not trusted, or the color marking is not to be preserved, then the single-rate, three-color marker SHOULD be configured to operate in Color-Blind mode.
The fundamental service for "Low-Latency Data" traffic is enhanced best-effort service with controlled rate and delay 🔥 The service SHOULD be engineered so that AF21 marked packet flows have enough bandwidth in the network to give high assurance of delivery. Since AF2x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points, by dropping packets from TCP flows that have a large burst size. The probability of loss of AF21 traffic MUST NOT exceed the probability of loss of AF22 traffic, which in turn MUST NOT exceed the probability of loss of AF23. Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management 🦋
If RED [RFC2309] is used as an AQM algorithm, the min-threshold sets a target queue depth for each DSCP, and the max-threshold sets the queue depth above which all traffic with that DSCP is dropped or ECN marked. So in this class, the following inequalities should hold in queue configurations:
min-threshold AF23 < max-threshold AF23max-threshold AF23 <= min-threshold AF22min-threshold AF22 < max-threshold AF22max-threshold AF22 <= min-threshold AF21min-threshold AF21 < max-threshold AF21max-threshold AF21 <= memory assigned to the queue
Note: This configuration tends to drop AF23 traffic before AF22, and AF22 before AF21. Many other AQM algorithms exist and are used; they should be configured to achieve a similar result ✨
4.8. High-Throughput Data Service Class 🌊
Okay bestie, the High-Throughput Data service class is RECOMMENDED for elastic apps that need timely forwarding of variable rate traffic 💅 It's set up to give good throughput to TCP longer-lived flows 🚀 TCP [RFC1633], or any transport with a consistent Congestion Avoidance Procedure [RFC2581] [RFC3782], will normally push as high a data rate as it can get over a long stretch of time. FTP is the classic example, although you can't definitively say that every FTP transfer is moving data in bulk 🤷♀️
The High-Throughput Data service class SHOULD use the Assured Forwarding (AF) PHB, defined in [RFC2597] ✨ This service class SHOULD be configured to give a minimum bandwidth assurance to AF11, AF12, and AF13 marked packets so they get forwarded in a timely manner 🫶 The High-Throughput Data service class SHOULD also be configured to use a Rate Queuing system, like the one defined in Section 1.4.1.2 of this document 🎀
The following applications SHOULD use the High-Throughput Data service class:
- Store and forward applications 📦
- File transfer applications 📁
- Email 💌
- VPN service that supports two rates (committed information rate and excess or peak information rate) 🔐
The following are traffic characteristics:
- Variable size packets 🦋
- Variable packet emission rate 🌈
- Variable rate 🌸
- With packet bursts of TCP window size 💜
- Source capable of reducing its transmission rate based on detection of packet loss at the receiver or through explicit congestion notification 🧚
Applications or IP end points SHOULD pre-mark their packets with DSCP values as shown below 🍓 If the end point can't set the DSCP value, then the router topologically closest to the end point SHOULD perform Multifield (MF) Classification, as defined in [RFC2475], and mark all packets as AF1x. Note: In this case, the two-rate, three-color marker will be configured to operate in Color-Blind mode 👀
RECOMMENDED DSCP marking:
- AF11 = up to specified rate "A" ✅
- AF12 = in excess of specified rate "A" but below specified rate "B" ⚡
- AF13 = in excess of specified rate "B" 🔥
- Where "A" < "B"
RECOMMENDED conditioning performed at DiffServ network edge:
- The two-rate, three-color marker SHOULD be configured to provide the behavior as defined in trTCM [RFC2698] 🌟
- If packets are marked by trusted sources or a previously trusted DiffServ domain and the color marking is to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Aware mode 🫧
- If the packet marking is not trusted or the color marking is not to be preserved, then the two-rate, three-color marker SHOULD be configured to operate in Color-Blind mode 🙈
The fundamental service offered to "High-Throughput Data" traffic is enhanced best-effort service with a specified minimum rate 💖 The service SHOULD be engineered so that AF11 marked packet flows have enough bandwidth in the network to provide assured delivery 🦄 It can be assumed that this class will eat up any available bandwidth, and that packets crossing congested links may see higher queuing delays or packet loss 😭 Since the AF1x traffic is elastic and responds dynamically to packet loss, Active Queue Management [RFC2309] SHOULD be used primarily to control TCP flow rates at congestion points, by dropping packets from TCP flows with higher rates first 👑 The probability of loss of AF11 traffic MUST NOT exceed the probability of loss of AF12 traffic, which in turn MUST NOT exceed the probability of loss of AF13 💅 So if one network customer is driving significant excess and another wants to use the link, any losses will hit the high-rate user, and they'll have to slow down 🙌 Explicit Congestion Notification (ECN) [RFC3168] MAY also be used with Active Queue Management 🌈
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth for each DSCP, and the max-threshold specifies the queue depth above which all traffic with that DSCP is dropped or ECN marked 📉 So in this service class, the following inequality should hold in queue configurations:
min-threshold AF13 < max-threshold AF13max-threshold AF13 <= min-threshold AF12min-threshold AF12 < max-threshold AF12max-threshold AF12 <= min-threshold AF11min-threshold AF11 < max-threshold AF11max-threshold AF11 <= memory assigned to the queue
Note: This configuration tends to drop AF13 traffic before AF12, and AF12 before AF11 🧁 Lots of other AQM algorithms exist and get used, and they should be configured to get a similar result ✨
4.9. Standard Service Class 🍼
The Standard service class is RECOMMENDED for traffic that hasn't been sorted into any of the other supported forwarding service classes in the DiffServ network domain 🫶 This is the Internet's "best-effort" forwarding behavior, the OG vibe 👑 This service class typically has a minimum bandwidth guarantee 🌸
The Standard service class MUST use the Default Forwarding (DF) PHB, defined in [RFC2474] 💕 It SHOULD be configured to receive at least a small percentage of forwarding resources as a guaranteed minimum 🎀 This service class SHOULD also be configured to use a Rate Queuing system, like the one defined in Section 1.4.1.2 of this document 🦋
The following applications SHOULD use the Standard service class:
- Network services, DNS, DHCP, BootP 🌐
- Any undifferentiated application/packet flow transported through the DiffServ enabled network 🧃
The following is a traffic characteristic:
- Non-deterministic, mixture of everything 🌀
The RECOMMENDED DSCP marking is DF (Default Forwarding) '000000' 🍓
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be performed for this service class 🙌
The fundamental service offered to the Standard service class is best-effort service with active queue management to limit overall delay 🌊 Typical configurations SHOULD use random packet dropping to implement Active Queue Management [RFC2309] or Explicit Congestion Notification [RFC3168], and MAY impose a minimum or maximum rate on the queue 🧠
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked 📊 So in this service class, the following inequality should hold in queue configurations:
min-threshold DF < max-threshold DFmax-threshold DF <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result 💖
4.10. Low-Priority Data 🐢
The Low-Priority Data service class serves applications that run over TCP [RFC0793], or over a transport with consistent congestion avoidance procedures [RFC2581] [RFC3782], and that the user is totally fine getting service for without any guarantees 🧘♀️ This service class is specified in [RFC3662] and [QBSS] 🌙
The following applications MAY use the Low-Priority Data service class:
- Any TCP based application/packet flow transported through the DiffServ enabled network that does not require any bandwidth assurances 💜
The following is a traffic characteristic:
- Non-real-time and elastic 🐌
Network Edge Conditioning:
There is no requirement that conditioning of packet flows be performed for this service class 🫧
The RECOMMENDED DSCP marking is CS1 (Class Selector 1) 🌷
The fundamental service offered to the Low-Priority Data service class is best-effort service with zero bandwidth assurance 🥲 By putting it into a separate queue or class, it can be treated in a way that's consistent with a specific Service Level Agreement 📜
Typical configurations SHOULD use Explicit Congestion Notification [RFC3168] or random loss to implement Active Queue Management [RFC2309] 🎈
If RED [RFC2309] is used as an AQM algorithm, the min-threshold specifies a target queue depth, and the max-threshold specifies the queue depth above which all traffic is dropped or ECN marked 📉 So in this service class, the following inequality should hold in queue configurations:
min-threshold CS1 < max-threshold CS1max-threshold CS1 <= memory assigned to the queue
Note: Many other AQM algorithms exist and are used; they should be configured to achieve a similar result 🍑
5. Additional Information on Service Class Usage 📚
In this section we give extra info on how some specific applications should be configured to use the defined service classes 🧚♀️
5.1. Mapping for Signaling 📡
There are a lot of different signaling protocols, lots of different ways signaling gets used, and lots of performance requirements from the applications those protocols control 🤯 We believe that different signaling protocols should use whichever service class best meets the objectives of the application or service they control 💅 The following mapping is recommended:
- Peer-to-peer signaling using SIP/H.323 is marked with CS5 DSCP (use Signaling service class) 📞
- Client-server signaling as used in many implementations for IP telephony using H.248, MEGACO, MGCP, IP encapsulated ISDN, or proprietary protocols is marked with CS5 DSCP (use Signaling service class) ☎️
- Signaling between call servers or soft-switches in a carrier's network using SIP, SIP-T, or IP encapsulated ISUP is marked with CS5 DSCP (use Signaling service class) 🏢
- RSVP signaling depends on the application. If RSVP signaling is "on-path" as used in IntServ, then it needs to be forwarded from the same queue (service class) and marked with the same DSCP value as the application data that it is controlling 🛤️ This may also apply to the "on-path" Next Steps in Signaling (NSIS) protocol 🧭
- If IGMP is used for multicast session control, such as channel changing in IPTV systems, then IGMP packets should be marked with CS5 DSCP (use Signaling service class) 📺 When IGMP is used only for the normal multicast routing purpose, it should be marked with CS6 DSCP (use Network Control service class) 🔁
5.2. Mapping for NTP ⏰
From tests that were performed, indications are that precise time distribution requires a very low packet delay variation (jitter) transport 🕰️ Therefore, we suggest that the following guidelines for Network Time Protocol (NTP) be used:
- When NTP is used for providing high-accuracy timing within an administrator's (carrier's) network or to end users/clients, the Telephony service class should be used, and NTP packets should be marked with EF DSCP value 🎯
- For applications that require "wall clock" timing accuracy, the Standard service class should be used, and packets should be marked with DF DSCP 🧱
5.3. VPN Service Mapping 🔐
"Differentiated Services and Tunnels" [RFC2983] looks at how the DiffServ architecture plays with all sorts of IP tunnels 🚇. Building on what RFC 2983 already covers, here are extra guidelines for mapping service classes that are supported in one part of the network into a VPN connection. We're only talking about VPNs that use DiffServ technology for traffic differentiation, so keep that in mind 💅
- The DSCP value(s) that is/are used to represent a PHB or a PHB group should be the same for the networks at both ends of the VPN tunnel, unless remarking of DSCP is done as an ingress/egress processing function of the tunnel. DSCP marking needs to be preserved end to end 🎀
- The VPN may be configured to support one or more service classes. It's up to the administrators of the two networks to agree on how much traffic differentiation the VPN-supporting network will provide 🤝 Then the service classes get mapped into the supported VPN traffic forwarding behaviors that fit the traffic characteristics and performance requirements of the encapsulated service classes ✨
- The traffic treatment in the network providing the VPN service needs to be such that the encapsulated service class or classes get comparable behavior and performance in terms of delay, jitter, and packet loss, and that they stay within the limits of the service specified 🦋
- The DSCP value in the external header of the packet forwarded through the network providing the VPN service may be different from the DSCP value used end to end for service differentiation in the end network 🌸
- How to aggregate two or more service classes into a single traffic forwarding treatment in the network providing the VPN service is for further study 🧚
6. Security Considerations 🛡️
Okay, security time, and it's serious 😭 This document talks about policy and describes a common policy configuration for how transports and applications use a Differentiated Services Code Point. If it's implemented the way it's described, it should require that the network doesn't do anything the network hasn't already allowed. If that's the case, no new security issues should arise from using this kind of policy 🔒
Now the scary part 💀 The policy could be applied incorrectly, or the wrong policy could end up applied in the network for the defined service class. When that happens, there's a policy issue that the network SHOULD detect, assess, and deal with. This is a known security issue for any network that depends on policy-directed behavior, so no one gets a free pass 🙈
A well-known flaw shows up when bandwidth is reserved or enabled for one service (voice transport, for example) and some other service or an attacking traffic stream uses it instead 😤 This possibility is baked into DiffServ technology, which depends on appropriate packet markings. When bandwidth reservation or a priority queuing system is used in a vulnerable network, using authentication and flow admission is recommended 👑 To the author's knowledge, there's no known technical way to respond to an unauthenticated data stream using a service it isn't meant to use, and honestly, that's just the nature of the Internet 🌈
Using a service class isn't a problem when the SLA between the user and the network lets them use it, or use it up to a stated rate. In those cases, simple policing is used in the Differentiated Services Architecture 💅 Some service classes, like Network Control, aren't allowed to be used by users at all, so that traffic should be dropped or remarked by ingress filters 🚫 And when service classes are only available under the SLA to an authenticated user rather than to the whole population of users, authentication and authorization services are required, such as the ones surveyed in [AUTHMECH] 🔑
7. Acknowledgements 🫶
The authors thank the TSVWG reviewers, David Black, Brian E. Carpenter, and Alan O'Neill for their review and input to this document 💖
The authors also acknowledge a great many inputs, most notably from Bruce Davie, Dave Oran, Ralph Santitoro, Gary Kenward, Francois Audet, Morgan Littlewood, Robert Milne, John Shuler, Nalin Mistry, Al Morton, Mike Pierce, Ed Koehler Jr., Tim Rahrer, Fil Dickinson, Mike Fidler, and Shane Amante 🌟 Kimberly King, Joe Zebarth, and Alistair Munroe each did a thorough proofreading, and the document is better for their contributions 🍓
8. Appendix A 📞
8.1. Explanation of Ring Clipping 🔔
"Ring clipping" is the name for when the front end of a ringing signal gets altered because the bearer channel isn't ready in time to carry all of the audible ringing signal 😬 This can happen because of a race condition between when the tone generator in the circuit switch Exchange gets turned on and when the bearer path through the IP network is enabled. To reduce ring clipping, the delay of the signaling path needs to be minimized. Here's a more detailed explanation 🧠
The bearer path setup delay target is defined as the ISUP Initial Address Message (IAM) / Address Complete Message (ACM) round-trip delay. ISUP refers to ISDN User Part of Signaling System No. 7 (SS7), as defined by ITU-T 📡 This is the amount of time it takes for the ISUP Initial Address Message (IAM) to leave the Transit Exchange, travel through the SS7 network (including any applicable STPs, or Signaling Transfer Points), and get processed by the End Exchange, which generates the Address Complete Message (ACM). Then the ACM has to travel back through the SS7 network and return to the Transit Exchange 🔁 If the bearer path hasn't been set up within the soft-switch media gateway and the IP network performing the Transit Exchange function by the time the ACM is forwarded to the originating End Exchange, ring clipping may occur 😱 If ACM processing in the soft-switch media gateway and delay through the IP network are excessive, the bearer path setup gets delayed, and that may cause the ring tone to be clipped and heard 🎶
The intra-exchange ISUP IAM signaling delay value should not exceed 240ms. This may include soft-switch, media gateway, router, and propagation delay on the inter-exchange data path. This value is the threshold where ring clipping theoretically starts 📍 It's important to note that the 240ms delay objective is a maximum value. Service administrators are free to choose their own IAM delay values according to their preferences (i.e., they may want a very low mean delay objective for strategic reasons, to stand out from other providers) ✨ Summed up, out of the 240ms delay budget, 200ms is allocated as cross-Exchange delay (soft-switch and media gateway) and 40ms for network delay (queuing and distance) 💜
9. References 📚
9.1. Normative References
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[RFC1349] Almquist, P., "Type of Service in the Internet Protocol
Suite", RFC 1349, July 1992.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2309] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering,
S., Estrin, D., Floyd, S., Jacobson, V., Minshall, G.,
Partridge, C., Peterson, L., Ramakrishnan, K., Shenker,
S., Wroclawski, J., and L. Zhang, "Recommendations on
Queue Management and Congestion Avoidance in the
Internet", RFC 2309, April 1998.
[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, December
1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.
[RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
Per-Domain Behavior (PDB) for Differentiated Services",
RFC 3662, December 2003.9.2. Informative References
[AUTHMECH] Rescorla, E., "A Survey of Authentication Mechanisms",
Work in Progress, September 2005.
[QBSS] "QBone Scavenger Service (QBSS) Definition", Internet2
Technical Report Proposed Service Definition, March 2001.
[RFC1633] Braden, R., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC
1633, June 1994.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion
Control", RFC 2581, April 1999.
[RFC2697] Heinanen, J. and R. Guerin, "A Single Rate Three Color
Marker", RFC 2697, September 1999.
[RFC2698] Heinanen, J. and R. Guerin, "A Two Rate Three Color
Marker", RFC 2698, September 1999.
[RFC2963] Bonaventure, O. and S. De Cnodder, "A Rate Adaptive Shaper
for Differentiated Services", RFC 2963, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2996] Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996,
November 2000.
[RFC3086] Nichols, K. and B. Carpenter, "Definition of
Differentiated Services Per Domain Behaviors and Rules for
their Specification", RFC 3086, April 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC
3175, September 2001.
[RFC3290] Bernet, Y., Blake, S., Grossman, D., and A. Smith, "An
Informal Management Model for Diffserv Routers", RFC 3290,
May 2002.
[RFC3782] Floyd, S., Henderson, T., and A. Gurtov, "The NewReno
Modification to TCP's Fast Recovery Algorithm", RFC 3782,
April 2004.Authors' Addresses 🦋
Jozef Babiarz
Nortel Networks
3500 Carling Avenue
Ottawa, Ont. K2H 8E9
Canada
Phone: +1-613-763-6098
Fax: +1-613-765-7462
EMail: babiarz@nortel.com
Kwok Ho Chan
Nortel Networks
600 Technology Park Drive
Billerica, MA 01821
US
Phone: +1-978-288-8175
Fax: +1-978-288-8700
EMail: khchan@nortel.com
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, CA 93117
US
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.comFull Copyright Statement 💖
Copyright (C) The Internet Society (2006). 📜✨
Okay, legal stuff but make it cute 🎀. This document is covered by the rights, licenses and restrictions in BCP 78, and unless BCP 78 says otherwise, the authors keep all of their rights 🦋.
This document and the information in it are provided on an "AS IS" basis, and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 🙈💀
Intellectual Property 🌈
The IETF doesn't take a side on whether any Intellectual Property Rights or other rights might be claimed over the tech in this document, or on how far any license under those rights might or might not be available. It also doesn't say it went out and searched for those rights on its own 🕵️♀️. If you want the procedures for rights in RFC documents, check out BCP 78 and BCP 79 📚.
Copies of IPR disclosures made to the IETF Secretariat, plus any assurances of licenses that will be made available, or the results of an attempt to get a general license or permission for implementers or users of this specification to use those proprietary rights, can be found in the IETF online IPR repository at http://www.ietf.org/ipr 🔍✨.
The IETF also invites anyone who's interested to flag any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💌.
Acknowledgement 🫶
Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💜👑.
📦 where this page comes from
- ietf: rfc4594 2006-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms