RFC 5865
A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic
RFC 5865: A Differentiated Services Code Point (DSCP) for Capacity-Admitted Traffic 💖
okay bestie, title block first! 🎀
- Series: Internet Engineering Task Force (IETF) 🌸
- Request for Comments: 5865 ✨
- Updates: 4542, 4594 🦋
- Category: Standards Track 👑
- ISSN: 2070-1721
- Date: May 2010 📅
- Authors: F. Baker (Cisco Systems), J. Polk (Cisco Systems), M. Dolly (AT&T Labs) 🫶
Abstract
okay so this doc asks IANA for one DSCP 💅 for a class of real-time traffic. That traffic conforms to the Expedited Forwarding PHB, and the network also lets it in through a Call Admission Control (CAC) process that checks authentication, authorization, and capacity. 🔥
Here's the tea: this is different from regular real-time traffic that also follows Expedited Forwarding but either gets no capacity admission at all or only very coarse capacity admission. 🙈
Status of This Memo
this is an Internet Standards Track document ✨
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🌈. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). 💜 If you want more info about Internet Standards, check Section 2 of RFC 5741 📚
for the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc5865 🦋
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀
this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they're in effect on the publication date. Read them carefully, bestie, because they explain your rights and restrictions for this document 📜
any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License. 💻
this document may include material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008 ✨. The people controlling the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. So unless you get an adequate license from those copyright holders, this document may not be modified outside the IETF Standards Process, and derivative works may not be created outside the IETF Standards Process. The one exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌍
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Problem . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Candidate Implementations of the Admitted Telephony
Service Class . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Potential implementations of EF in this model . . . . . . 7
2.2. Capacity admission control . . . . . . . . . . . . . . . 9
2.3. Recommendations on implementation of an Admitted
Telephony Service Class . . . . . . . . . . . . . . . . . 10
3. Summary: changes from RFC 4594 . . . . . . . . . . . . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 131. Introduction ✨
okay so this doc requests one DSCP from IANA for a class of real-time traffic 💖. This class conforms to the Expedited Forwarding (EF) [RFC3246] [RFC3247] PHB. It also gets admitted through a CAC process involving authentication, authorization, and capacity admission 🔐. This is different from a real-time class that follows Expedited Forwarding but isn't subject to capacity admission, or only gets very coarse capacity admission 🌸
the doc also recommends that certain video classes from [RFC4594] be treated as requiring capacity admission 🎬
real-time flows have one or more potential congestion points between the endpoints 🛣️. Reserving capacity for them is important for application performance, and all of these apps have low tolerance to jitter (aka delay variation) and loss, which Section 2 summarizes 😭. Most of them (except multimedia conferencing) have inelastic flow behavior from Figure 1 of [RFC4594]. Inelastic flow behavior plus low jitter/loss tolerance are the service characteristics that make admission control necessary 🔥
one reason for capacity admission is that some traffic classes get handled under special policies 🧚. Service providers need to tell special-policy traffic apart from other classes, especially existing Voice over IP (VoIP) services. Those VoIP services do no capacity admission or only very coarse capacity admission, and they can go over their allocated resources 💀
the requested DSCP applies to the Telephony Service Class described in [RFC4594] 📞
now the video part 🎥. Video classes haven't had the history of mixing admitted and non-admitted traffic in the same Per-Hop Behavior (PHB) the way EF has, so this doc does not recommend an extra DSCP code point for video. Instead, the recommended "best practice" is to do admission control for all traffic in three video classes from [RFC4594]:
- The Interactive Real-Time Traffic (
CS4, used for Video conferencing and Interactive gaming) 🎮, - The Broadcast TV (
CS3) for use in a video on demand context 📺, and - The
AF4Multimedia Conferencing (video conferencing) 💜.
other video classes are believed not to have the current confusion problem with unadmitted traffic, so they wouldn't benefit from a separate DSCP for admitted traffic 🙅♀️. Within an ISP and on inter-ISP links (aka networks whose internal paths are uniform at hundreds of megabits per second or faster), you'd expect all of this traffic to be carried in the Real-Time Traffic (RTP) class described in [RFC5127] 🌈
1.1. Definitions 📖
okay bestie, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in RFC 2119 [RFC2119]. 🎀
here are the terms and acronyms this doc uses, so we're all on the same page ✨
PHB: a Per-Hop Behavior (PHB) is the externally observable forwarding behavior applied at a Differentiated Services compliant node to a DS behavior aggregate [RFC2475]. 🧚 it may be thought of as a program configured on the interface of an Internet host or router, specified in terms of drop probabilities, queuing priorities or rates, and other handling characteristics for the traffic class. it's giving "settings for a traffic class" energy 💜
DSCP: the Differentiated Services Code Point (DSCP), as defined in [RFC2474], is a value that is encoded in the DS field, and that each DS Node MUST use to select the PHB that is to be experienced by each packet it forwards [RFC3260]. 💖 it's a 6-bit number embedded into the 8-bit TOS (type of service) field of an IPv4 datagram or the Traffic Class field of an IPv6 datagram. the DS Node MUST use it, no skipping 🔥
CAC: Call Admission Control includes concepts of authorization and capacity admission. 🫶 "Authorization" refers to any procedure that identifies a user, verifies the authenticity of the identification, and determines whether the user is authorized to use the service under the relevant policy. "Capacity Admission" refers to any procedure that determines whether capacity exists supporting a session's requirements under some policy.
in the Internet these are separate functions, while in the Public Switched Telephone Network (PSTN) they and call routing are carried out together. 🌸 the Internet keeps them apart, the phone network bundles them up. two different vibes, both valid ✨
UNI: a User/Network Interface (UNI) is the interface (often a physical link or its virtual equivalent) that connects two entities that do not trust each other, and in which one (the user) purchases connectivity services from the other (the network). 💅
Figure 1 shows two user networks connected by what appears to each of them to be a single network ("The Internet", access to which is provided by their service provider) that provides connectivity services to other users. 🦋
UNIs tend to be the bottlenecks in the Internet, where users purchase relatively low amounts of bandwidth for cost or service reasons, and as a result are most subject to congestion issues and therefore issues requiring traffic conditioning and service prioritization. 😭 so the UNI is the congested little choke point, lowkey relatable
NNI: a Network/Network Interface (NNI) is the interface (often a physical link or its virtual equivalent) that connects two entities that trust each other within limits, and in which the two are seen as trading services for value. 🌈 Figure 1 shows three service networks that together provide the connectivity services that we call "the Internet". They are different administrations and are very probably in competition, but exchange contracts for connectivity and capacity that enable them to offer specific services to their customers. ⭐
NNIs may not be bottlenecks in the Internet if service providers contractually agree to provision excess capacity at them, as they commonly do. 🍓 however, NNI performance may differ by ISP, and the performance guarantee interval may range from a month to a much shorter period. furthermore, a peering point NNI may not have contractual performance guarantees or may become overloaded under certain conditions. they are also policy-controlled interfaces, especially in BGP. as a result, they may require a traffic prioritization policy. 🙈
Queue: there are multiple ways to build a multi-queue scheduler. 🧁 Weighted Round Robin (WRR) literally builds multiple lists and visits them in a specified order, while a calendar queue (often used to implement Weighted Fair Queuing, or WFQ) builds a list for each time interval and queues at most a stated amount of data in each such list for transmission during that time interval.
while these differ dramatically in implementation, the external difference in behavior is generally negligible when they are properly configured. ✨ consistent with the definitions used in the Differentiated Services Architecture [RFC2475], these are treated as equivalent in this document, and the lists of WRR and the classes of a calendar queue will be referred to uniformly as "queues". 👑
_.--------.
,-'' `--.
,-' `-.
,-------. ,',-------. `.
,' `. ,',' `. `.
/ User \ UNI / / Service \ \
( Network +-----+ Network ) `.
\ / ; \ / :
`. ,' ; `. .+ :
'-------' / '-------' \ NNI \
; \ :
; "The Internet" \ ,-------. :
; +' `. :
UNI: User/Network Interface / Service \ |
| ( Network ) |
NNI: Network/Network Interface \ / |
: +. ,' ;
: / '-------' ;
: / ;
,-------. \ ,-------. / NNI /
,' `. : ,' `+ ;
/ User \ UNI / Service \ ;
( Network +-----+ Network ) ,'
\ / \ \ / /
`. ,' `.`. ,' ,'
'-------' `.'-------' ,'
`-. ,-'
`--. _.-'
`--------''
Figure 1: UNI and NNI Interfaces1.2. Problem 🤔
okay so, in short, the Telephony Service Class, described in [RFC4594], permits the use of capacity admission in implementing the service, but present implementations either provide no capacity admission services or do so in a manner that depends on specific traffic engineering. 🎀 in the context of the Internet backbone, the two are essentially equivalent; the edge network depends on specific engineering by the service provider that might not be present, especially in a mobile environment. the edge is where things get shaky 🥺
however, services are being requested of the network that would specifically make use of capacity admission, and would distinguish among users or the uses of available Voice-over-IP or Video-over-IP capacity in various ways. 💜 various agencies would like to provide services as described in RFC [RFC4190] or in Section 2.6 of [RFC4504].
this requires the use of capacity admission to differentiate among users to provide services to them that are not afforded to non-capacity admitted customer-to-customer IP telephony sessions. 💅✨
2. Candidate Implementations of the Admitted Telephony Service Class 🎀
2.1. Potential Implementations of EF in This Model 🦋
okay so there are at least two ways to build isolation between the Capacity Admitted PHB and the Expedited Forwarding PHB in this model 💅 they're basically two different ways to set up separate classes:
- Multiple data plane traffic classes, each consisting of a policer and a queue, with the queues enjoying different priorities, or
- Multiple data plane traffic classes, each consisting of a policer but feeding into a common queue or multiple queues at the same priority.
we're gonna explain the difference and how each one acts in operation, because there is current confusion in the industry and it's giving chaos 😭 so let's clear it up 🫶
The multi-priority model is shown in Figure 2 🌸 traffic from each service class goes into its own priority queue. If data is sitting in more than one queue, traffic from one of them is always picked for transmission. This basically moves jitter from the higher-priority queue down onto the lower-priority queues, and it reorders traffic so the higher-priority traffic gets a smaller average queuing delay ✨ but each queue still needs its own policer to protect the network from errors and attacks 🛡️ because if a traffic class thinks it's carrying one data rate and an abuse sends way more, plain prioritization would not preserve the lower priorities of traffic. That could cause routing to fail or otherwise impact a service level agreement (SLA) 💀
.
policers priorities |`.
Admitted EF <=> ----------||----+ `.
high| `.
Unadmitted EF <=> ----------||----+ .'-----------
. medium .'
rate queues |`. +-----+ .' Priority
AF1------>||----+ `. / low |' Scheduler
| `. /
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)Figure 2: Implementation as a Data Plane Priority
The multi-policer model is shown in Figure 3 🎀 in this one, traffic from each service class gets policed according to its SLA requirements, and then all of it goes into a common priority queue. Unlike the multi-priority model, the jitter the traffic classes experience is the same, since there's only one queue 🦋 but the total traffic in this higher-priority queue sees less average jitter than the elastic traffic in the lower-priority one 🧚
policers priorities .
Admitted EF <=> -------\ |`.
--||----+ `.
Unadmitted EF <=> -------/ high| `.
. | .'--------
rate queues |`. +-----+ .'
AF1------>||----+ `. / low | .' Priority
| `. / |' Scheduler
AF2------>||----+ .'-+
| .'
CS0------>||----+ .' Rate Scheduler
|' (WFQ, WRR, etc.)Figure 3: Implementation as a Data Plane Policer
Operationally, the two models differ in the issues of loss due to policing and in how jitter gets distributed 👑
Okay now let's talk real-world examples 🎧 if the two traffic classes are, say, voice and video, the video datagrams can be pretty chunky (often variable sizes, up to the path MTU), while voice datagrams are tiny, like only 40 to 200 bytes depending on the codec 🥹 on lower-speed links (less than 10 MBPS), the jitter video adds to voice can be disruptive, but at higher speeds the jitter is nominal compared to what voice needs. So at access network speeds, [RFC4594] recommends separating video and voice into separate queues, while at optical speeds, [RFC5127] recommends they use a common queue 🌈
If, on the other hand, the two traffic classes are carrying the same type of application with the same jitter requirements, then giving one of them preference doesn't actually benefit the higher-priority traffic, and it may harm the lower-priority traffic 🙈 in that case, using separate policers and a common queue is the superior approach 💜
2.2. Capacity Admission Control 🌷
There are at least six major ways that capacity admission is done, or has been proposed to be done, for real-time applications 🍓 each one gets described below, and Section 3 will judge which ones are likely to meet the requirements of the Admitted Telephony service class. The six are:
- Drop Precedence used to force sessions to voluntarily exit,
- Capacity admission control by assumption or engineering,
- Capacity admission control by call counting,
- Endpoint capacity admission performed by probing the network,
- Centralized capacity admission control via bandwidth broker, and
- Distributed capacity admission control using protocols such as Resource Reservation Protocol (RSVP) or Next Steps in Signaling (NSIS).
The problem with dropping traffic to force users to hang up is that it hits a broad class of users 😬 if there's capacity for N calls and N+1 calls are active, data gets dropped randomly from all sessions so offered load doesn't exceed capacity. On very fast links that's acceptable, but on lower-speed links it can seriously wreck call quality 📉 there's also a behavioral issue here: people who get poor-quality calls tend to hang up and call again, which makes the problem better, then worse 🙃
The problem with capacity admission by assumption, which is widely deployed in today's VoIP environment, is that it depends on the assumptions made 🥴 you can do careful traffic engineering to ensure the needed bandwidth, but that can also be painful, and it has to be revisited whenever the network changes or network usage changes.
The problem with call-counting-based admission control is that it gets exponentially worse the farther you get from the control point (for example, it lacks sufficient scalability on the outskirts of the network) 🫠
There are two fundamental problems with depending on the endpoint to perform capacity admission. First, it may not be able to accurately measure the impact of the traffic it generates on the network. Second, it tends to be greedy (it doesn't care, basically) 💅 if the network operator is providing a service, they must be able to guarantee that service, which means they cannot trust systems that aren't controlled by their network 🔒
The problem with capacity controls via a bandwidth broker is that centralized servers lack far-away awareness, and they also lack effective real-time reaction to dynamic changes in all parts of the network at all instances of time 🛰️
The problem with mechanisms that don't enable associating a policy with the request is that they don't allow for multi-policy services, which are becoming important 📚
The operator's choice of admission procedure MUST, for this DSCP, ensure the following:
- The actual links that a session uses have enough bandwidth to support it.
- New sessions are refused admission if there is inadequate bandwidth under the relevant policy.
- A user is identified and the correct policy is applied if multiple policies are in use in a network.
- Under periods of network stress, the process of admission of new sessions does not disrupt existing sessions, unless the service explicitly allows for disruption of calls.
2.3. Recommendations on Implementation of an Admitted Telephony Service Class 🎀
When it's coupled with adequate Authentication, Authorization, and Accounting (AAA) and capacity admission procedures as described in Section 2.2, either of the two PHB implementations described in Section 2.1 is sufficient to provide the services required for an Admitted Telephony service class ✨ if preemption is required, Section 2.3.5.2 of [RFC4542] provides the tools for carrying out the preemption. If preemption isn't in view, or if it's used in addition to preemptive services, applying different thresholds depending on call precedence improves the probability of call completion, because preferred calls get admitted at a time when other calls are being refused 📞 routine and priority traffic can be admitted using the same DSCP value, since the choice of which calls get admitted is handled in the admission procedure executed in the control plane, not in the policing of the data plane 🧠
On the question of which protocols and procedures are required for authentication, authorization, and capacity admission, we note that clear standards don't exist yet for bandwidth brokers 🙅♀️ NSIS has not been finalized at this time, and in any event it's limited to unicast sessions 🫤 meanwhile RSVP has been standardized and has the relevant services. So we RECOMMEND the use of a protocol, such as RSVP, at the UNI 💖 procedures at the NNI are business matters to be discussed between the relevant networks, and they are RECOMMENDED but NOT REQUIRED 🤝
3. Summary: Changes from RFC 4594 🌈
To summarize, there are two changes to [RFC4594] discussed in this document 🍰
- Telephony class: The Telephony Service Class in RFC 4594 does not involve capacity admission. It depends on application layer admission that only estimates capacity, and it does that through static engineering. In addition to that class, a separate Admitted Telephony Class is added that performs capacity admission dynamically ⭐
- Video classes: Capacity admission is added to three video classes. These are the Interactive Real-Time Traffic class, the Broadcast TV class when used for video on demand, and the Multimedia Conferencing class 📺
4. IANA Considerations 👑
IANA assigned a DSCP value to a second EF traffic class, consistent with [RFC3246] and [RFC3247], in the "Differentiated Services Field Codepoints" registry 🦋 it implements the Telephony Service Class described in [RFC4594] at lower speeds, and it's included in the Real-Time Treatment Aggregate [RFC5127] at higher speeds. The code point value should be from pool 1 within the dscp-registry. The value is parallel with the existing EF code point (101110), since IANA assigned the code point 101100 -- keeping the (left-to-right) first 4 binary values the same in both 🔢 the code point described in this document is referred to as VOICE-ADMIT, and it has been registered as follows 💅
Sub-registry: Pool 1 Codepoints
Reference: [RFC2474]
Registration Procedures: Standards Action
Registry:
Name Space Reference
--------- ------- ---------
VOICE-ADMIT 101100 [RFC5865]This traffic class REQUIRES the use of capacity admission, such as RSVP services together with AAA services, at the User/Network Interface (UNI) 🔐 the use of such services at the NNI is at the option of the interconnected networks 🫶
5. Security Considerations 🔐
okay so bestie, this section is SERIOUS but make it cute 🎀. A major requirement of this service is effective use of a signaling protocol, such as RSVP, with the capabilities to identify its user as either an individual or a member of some corporate entity, and assert a policy such as "normal", "routine", or some level of "priority". 💅 Basically the signaling has to be able to tell who's asking, whether that's a person or a company, and say what kind of priority they're claiming. Main character energy, but make it accountable 😤
This capability, one has to believe, will be abused by script kiddies and others if the proof of identity is not adequately strong or if policies are written or implemented improperly by the carriers. 💀 Lowkey terrifying, no cap. This goes without saying, but this section is here for it to be said. 🙈 Consider it said!! 🫶
Many of the security considerations from RFC 3246 [RFC3246] apply to this document, as well as the security considerations in RFC 2474 and RFC 4542. 🌈 Go read those too, they're giving important vibes ✨ RFC 4230 [RFC4230] analyzes RSVP, providing some gap analysis to the NSIS WG as they started their work. 🦋 Keep in mind that this document is advocating RSVP at the UNI only, while RFC 4230 discusses (mostly) RSVP from a more complete point of view (i.e., e2e and edge2edge). 💜 When considering the RSVP aspect of this document, understanding Section 6 of RFC 4230 is a good source of information. 🧚
6. Acknowledgements 🫶
Kwok Ho Chan, Georgios Karagiannis, Dan Voce, and Bob Briscoe commented and offered text. 👑 The impetus for including video in the discussion, which initially only targeted voice, is from Dave McDysan. 🍓 Shoutout to them, they're iconic!! ✨
7. References 📚
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC3246] Davie, B., Charny, A., Bennet, J., Benson, K., Le Boudec,
J., Courtney, W., Davari, S., Firoiu, V., and D.
Stiliadis, "An Expedited Forwarding PHB (Per-Hop
Behavior)", RFC 3246, March 2002.7.2. Informative References
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.,
and W. Weiss, "An Architecture for Differentiated
Service", RFC 2475, December 1998.
[RFC3247] Charny, A., Bennet, J., Benson, K., Boudec, J., Chiu, A.,
Courtney, W., Davari, S., Firoiu, V., Kalmanek, C., and K.
Ramakrishnan, "Supplemental Information for the New
Definition of the EF PHB (Expedited Forwarding Per-Hop
Behavior)", RFC 3247, March 2002.
[RFC3260] Grossman, D., "New Terminology and Clarifications for
Diffserv", RFC 3260, April 2002.
[RFC4190] Carlberg, K., Brown, I., and C. Beard, "Framework for
Supporting Emergency Telecommunications Service (ETS) in
IP Telephony", RFC 4190, November 2005.
[RFC4504] Sinnreich, H., Ed., Lass, S., and C. Stredicke, "SIP
Telephony Device Requirements and Configuration", RFC
4504, May 2006.
[RFC4542] Baker, F. and J. Polk, "Implementing an Emergency
Telecommunications Service (ETS) for Real-Time Services in
the Internet Protocol Suite", RFC 4542, May 2006.
[RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration
Guidelines for DiffServ Service Classes", RFC 4594, August
2006.
[RFC5127] Chan, K., Babiarz, J., and F. Baker, "Aggregation of
DiffServ Service Classes", RFC 5127, February 2008.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005.Authors' Addresses 📮
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
Phone: +1-408-526-4257 EMail: fred@cisco.com
James Polk Cisco Systems Richardson, Texas 75082 USA
Phone: +1-817-271-3552 EMail: jmpolk@cisco.com
Martin Dolly AT&T Labs Middletown Township, New Jersey 07748 USA
Phone: +1-732-420-4574 EMail: mdolly@att.com 💖
📦 where this page comes from
- ietf: rfc5865 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms