RFC 4542
Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite
RFC 4542 💖 (Part 1 of 10)
Title block: this is RFC 4542, titled Implementing an Emergency Telecommunications Service (ETS) for Real-Time Services in the Internet Protocol Suite ✨. It's from May 2006 and was written by F. Baker and J. Polk of Cisco Systems. The category is Informational 🎀. The header doesn't list anything it obsoletes or updates, so it doesn't replace or change any earlier RFC 🧚.
Status of This Memo 🌸
This memo gives info to the Internet community. It is not an Internet standard of any kind, and it's free to distribute with no limits 💅.
Copyright Notice 🦋
Copyright (C) The Internet Society (2006).
Abstract 💜
Okay so, [RFC3689] and [RFC3690] lay out what an Emergency Telecommunications Service (ETS) needs to do, and an Internet Emergency Preparedness Service (IEPS) would be part of that 🔥. Some of these services need call preemption, which means kicking off a lower-priority call to make room. Others just queue calls or use other tricks 🙈. For IEPS, you need a Call Admission Control (CAC) procedure and a Per Hop Behavior (PHB) for the data, and that's what this architecture is about. Any service that uses H.323 or SIP to set up real-time sessions can use this CAC procedure and PHB 👑. The big goal is to guarantee an authorized user a much better chance of finishing a call during a crisis 😭🫶.
This document mostly talks about ETS in the context of the US Government and NATO, since it's built around the Multi-Level Precedence and Preemption (MLPP) and Government Emergency Telecommunication Service (GETS) standards 🌈. But the architectures here aren't limited to those organizations, so they apply more widely ⭐.
Table of Contents 🍓
1. Overview of the Internet Emergency Preference Service
Problem and Proposed Solutions ..................................3
1.1. Emergency Telecommunications Services ......................3
1.1.1. Multi-Level Preemption and Precedence ...............4
1.1.2. Government Emergency Telecommunication Service .....6
1.2. Definition of Call Admission ...............................6
1.3. Assumptions about the Network ..............................7
1.4. Assumptions about Application Behavior .....................7
1.5. Desired Characteristics in an Internet Environment .........9
1.6. The Use of Bandwidth as a Solution for QoS ................10
2. Solution Proposal ..............................................11
2.1. Call Admission/Preemption Procedure .......................12
2.2. Voice Handling Characteristics ............................15
2.3. Bandwidth Admission Procedure .............................17
2.3.1. RSVP Admission Using Policy for Both
Unicast and Multicast Sessions .....................17
2.3.2. RSVP Scaling Issues ................................19
2.3.3. RSVP Operation in Backbones and Virtual
Private Networks (VPNs) ............................19
2.3.4. Interaction with the Differentiated
Services Architecture ..............................21
2.3.5. Admission Policy ...................................21
2.4. Authentication and Authorization of Calls Placed ..........23
2.5. Defined User Interface ....................................23
3. Security Considerations ........................................24
4. Acknowledgements ...............................................24
5. References .....................................................25
5.1. Normative References ......................................25
5.2. Informative References ....................................27
Appendix A. 2-Call Preemption Example using RSVP .................291. Overview of the Internet Emergency Preference Service Problem and Proposed Solutions 🎀
Okay, bestie, the setup: [RFC3689] and [RFC3690] describe what an Emergency Telecommunications Service (ETS) needs, and an Internet Emergency Preference Service (IEPS) would be one piece of it 💅. Some of these services need call preemption, and others need call queuing or something else ✨. The key point is still the same: an authorized user needs a much higher chance of call completion during a crisis 🫶.
IEPS needs a Call Admission Control procedure and a Per Hop Behavior for the data that fits this architecture 🦋. That CAC procedure and PHB work for any service that uses H.323 or SIP to set up real-time sessions 💜. That obviously includes Voice and Video, though right now the community is mostly thinking about Voice on IP, so a lot of the examples come from there 🎧.
Here's the deal with admission. If a network never denies or rejects a call it already accepted, then admission checks done only at call setup might be enough 🌸. But if the network can review a session's status and preempt or deny it later, that changes things 😭. That can happen when routing changes leave the new routes without enough capacity for the calls moved onto them, or when the offered load changes and higher-precedence calls push out existing ones 🔥. In that case, the network has to keep an ongoing model of where each call stands 👑.
1.1. Emergency Telecommunications Services 🌈
Before we get into the solution, let's talk about the problem ETS (and therefore IEPS) is meant to solve, and how the system is set up 🧚. The Emergency Telecommunications Service [ITU.ETS.E106] is the successor to, and a generalization of, two US services: Multi-Level Precedence and Preemption (MLPP) and the Government Emergency Telecommunication Service (GETS) ⭐. Services built on these models are used in lots of countries around the world, on both the Public Switched Telephone Network (PSTN) and Global System for Mobile Communications (GSM) networks 🌍. Both are designed so an authorized user can get service from the telephone network during a crisis 💖. The main differences are the mechanisms they use and how many precedence levels they recognize 🍓.
1.1.1. Multi-Level Preemption and Precedence 💅
The Assured Service is an IP version of an existing ITU-T/NATO/DoD telephone architecture called Multi-Level Precedence and Preemption [ITU.MLPP.1990] [ANSI.MLPP.Spec] [ANSI.MLPP.Supp], or MLPP 🔥. MLPP is a prioritized call handling system. In emergencies, within the relevant NATO and DoD commands, it strictly defines how important different kinds of communication are, so higher-precedence traffic can win over lower-precedence traffic 👑. This document covers NATO and US Department of Defense uses of MLPP, but the architecture and standard also apply outside those organizations 🌸.
Here are the precedence levels, from highest to lowest 🎀:
- Flash Override Override: used by the Commander in Chief, the Secretary of Defense, and the Joint Chiefs of Staff, and by commanders of combatant commands when they declare that a state of war exists 💀. It's also used by commanders of combatant commands when they declare Defense Condition One, Defense Emergency, or Air Defense Emergency, and by other national authorities the President may authorize, in conjunction with Worldwide Secure Voice Conferencing System conferences 🫶. Flash Override Override cannot be preempted. This level isn't enabled on all DoD networks 🙈.
- Flash Override: used by the Commander in Chief, the Secretary of Defense, and the Joint Chiefs of Staff, and by commanders of combatant commands when they declare that a state of war exists 👑. It's also used for Defense Condition One, Defense Emergency, and other national authorities the President may authorize 🔥. Flash Override cannot be preempted in the DSN.
- Flash: generally reserved for calls about command and control of military forces essential to defense and retaliation 🛡️. It also covers critical intelligence essential to national survival, diplomatic negotiations critical to arresting or limiting hostilities, and critical civil alert information essential to national survival 🌈. It further includes continuity of federal government functions essential to national survival, critical internal security functions essential to national survival, and catastrophic events of national or international significance 💜.
- Immediate: generally reserved for calls about situations that gravely affect the security of national and allied forces 😭. It also covers reconstituting forces after an attack, intelligence essential to national security, and diplomatic negotiations to reduce or limit the threat of war 🧚. Other examples are federal government actions essential to national survival, situations that gravely affect the nation's internal security, and Civil Defense actions 🌸. It includes disasters or events of extensive seriousness with an immediate, detrimental effect on the population's welfare, and vital information with an immediate effect on aircraft, spacecraft, or missile operations ✨.
- Priority: generally reserved for calls that need quick action from the called parties, or that provide essential information for running government operations 🍓.
- Routine: the label for official government communications that need rapid transmission by telephone but don't need preferential handling 🦋.
MLPP is meant to give more important calls a higher chance of getting through 💖. The rule is simple: when congestion happens inside a network, more important calls override less important ones 🔥. Station-based preemption is used when a more important call needs to reach either party in an existing call 📞. Trunk-based preemption is used when trunk bandwidth has to be reallocated so a higher-precedence call can use a given path in the network 🛤️. In both station-based and trunk-based preemption, the preempted parties are positively notified with a preemption tone that their call can no longer be supported 😭. The same preemption tone is used whether the call is ended for station-based or trunk-based preemption 🎀. The rest of this discussion focuses on trunk-based preemption issues 💅.
MLPP is a proactive system. Callers must assign one of the precedence levels above when they start a call, and that level can't change during the call 💜. If a user doesn't assign an elevated level when starting the call, the call is assumed to be "routine" 🌸. If there's end-to-end capacity, any call can be placed at any time 🌈. But when a trunk group (in the circuit world) or an interface (in the IP world) reaches a utilization threshold, someone has to decide which calls to accept or let continue 👑. The system will seize the trunk(s) or bandwidth needed for the more important calls, ahead of less important ones, by preempting one or more existing lower-precedence calls so a higher-precedence call can be placed 🔥.
More than one call might have to be preempted if the higher-precedence call needs more trunks or bandwidth 🧚. A video call (perhaps 384 KBPS, or 6 trunks) competing with several lower-precedence voice calls is a perfect example 🎥✨.
(More parts follow, babe. Stay tuned for Part 2 🦋💖)
1.1.2. Government Emergency Telecommunications Service 🇺🇸🎀
Okay bestie, this one is basically MLPP's cousin 💅. It's the Government Emergency Telecommunications Service (GETS), a US service built for civilian networks that still uses MLPP signaling tech 📡. It's different in two big ways. First, it skips preemption entirely 🙅♀️ and instead reserves bandwidth or queues calls so the call is highly likely to actually connect 📞. Second, it only has two levels: "Routine" and "Priority" 🍓. Iconic simplicity.
GETS is just here as an example 🧚. Other governments and organizations use similar architectures too 🌍.
1.2. Definition of Call Admission
Okay so traditionally, in the PSTN, Call Admission Control (CAC) has been in charge of two things 👑. One, enforcing bandwidth available thresholds (for example, limiting the resources some traffic can eat 🍽️). Two, checking whether a caller actually has permission to use an available circuit (like being an identified subscriber, with that identity backed up by appropriate credentials 🔐). IEPS, or any emergency telephone service, has some extra moves it can pull to boost the odds of a call going through 💖:
- The call may be authorized to use other networks that it would not normally use;
- The network may preempt other calls to free bandwidth;
- The network may hold the call and place it when other calls complete; or
- The network may use different bandwidth availability thresholds than are used for other calls.
Here's the tea 🫶. At the end of CAC, the caller either has a circuit they're authorized to use or they have no circuit at all 💀. Preemption and looking at alternative bandwidth sources are part and parcel of providing bandwidth, so the authorization step also decides which networks are even allowed to be considered. The three are literally inseparable 🔗. CAC finds available bandwidth that the caller is authorized to use, and in some networks, preemption may be part of making that happen ✨.
1.3. Assumptions about the Network
IP networks generally fall into two buckets: ones with constrained bandwidth, and ones that are massively over-provisioned 🦋. In a network where, over any interval you can measure (even sub-second intervals), capacity exceeds offered load by at least 2:1, the jitter and loss in transit are nominal 😌. This is generally true of properly engineered Ethernet LANs and of optical networks (networks that measure their link speeds in multiples of 51 MBPS) 🌈. For optical networks, circuit-switched solutions such as Asynchronous Transfer Mode (ATM), MPLS, and GMPLS can be used to explicitly place routes, which improves the odds a bit 🎯.
Between those networks, in places commonly called "inter-campus links", "access links", or "access networks", it's common to find links whose offered load can approximate or exceed the available capacity 😬. This happens for various reasons, including technology (like satellite links) and cost. These events may be momentary or may last for extended periods of time ⏳.
Also, mainly in tactical deployments, bandwidth constraints show up a lot in the local infrastructure of networks 🪖. For example, the US Navy's network afloat connects approximately 300 ships, via satellite, to five network operation centers (NOCs). Those NOCs are then interconnected via the Defense Information Systems Agency (DISA) backbone 🛰️. A typical ship may have between two and six radio systems aboard, often at speeds of 64 KBPS or less. In US Army networks, current radio technology likewise limits tactical communications to links below 100 KBPS 📻.
Over this infrastructure, military communications expect to deploy voice systems (30-80 KBPS per session) and video conferencing using MPEG 2 (3-7 MBPS) and MPEG 4 (80 KBPS to 800 KBPS) 🎥. On top of that, there's the usual mail, file transfer, and transaction traffic 📬.
1.4. Assumptions about Application Behavior
Parekh and Gallagher published a series of papers [Parekh1] [Parekh2] analyzing what's needed to ensure a specified service level for a stream of traffic 📚. The big takeaway? To predict how a stream of traffic will behave in a network, you need to know two things 🧠:
- the rate and arrival distribution with which traffic in a class is introduced to the network, and
- what network elements will do, in terms of the departure distribution, injected delay jitter, and loss characteristics, with the traffic they see.
For example, TCP tunes its effective window (the amount of data it sends per round trip interval) so that the ratio of the window to the round trip interval approximates the available capacity in the network 🏄♀️. As long as round trip delay stays roughly stable and loss is nominal (which are mostly behaviors of the network), TCP keeps a predictable level of throughput ✅. But if loss is random or delays wildly vary, TCP gets way less predictable 🙃.
Voice and video systems, for the most part, are designed to deliver a fixed level of quality as the user perceives it 🎤. (The exceptions are systems that pick rate options across a broad range to adapt to ambient loss. These have broadly fluctuating perceived quality and haven't found much commercial success 🤷♀️.) Instead, they send traffic at a rate the codec chooses based on what it thinks is needed. In an MPEG-4 system, for instance, if the camera is pointed at a wall, the codec decides an 80 KBPS data stream will describe that wall and sends that much traffic. If a person walks in front of the wall, or the camera is pointed at a moving object, the codec may easily send 800 KBPS to accurately describe what it sees 🏃♀️. In commercial sports broadcasts, which may line up periods where advertisements are displayed, traffic rates suddenly jump across all channels at certain times. Eye-catching ads need way more bandwidth than the camera pointed at the green football field 🏈💅.
As described in [RFC1633], when you're dealing with a real-time application, there are basically two things you must do to ensure Parekh's first requirement 🔑. First, to know how much offered load the application is presenting, you must police traffic entering the network (measure the load offered and discard the excess) 🚧. If that policing has a debilitating effect on the application, the way non-negligible loss does for voice or video, you must admit sessions judiciously according to some policy 🚪. A key characteristic of that policy must be that the offered load does not exceed the capacity dedicated to the application 💯.
Inside the network, the other thing you must do is make sure the application's needs are met in terms of loss, variation in delay, and end-to-end delay 🌐. One way to do this is to supply sufficient bandwidth so loss and jitter are nominal. Where that can't be accomplished, you must use queuing technology to deterministically apply bandwidth to hit the goal 🎯.
1.5. Desired Characteristics in an Internet Environment
Okay so the key elements of the Internet Emergency Preference Service include the following 💖:
- Precedence Level Marking each call: Call initiators choose the appropriate precedence level for each call based on how important the call is to the user. This level is not to be changed for the duration of the call. The call before and the call after are independent with regard to this level choice 🏷️.
- Call Admission/Preemption Policy: There is likewise a clear policy about calls that may already be in progress at the called instrument. During call admission (SIP/H.323), if they are of lower precedence, they must make way according to a prescribed procedure. All callers on the preempted call must be informed that the call has been preempted, and the call must make way for the higher-precedence call 🙋♀️.
- Bandwidth Admission Policy: There is a clear bandwidth admission policy. Sessions may be placed that assert any of several levels of precedence. If there's demand and authorization is granted, other sessions will be preempted to make way for a call of higher precedence 📶.
- Authentication and Authorization of calls placed: Unauthorized attempts to place a call at an elevated status are not permitted 🚫. In the telephone system, this is managed by controlling the policy applied to an instrument by its switch, plus a code the caller produces to identify themselves to the switch. On the Internet, such characteristics must be explicitly signaled 🔐.
- Voice handling characteristics: In the telephone system, a call gets a circuit and gives the callers the means to conduct their business without significant impact, as long as the call is not preempted. In a VoIP system, one would hope for essentially the same service 📞🥰.
- Defined User Interface: If a call is preempted, the caller and the callee are notified via a defined signal. That way they know their call has been preempted and that, at this instant, there is no alternative circuit available to them at that precedence level 🔔.
A VoIP implementation of the Internet Emergency Preference Service must, by definition, provide those characteristics 🫶✨.
1.6. The Use of Bandwidth as a Solution for QoS
Okay so there's a whole debate in internet circles about how bandwidth relates to QoS, and it needs to be put to bed 🛏️ before we can properly analyze this procedure. Here's the tea: in lots of parts of the internet, bandwidth can solve the problem all by itself 💅. On a LAN, if there's significant loss between two switches or between a switch and a server, the simplest and cheapest fix is to buy the next faster interface: swap 10 MBPS Ethernet for 100 MBPS, 100 MBPS for 1 gigabit, or even jump straight to 10-gigabit Ethernet 🚀. Optical networks work the same way, where the simplest and cheapest move is often to raise the data rate of the optical path, either by picking a faster optical carrier or by deploying an additional lambda ✨.
Where bandwidth can be over-provisioned to the point that loss or queuing delay is negligible, 10:1 over-provisioning is often the cheapest and surest move, and it also gives you a growth path for future requirements 🌱. However, there are many places in communication networks where effectively infinite bandwidth just isn't feasible: many access networks, satellite communications, fixed wireless, airborne and marine communications, island connections, and connections to regions where fiber optic links aren't cost-effective 🥺. That's exactly where resource management matters.
Specifically, we do not recommend deploying significant QoS procedures on links faster than 100 MBPS, except for aggregated services that provide specific protection to the stability of the network or the continuity of real-time traffic as a class 🎀. The reason is that the mathematics of such circuits doesn't support this as a requirement 🧮.
In short, the fact that we're talking about this class of policy control means those constraints really exist in the network and must be dealt with. As much as we might like to, in those places we are not solving the problem with bandwidth 💖.
2. Solution Proposal ✨
A typical voice or video network, including a backbone domain, is shown in Figure 1 👇
............... ......................
. . . .
. H H H H . . H H H H .
. /----------/ . . /----------/ .
. R SIP . . R R .
. \ . . / \ .
. R H H H . ....... / \ .
. /----------/ .. ../ R SIP .
. R .. /. /----------/ .
..... ..\. R-----R . H H H H .
...... .\ / \ . .
. \ / \ . .
. R-----------R ....................
. \ / .
. \ / .
. R-----R .
. .
............
SIP = SIP Proxy
H = SIP-enabled Host (Telephone, call gateway or PC)
R = Router
/---/ = Ethernet or Ethernet Switch
Figure 1: Typical VoIP or Video/IP NetworkLooking at the figure, it becomes obvious that Voice/IP and Video/IP call flows are very different from call flows in the PSTN 🤯. In the PSTN, call control traverses a switch, which in turn controls data handling services like ATM or Time Division Multiplexing (TDM) switches or multiplexers. Even if they aren't physically co-located, the control plane software and the data plane services are closely connected: the switch routes a call using bandwidth it knows is available 📞. In a voice/video-on-IP network, though, call control is completely divorced from the data plane. A telephone instrument in the United States can have a Swedish telephone number if that's where its SIP proxy happens to be, but on any given call, it could be using only data paths in the Asia/Pacific region, data paths provided by a different company, and often data paths provided by multiple companies/providers 🌏.
So call management has to answer a whole bunch of questions, and all of them must be answered 👑:
- May I make this call from an administrative policy perspective? Am I authorized to make this call? 🛂
- What IP address correlates with this telephone number or SIP URI? 🔍
- Is the other instrument "on hook"? If it is busy, under what circumstances may I interrupt? 📵
- Is there bandwidth available to support the call? 📶
- Does the call actually work, or do other impairments (loss, delay) make the call unusable? 😭
2.1. Call Admission/Preemption Procedure ✨
okay so Administrative Call Admission is the whole goal of SIP and H.323 🎀 It's basically asking the big questions, like "What IP address is the callee at?" and "Did you pay your bill?" 💅
For a specialized policy like call preemption, you need two capabilities from an administrative point of view. [RFC4412] gives you a way to pass along policy info about the precedence of the call 🔥 and [RFC4411] gives you a reason code when a call fails or gets refused, so everyone knows what actually happened 🙈 If it's a failure, redialing might make sense. If it's a policy-driven preemption though, even if you redial, the call may still not go through 💀 The requirements for all of this get dug into more in [RFC3689].
The SIP Communications Resource Priority Header (aka the RP Header) carries the precedence level the call initiator picked into the setup process 🦋 The syntax looks like this:
Resource Priority: namespace.priority levelThe "namespace" part tells everyone which domain of significance the originator belongs to, and it travels end-to-end all the way to the destination (called) device (telephone) ✨ If the receiving phone doesn't support the namespace, it can just ignore the setup request, no drama 🫶 Being able to show the domain of origin is also what lets Service Level Agreements (SLAs) limit how an unknown requester can get preferential treatment into an IEPS domain. Very protective, very iconic 👑
For the DSN infrastructure, the header for a routine precedence level call would look like this 🍓
Resource Priority: dsn.routineThe precedence level in this header gets checked against the requester's authorization profile to see if they're allowed to use it 🧚 This usually happens at the SIP first-hop Proxy, which can challenge lots of stuff in the call setup request, including the requester's choice of precedence levels (it checks they aren't using a level they aren't authorized to use). Main character gatekeeping energy 💅
The DSN has 5 precedence levels of IEPS, in descending order:
dsn.flash-override
dsn.flash
dsn.immediate
dsn.priority
dsn.routineThen there's the US Defense Red Switched Network (DRSN), which was IANA-registered in [RFC4412] as another example. It has 6 levels of precedence 🌈 The DRSN just adds one level higher than flash-override, reserved for the President and a select few others:
drsn.flash-override-overrideNote that the namespace changed for this level. The lower 5 levels within the DRSN also use this as their namespace for all DRSN-originated call setup requests 💜
The Resource-Priority Header (RPH) does two jobs. It informs the use of Differentiated Services Code Points (DSCPs) by the callee, who needs to use the same DSCP as the caller to get the same data path service 🌸 It also helps with policy-based preemption of calls in progress, when appropriate ⭐
Once a call is established in an IEPS domain, the Reason Header for Preemption (described in [RFC4411]) makes sure all SIP nodes are synced up on a preemption event, whether it happened at the endpoint or in a router that's experiencing congestion 😭 In SIP, the normal way to signal the end of a session is for one end system to send a BYE Method request, as specified in [RFC3261]. That's also the proper move for signaling a call termination due to preemption, because it's basically a normal termination with extra info telling the peer why the call ended so abruptly: a preemption occurred 🎀 This gets used to inform all the relevant SIP entities, and it says whether the preemption was endpoint-generated or happened inside a router along the communications path (described in Section 2.3.1). Iykyk 🧚
Figure 2 is a simple example of a SIP call setup that includes the layer 7 precedence of a call between Alice and Bob 🦋 Alice successfully sets up a call to Bob at the "Routine" precedence level. Then Carol calls Bob at a higher precedence level (Immediate). Quick note: this is all at the SIP layer, so it has nothing to do with RSVP yet. The example involving SIP and RSVP signaling is in the appendix 🙈 Once Bob's user agent (phone) gets the INVITE message from Carol, his UA has to choose between keeping the call to Alice and sending Carol a "busy" indication, or preempting the call to Alice so it can accept Carol's call instead. In IEPS networks, that choice comes down to comparing Resource Priority headers ✨ Alice set the precedence level of her call to Bob at "Routine" (the lowest level in the network). Carol set her priority level to "Immediate" (higher than "Routine") 🔥 So under IEPS policy, Bob's UA needs to preempt Alice's call and give her a preemption indication in the call termination message. And Bob needs to successfully answer Carol's call setup 💖
UA Alice UA Bob UA Carol
| INVITE (RP: Routine) | |
|--------------------------->| |
| 200 OK | |
|<---------------------------| |
| ACK | |
|--------------------------->| |
| RTP | |
|<==========================>| |
| | |
| | INVITE (RP: Immediate) |
| |<----------------------------|
| ************************************************ |
| *Resource Priority value comparison by Bob's UA* |
| ************************************************ |
| | |
| BYE (Reason: UA preemption) |
|<---------------------------| |
| | 200 OK |
| |---------------------------->|
| 200 OK (BYE) | |
|--------------------------->| |
| | ACK |
| |<----------------------------|
| | RTP |
| |<===========================>|
| | |Figure 2: Priority Call Establishment and Termination at SIP Layer
Nothing in this example involved mechanisms other than SIP 🌈 It's also assumed that each user agent recognized the Resource-Priority header namespace value in each message. So the domain is assumed to have allowed Alice, Bob, and Carol to communicate 🫶 Authentication and Authorization get discussed later in this document 👑
2.2. Voice Handling Characteristics 🎀
The Quality of Service architecture used in the data path is the one from [RFC2475] 💅 Differentiated Services uses a flag in the IP header called the DSCP [RFC2474] to identify a data stream, and then applies a procedure called a Per Hop Behavior, or PHB, to it. This is mostly as described in [RFC2998] ✨
In the data path, the Expedited Forwarding PHB [RFC3246] [RFC3247] describes the basic needs of voice and video traffic 🦋 This PHB means making sure enough bandwidth is dedicated to real-time traffic so that variation in delay and loss rate stay minimal, since codecs get hampered by excessive loss [G711.1] [G711.3] 😭 In parts of the network where bandwidth is heavily over-provisioned, there may be no remaining concern 🌸 In places where bandwidth is more constrained, you may need a priority queue. If you use a priority queue, there's potential for abuse, so you also need to police the traffic placed into the queue to detect and manage that abuse 💀 A big question is "where does this policing need to take place?" The obvious spots are the first-hop routers and any place where converging data streams might congest a link 🙈
Some proposals mark traffic with various code points that match the service precedence of the call 🍓 In normal service, if all the traffic is in the same queue and the EF service requirements are met (applied capacity exceeds offered load, variation in delay is minimal, and loss is negligible), details of traffic marking should be irrelevant, as long as packets get into the right service class 🧚 Then the major issues are appropriate policing of traffic, especially around route changes, and making sure the path has sufficient capacity 💖
The real-time voice/video application should be generating traffic at a rate that fits its content and codec, which is either a constant bit rate stream or a stream whose rate varies within a specified range 💜 The first-hop router should be policing traffic originated by the application, the same way traditional virtual circuit networks like Frame Relay and ATM do it ⭐ Between these two checks (at what some networks call the Data Terminal Equipment (DTE) and Data Communications Equipment (DCE)), application traffic should be guaranteed to stay within acceptable limits 🔥 So, given bandwidth-aware call admission control, there should be minimal actual loss ✨ Loss could still happen where routing has recently changed and CAC hasn't caught up, or where statistical thresholds are in use in CAC and the data streams happen to coincide at their peak rates 😭
If it's demonstrated that routing transients and variable rate beat frequencies are a sufficient problem, it's possible to provide a policing mechanism that isolates intentional loss among an ordered set of classes 🎀 Lowkey, the ability to do this, by various algorithms, has been demonstrated, but the technical requirement has not 🙈 If dropping random packets from all calls isn't appropriate, concentrating random loss in a subset of the calls makes things worse for those calls. A superior approach would reject or preempt an entire call instead 🫶
Parekh's second condition has been met: we must know what the network will do with the traffic 🌈 If the offered load exceeds the available bandwidth, the network will remark and drop the excess traffic. So the key questions become "How does one limit offered load to a rate less than or equal to available bandwidth?" and "How much traffic does one admit with each appropriate marking?" 🧚 Honestly, these are the questions I'm obsessed with 💅✨
2.3. Bandwidth Admission Procedure ✨
Okay so bestie, lots of voice and video codecs need a nominal loss rate to perform nicely 🎀, which is why Parekh's first requirement is that offered load has to be within the available capacity. 💅 There are a few ways to get there.
One approach that's commonly used in H.323 networks is to limit the number of calls the gatekeeper accepts at the same time. SIP networks kinda do something similar when they place a stateful SIP proxy near a single ingress/egress of the network. This can put an upper bound on the total number of calls in the network or on the total number of calls crossing the significant link. BUT ngl, the gatekeeper has no knowledge of routing, so the engineering has to be super conservative and usually assumes a single ingress/egress or the failure of one of its data paths. 😭 This can work as a short-term work-around, but it's not a general solution that's readily deployed, and it limits the options in network design. 🙈
[RFC1633] provides for signaled admission for the use of capacity. The recommended approach is explicit capacity admission, supporting the concepts of preemption. An example of such a procedure uses the Resource Reservation Protocol [RFC2205] [RFC2209] (RSVP). The use of Capacity Admission using RSVP with SIP is described in [RFC3312]. While call counting is specified in H.323, network capacity admission is not integrated with H.323 at this time. 🦋
2.3.1. RSVP Admission Using Policy for Both Unicast and Multicast Sessions
RSVP is a resource reservation setup protocol that gives you the one-way (at a time) setup of resource reservations for multicast and unicast flows. 🌸 Each reservation is set up in one direction (meaning one reservation from each end system; in a multicast environment, N senders set up N reservations). These reservations complete a communication path with a deterministic bandwidth allocation through each router along that path between end systems. They set up a known quality of service for end-to-end communications and maintain a "soft-state" within a node. The meaning of "soft state" is that in the event of a network outage or change of routing, these reservations are cleared without manual intervention, but they must be periodically refreshed. In RSVP, the refresh period is by default 30 seconds, but it may be as long as is appropriate. ⭐
RSVP is a locally-oriented process, not a globally- or domain-oriented one like a routing protocol or H.323 Call Counting. 💜 Although it uses the local routing databases to determine the routing path, it's only concerned with the quality of service for a particular or aggregate flow through a device. RSVP isn't aware of anything other than the local goal of QoS and its RSVP-enabled adjacencies, operating below the network layer. The process by itself neither requires nor has any end-to-end network knowledge or state. So RSVP can be effective when it's enabled at some nodes in a network without needing every node to participate. It's giving independent, main character energy 👑
Here's the diagram from the spec (Figure 3) showing how RSVP lives inside hosts and routers:
HOST ROUTER
_____________________________ ____________________________
| _______ | | |
| | | _______ | | _______ |
| |Appli- | | | |RSVP | | | |
| | cation| | RSVP <---------------------------> RSVP <---------->
| | <--> | | | _______ | | |
| | | |process| _____ | ||Routing| |process| _____ |
| |_._____| | -->Policy| || <--> -->Policy||
| | |__.__._| |Cntrl|| ||process| |__.__._| |Cntrl||
| |data | | |_____|| ||__.____| | | |_____||
|===|===========|==|==========| |===|==========|==|==========|
| | --------| | _____ | | | --------| | _____ |
| | | | ---->Admis|| | | | | ---->Admis||
| _V__V_ ___V____ |Cntrl|| | _V__V_ __V_____ |Cntrl||
| | | | | |_____|| | | | | ||_____||
| |Class-| | Packet | | | |Class-| | Packet | |
| | ifier|==>Schedulr|================> ifier|==>Schedulr|=========>
| |______| |________| |data | |______| |________| data
| | | |
|_____________________________| |____________________________|
Figure 3: RSVP in Hosts and RoutersFigure 3 shows the internal process of RSVP in both hosts (end systems) and routers, as shown in [RFC2209]. 🧚
RSVP uses the phrase "traffic control" to describe the mechanisms of how a data flow receives quality of service. There are 3 different mechanisms to traffic control (shown in Figure 2 in both hosts and routers). They are:
- A packet classifier mechanism: This resolves the QoS class for each packet; this can determine the route as well.
- An admission control mechanism: This consists of two decision modules: admission control and policy control. Determining whether there are satisfactory resources for the requested QoS is the function of admission control. Determining whether the user has the authorization to request such resources is the function of policy control. If the parameters carried within this flow fail, either of these two modules errors the request using RSVP.
- A packet scheduler mechanism: At each outbound interface, the scheduler attains the guaranteed QoS for that flow.
2.3.2. RSVP Scaling Issues
As originally written, there was concern that RSVP had scaling limitations due to its data plane behavior [RFC2208]. This either has not proven to be the case or has in time largely been corrected. 🙌 Telephony services generally require peak call admission rates on the order of thousands of calls per minute, and peak call levels comparable to the capacities of the lines in question, which is generally on the order of thousands to tens of thousands of calls. Current RSVP implementations admit calls at the rate of hundreds of calls per second and maintain as many calls in progress as memory configurations allow. 💅
In edge networks, RSVP is used to signal for individual microflows, admitting the bandwidth. However, Differentiated Services is used for the data plane behavior. Admission and policing may be performed anywhere, but need only be performed in the first-hop router (which, if the end system sending the traffic is a DTE, constitutes a DCE for the remaining network) and in routers that have interfaces threatened by congestion. In Figure 1, these would normally be the links that cross network boundaries. 🌈
2.3.3. RSVP Operation in Backbones and Virtual Private Networks (VPNs)
In backbone networks, which are normally awash in bandwidth, RSVP and its affected data flows may be carried in a variety of ways. 🫶 If the backbone is a maze of tunnels between its edges (true of MPLS networks, networks that carry traffic from an encryptor to a decryptor, and also VPNs), applicable technologies include [RFC2207], [RFC2746], and [RFC2983]. An IP tunnel is, simplistically put, a IP packet enveloped inside another IP packet as a payload. When IPv6 is transported over an IPv4 network, encapsulating the entire v6 packet inside a v4 packet is an effective means to accomplish this task. In this type of tunnel, the IPv6 packet is not read by any of the routers while inside the IPv4 envelope. If the inner packet is RSVP enabled, there must be an active configuration to ensure that all relevant backbone nodes read the RSVP fields; [RFC2746] describes this.
This is similar to how IPsec tunnels work. Encapsulating an RSVP packet inside an encrypted packet for security purposes, without copying or conveying the RSVP indicators in the outside IP packet header, would make RSVP inoperable while in this form of a tunnel. 🔒 [RFC2207] describes how to modify an IPsec packet header to allow for RSVP awareness by nodes that need to provide QoS for the flow or flows inside a tunnel.
Other networks may simply choose to aggregate the reservations across themselves, as described in [RFC3175]. The problem with an individual reservation architecture is that each flow requires a non-trivial amount of message exchange, computation, and memory resources in each router between each endpoint. 😩 Aggregation of flows reduces the number of completely individual reservations into groups of individual flows that can act as one for part or all of the journey between end systems. Aggregates are not intended to be from the first router to the last router within a flow, but to cover common paths of a large number of individual flows.
Examples of aggregated data flows include streams of IP data that traverse common ingress and egress points in a network and also include tunnels of various kinds. MPLS LSPs, IPsec Security Associations between VPN edge routers, IP/IP tunnels, and Generic Routing Encapsulation (GRE) tunnels all fall into this general category. The distinguishing factor is that the system injecting an aggregate into the aggregated network sums the PATH and RESV statistical information on the un-aggregated side and produces a reservation for the tunnel on the aggregated side. If the bandwidth for the tunnel cannot be expanded, RSVP leaves the existing reservation in place and returns an error to the aggregator, which can then apply a policy such as IEPS to determine which session to refuse. In the data plane, the DSCP for the traffic must be copied from the inner to the outer header, to preserve the PHB's effect. 🍓
One concern with this approach is that it leaks information into the aggregated zone about the number of active calls or the bandwidth they consume. In fact, it does not, as the data itself is identifiable by aggregator address, deaggregator address, and DSCP. As such, even if it is not advertised, such information is measurable. 👀
2.3.4. Interaction with the Differentiated Services Architecture
In the PATH message, the DCLASS object described in [RFC2996] is used to carry the determined DSCP for the precedence level of that call in the stream. This is reflected back in the RESV message. The DSCP will be determined from the authorized SIP message exchange between end systems by using the R-P header. The DCLASS object permits both bandwidth admission within a class and the building up of the various rates or token buckets. 💖
2.3.5. Admission Policy
RSVP's basic admission policy, as defined, is to grant any user bandwidth if there is bandwidth available within the current configuration. In other words, if a new request arrives and the difference between the configured upper bound and the currently reserved bandwidth is sufficiently large, RSVP grants use of that bandwidth. 🎀 This basic policy may be augmented in various ways, such as using a local or remote policy engine to apply AAA procedures and further qualify the reservation. 🔥
2.3.5.1. Admission for Variable Rate Codecs
Okay so for some apps, like broadcast video using MPEG-1, or voice with no activity detection using a constant bit rate codec like G.711, this basic policy is totally adequate apart from AAA 💅. But for variable rate codecs, like MPEG-4 or a voice codec with Voice Activity Detection, it might be deemed too conservative 🙈. Researchers have studied two basic types of statistical policy: simple over-provisioning, and approximation to ambient load 🧠.
Simple over-provisioning sets the bandwidth admission limit higher than the desired load, because it assumes a session that admits a certain bandwidth will actually use only a fraction of it ✨. For example, if MPEG-4 data streams are known to use data rates between 80 and 800 KBPS, and there's no obvious reason sessions would synchronize (like having commercial breaks on 15 minute boundaries), you could estimate that the average session consumes 400 KBPS and treat an admission of 800 KBPS as actually consuming half that 🍓.
You can also approximate to average load, which is maybe a more reliable procedure 💜. Here you maintain a variable that measures actual traffic through the admitted data's queue, approximating it with an exponentially weighted moving average. When a new reservation request shows up, if the requested rate is less than the difference between the configured upper bound and the current moving average, the reservation gets accepted, and the moving average is immediately increased by the amount of the reservation. That way the bandwidth isn't promised out to several users at once 🔒. Over time the moving average decays from that guard position to an estimate of true load, which may give another session a chance to be reserved that would otherwise have been refused 🦋.
Statistical reservation schemes like these are overwhelmingly dependent on the correctness of their configuration and how well it suits the codecs in use 💀. But they let you take advantage of statistical multiplexing gains that might otherwise be missed 👑.
2.3.5.2. Interaction with Complex Admission Policies, AAA, and Preemption of Bandwidth
Policy is carried and applied as described in [RFC2753] 🎀. Figure 4 below is the basic conceptual model for policy decisions and enforcement in an Integrated Services model. This model was created to give us the ability to monitor and control reservation flows based on user identity, specific traffic, and security requirements, plus conditions that might change for various reasons, including a reaction to a disaster or emergency event involving the network or its users 🚨.
Network Node Policy server
______________
| ______ |
| | | | _____
| | PEP | | | |------------->
| |______|<---|---->| PDP |May use LDAP,SNMP,COPS...for accessing
| ^ | | | policy database, authentication, etc.
| | | |_____|------------->
| __v___ |
| | | | PDP = Policy Decision Point
| | LPDP | | PEP = Policy Enforcement Point
| |______| | LPDP = Local Policy Decision Point
|______________|
Figure 4: Conceptual Model for Policy Control of RoutersThe Network Node represents a router in the network. The Policy Server represents the point of admission and policy control by the network operator 🏰. The Policy Enforcement Point (PEP), which is the router, is where the policy action actually gets carried out ⚡. Policy decisions can live locally in the form of a Local Policy Decision Point (LPDP), or in a separate server on the network called the Policy Decision Point 🧚. The easier the instruction set of rules, the more likely it can reside in the LPDP for speed of access reasons. The more complex the rule set, the more likely it's active on a remote server 🌈. The PDP will use other protocols (LDAP, SNMP, etc.) to request information (e.g., user authentication and authorization for precedence level usage) to be used in creating the rule sets of network components 🔍. This remote PDP should also be considered where non-reactive policies are distributed out to the LPDPs 💅.
Taking the above model as a framework, [RFC2750] extends RSVP's concept of a simple reservation to include policy controls. That includes the concepts of Preemption [RFC3181] and Identity [RFC3182], specifically speaking to the usage of policies that preempt calls under the control of either a local or remote policy manager 📞. The policy manager assigns a precedence level to the admitted data flow. If it admits a data flow that exceeds the available capacity of a system, the expectation is that the RSVP-affected RSVP process will tear down a session among the lowest precedence sessions it has admitted 😭. The RESV Error resulting from that will go to the receiver of the data flow and get reported to the application (SIP or H.323). That application is responsible for disconnecting its call, with a reason code of "bandwidth preemption" 💔.
2.4. Authentication and Authorization of Calls Placed
It will be necessary, of course, to ensure that any policy is applied to an authenticated user. The capabilities assigned to an authenticated user may be considered authorized for use in the network 🔐. For bandwidth admission, this will require the utilization of [RFC2747] [RFC3097]. In SIP and H.323, AAA procedures will also be needed 🫶.
2.5. Defined User Interface
The user interface, meaning the chimes and tones the user hears, should ideally stay the same as in the PSTN for those indications that still apply to an IP network 📱. There should be some new effort to update the list of announcements sent to the user that don't necessarily apply anymore 📝. All indications to the user, of course, depend on positive signals, not unreliable measures based on changing measurements ✨.
3. Security Considerations
This document outlines a networking capability composed entirely of existing specifications. It has significant security issues, and I'm not being dramatic here 😱. A failure of the various authentication or authorization procedures can cause a fundamental breakdown in communications 💀. However, the issues are internal to the various component protocols and are covered by their various security procedures 🛡️.
4. Acknowledgements
This document was developed with the knowledge and input of many people, far too numerous to name one by one 🫶. Key contributors of thoughts include Francois Le Faucheur, Haluk Keskiner, Rohan Mahy, Scott Bradner, Scott Morrison, Subha Dhesikan, and Tony De Simone 👑. Pete Babendreier, Ken Carlberg, and Mike Pierce provided useful reviews 🌸.
5. References
5.1. Normative References ✨
These are the must-read docs 💅 (and no, I'm not capitalizing anything here, that's just how the list is laid out 🙈).
[RFC3689]Carlberg, K. and R. Atkinson, "General Requirements for Emergency Telecommunication Service (ETS)", RFC 3689, February 2004.[RFC3690]Carlberg, K. and R. Atkinson, "IP Telephony Requirements for Emergency Telecommunication Service (ETS)", RFC 3690, February 2004.
Integrated Services Architecture References 🌈
[RFC1633]Braden, B., Clark, D., and S. Shenker, "Integrated Services in the Internet Architecture: an Overview", RFC 1633, June 1994.[RFC2205]Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.[RFC2207]Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC Data Flows", RFC 2207, September 1997.[RFC2208]Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997.[RFC2209]Braden, B. and L. Zhang, "Resource ReSerVation Protocol (RSVP) -- Version 1 Message Processing Rules", RFC 2209, September 1997.[RFC2746]Terzis, A., Krawczyk, J., Wroclawski, J., and L. Zhang, "RSVP Operation Over IP Tunnels", RFC 2746, January 2000.[RFC2747]Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000.[RFC2750]Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000.[RFC2753]Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000.[RFC2996]Bernet, Y., "Format of the RSVP DCLASS Object", RFC 2996, November 2000.[RFC2998]Bernet, Y., Ford, P., Yavatkar, R., Baker, F., Zhang, L., Speer, M., Braden, R., Davie, B., Wroclawski, J., and E. Felstaine, "A Framework for Integrated Services Operation over Diffserv Networks", RFC 2998, November 2000.[RFC3097]Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001.[RFC3175]Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.[RFC3181]Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001.[RFC3182]Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, October 2001.[RFC3312]Camarillo, G., Marshall, W., and J. Rosenberg, "Integration of Resource Management and Session Initiation Protocol (SIP)", RFC 3312, October 2002.
Differentiated Services Architecture References 💖
[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 Services", RFC 2475, December 1998.[RFC2983]Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.[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.[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.
Session Initiation Protocol and Related References 🎀
[RFC2327]Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.[RFC3261]Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.[RFC4411]Polk, J., "Extending the Session Initiation Protocol (SIP) Reason Header for Preemption Events", RFC 4411, February 2006.[RFC4412]Schulzrinne, H. and J. Polk, "Communications Resource Priority for the Session Initiation Protocol (SIP)", RFC 4412, February 2006.
5.2. Informative References 🧚
These are the extra-credit reads 📚 Not required, but lowkey fascinating.
[ANSI.MLPP.Spec]American National Standards Institute, "Telecommunications - Integrated Services Digital Network (ISDN) - Multi-Level Precedence and Preemption (MLPP) Service Capability", ANSI T1.619-1992 (R1999), 1992.[ANSI.MLPP.Supp]American National Standards Institute, "MLPP Service Domain Cause Value Changes", ANSI ANSI T1.619a-1994 (R1999), 1990.[G711.1]Viola Networks, "Netally VoIP Evaluator", January 2003,http://www.brainworks.de/Site/hersteller/viola_networks/Dokumente/Compr_Report_Sample.pdf.[G711.3]Nortel Networks, "Packet Loss and Packet Loss Concealment", 2000,http://www.nortelnetworks.com/products/01/succession/es/collateral/tb_pktloss.pdf.[ITU.ETS.E106]International Telecommunications Union, "International Emergency Preference Scheme for disaster relief operations (IEPS)", ITU-T Recommendation E.106, October 2003.[ITU.MLPP.1990]International Telecommunications Union, "Multilevel Precedence and Preemption Service (MLPP)", ITU-T Recommendation I.255.3, 1990.[Parekh1]Parekh, A. and R. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Multiple Node Case", INFOCOM 1993: 521-530, 1993.[Parekh2]Parekh, A. and R. Gallager, "A Generalized Processor Sharing Approach to Flow Control in Integrated Services Networks: The Single Node Case", INFOCOM 1992: 915-924, 1992.
Appendix A. 2-Call Preemption Example Using RSVP 📞
Okay bestie, this is the big picture 🦋 It shows how SIP, SDP, and RSVP all work together. Most of the heavy lifting is referenced from [RFC2327], [RFC3312], [RFC4411], and [RFC4412], and the RSVP reservation path stuff mostly comes from [RFC2205].
SIP signaling happens at the Application Layer, riding on a UDP/IP or TCP/IP (including TLS/TCP/IP) transport. Routing protocols like BGP and OSPF decide the route the packets take between source and destination devices. RSVP rides on top of IP too, so it's at the mercy of those IP routing protocols to pick a path between endpoints. RSVP is not a routing protocol 🙈 The appendix builds up step by step, showing how many layers are involved in SIP. QoS Preconditions need successful RSVP signaling between endpoints before SIP will acknowledge that the session is set up (for voice, video, or both). Then we'll look at what happens when the network gets overloaded (congestion) and a SIP session gets preempted 😭
Three diagrams show different views of the same connectivity example throughout the appendix. The first one (Figure 5) has lots of routers sitting between lots of endpoints, which are SIP user agents, or UAs. There are 4 UAs of interest, for users Alice, Bob, Carol, and Dave. When a human user has to do something on a UA to move a SIP process along, we'll say so explicitly to avoid confusion. Otherwise, when we say Alice, we mean Alice's UA (her phone) 📱
RSVP reserves bandwidth in one direction only, the direction of the RESV message. As we've discussed, IP forwarding of packets is dictated by the routing protocol for that part of the infrastructure, from the point of view of where the packet goes next 🌸
The RESV message travels through the routers in the reverse path taken by the PATH message. The PATH message sets up a record of the route through a part of the network to the destination endpoint, but it does not reserve any resources (bandwidth). The RESV message goes back to the original requester of the RSVP flow and asks for the bandwidth. That means the endpoint that starts the RESV message controls the reservation's parameters. This document says in the body text that the SIP initiator (the UAC) sets the session parameters in an INVITE message, and that the INVITE recipient (the UAS) must follow the parameters from that INVITE. There's one exception: which codec to use, if the UAC offered more than one to the UAS. We'll see that exception when we dig into the INVITE message later in the appendix. If there was only one codec in the SDP of the INVITE message, the reservation parameters follow what the UAC asked for (specifically the Resource-Priority header namespace and priority value) ✨
Here's the first figure, with the 4 UAs and a meshed routed infrastructure between each one. To keep things simple, this appendix only talks about the reservations from Alice to Bob (one direction) and from Carol to Dave (one direction). An interactive voice service needs two one-way reservations, each ending in one of the UAs. That gives the appearance of a two-way reservation, when it really isn't 🦋
Alice -----R1----R2----R3----R4------ Bob
| \ / \ / \ / |
| \/ \/ \/ |
| /\ /\ /\ |
| / \ / \ / \ |
Carol -----R5----R6----R7----R8------ Dave
Figure 5: Complex Routing and Reservation TopologyThe PATH message from Alice to Bob (which sets up the route for the RESV message) goes through these routers:
Alice -> R1 -> R2 -> R3 -> R4 -> BobThe RESV message (and therefore the reservation of resources) from Bob to Alice goes through these routers:
Bob -> R4 -> R3 -> R2 -> R1 -> AliceOkay so picture this: Carol and Dave are the ones setting up the path, and the route they take is kinda iconic 🛣️✨
Carol -> R5 -> R2 -> R3 -> R8 -> DaveThe RESV message (the one that actually reserves the resources 💖) goes back the other way:
Dave -> R8 -> R3 -> R2 -> R5 -> CarolNow here's the tea 🫖. Alice and Bob's reservations both run through the same router link, between R3 and R2. That means R2's interface is sharing the drama, and this is exactly where congestion shows up in this example, on the link between R2 and R3 😭. Voice media packets move in the same direction as the PATH message, and RSVP reserves resources on a router's egress interface. So it's Int7 that finds out first that something's going wrong. Main character energy for Int7, honestly 👑
Alice Bob
\ /
\ /
+--------+ +--------+
| | | |
| R2 | | R3 |
| Int7-------Int5 |
| | | |
+--------+ +--------+
/ \
/ \
Carol Dave
Figure 6: Reduced Reservation TopologyFigure 6 shows how the messages between the UAs and the RSVP messages between the routers fit together. It's basically the visual version of the binding set up in [RFC3312], which honestly deserves a better name, something like "SIP Preconditions for QoS" from this document's point of view 🎀.
We're gonna assume everything has already powered up and grabbed whatever registration or remote policy downloads it needed to work properly 🌸. The routing protocol of choice has already done its routing table update across this part of the network. So now we only care about end-to-end communication and how that messes with the infrastructure in between the endpoints 🧚.
Next up is Figure 7, which is nearly identical to Figure 1 from [RFC3312]. It shows the minimum SIP messaging (at layer 7) between Alice and Bob for a good-quality voice call 📞. The SIP messages are numbered so you can tell the special ones apart. RSVP gets kicked off during the SIP signaling, and we'll talk about that messaging below 💜.
UA Alice UA Bob
| |
| |
|-------------(1) INVITE SDP1--------------->|
| | Note 1
|<------(2) 183 Session Progress SDP2--------| |
***|********************************************|***<-+
* |----------------(3) PRACK------------------>| *
* | | * Where
* |<-----------(4) 200 OK (PRACK)--------------| * RSVP
* | | * is
* | | * signaled
***|********************************************|***
|-------------(5) UPDATE SDP3--------------->|
| |
|<--------(6) 200 OK (UPDATE) SDP4-----------|
| |
|<-------------(7) 180 Ringing---------------|
| |
|-----------------(8) PRACK----------------->|
| |
|<------------(9) 200 OK (PRACK)-------------|
| |
| |
|<-----------(10) 200 OK (INVITE)------------|
| |
|------------------(11) ACK----------------->|
| |
| RTP (within the reservation) |
|<==========================================>|
| |
Figure 7: SIP Reservation Establishment Using PreconditionsSo the call kicks off with Alice wanting to talk to Bob 💬. Alice picks an IEPS precedence level for the call. The default is "routine," which is for normal everyday calls, but a priority level still has to be chosen for every single call 🍓. Alice puts Bob's address and the precedence level into her UA and basically hits send 📤. In SIP, that's an INVITE Method Request message [M1]. Here's what SIP folks call a well-formed SIP message, meaning it has every header it needs to actually work 🫶. We're using the US Marine Corps (USMC) for the addresses in this exchange.
[M1 - INVITE from Alice to Bob, RP=Routine, QOS=e2e and mandatory]
INVITE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9
Max-Forwards: 70
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
Require: 100rel, preconditions, resource-priority
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 191
v=0
o=alice 2890844526 2890844526 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0 4 8
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecvSo in this INVITE, Alice is inviting Bob into a session 🎉. The top half of the lines (everything above the "v=0" line) is SIP headers and their values. The bottom half is Session Description Protocol (SDP) lines. After the first line (the Status line), SIP headers aren't locked into any particular order, with one exception: the Via header 🙅♀️. Via is the SIP hop route path, and every SIP element the message passes through on its way to the destination UA adds a new Via line. It's kinda like an RSVP PATH message, building a reverse path back to whoever sent the message 🔙. At any point along the way, a SIP element knows how to get back to the originator. There are no SIP Proxies in this example, because for Preconditions they just make more messages that look identical (except for the Via and Max-Forwards headers). Not worth the space here when SIP RFCs already cover that stuff 📚.
The SIP headers used for Preconditions are:
- Require header 🔐. It holds 3 option tags. "100rel" demands a reliable provisional response for this INVITE's special conditions. "preconditions" demands that preconditions actually get attempted. "resource-priority" demands support for the Resource-Priority header. Each of these option tags can be called out by name in a failure response from the called UA, so the calling UA knows exactly what wasn't supported.
If this INVITE gets accepted, Bob's UA sends back a 183 "Session Progress" message. That's a reliable confirmation that preconditions are required for the call ✅.
- Resource-Priority header 🚨. It shows the domain namespace and precedence level of the call, end to end.
That wraps up SIP's job in session initiation 🎀. Preconditions get requested, required, and signaled in the SDP part of the message. SDP rides along in a SIP message body, kinda like the text inside an email 💌. SDP has its own special rules (check [RFC2327] for more on SDP, or the MMUSIC WG for what's cooking with it 🧁). SDP lines have to be in a specific order so end systems can parse them 🧩. Dialog-generating (or call-generating) SDP bodies all need an "m=" line, a media description line. After the "m=" line come zero or more "a=" lines, called Attribute lines 🏷️.
The "m=" line in Alice's INVITE is asking for a voice session (video gets identified here too 📹). It offers 3 codecs Alice supports (0 = G.711, 4 = G.723, and 18 = G.729), and Bob gets to pick one of them for the session. Bob can choose any of the 3 🙌. The first a=rtpmap line describes the codec type these 3 are (PCMU). The next two "a=" lines are the only identifiers that tell you RSVP is being used for this call 👀. Here's the second "a=" line:
a=curr:qos e2e noneIt tells you the "current" qos status at Alice's UA. Quick note 📝: everything in SDP is from the sender's point of view. Alice will never tell Bob what his SDP looks like. She only tells Bob about her own SDP 🙅♀️.
- "e2e" means capacity assurance is required from Alice's UA to Bob's UA. So if there's no available capacity assurance in either direction, the call attempt fails 💀.
- "none" means there's no reservation from Alice's UA to Bob right now 🫥.
The final "a=" line (a=des) shows the "desired" level of qos:
a=des:qos mandatory e2e sendrecv- "mandatory" means this qos request MUST be successful, or the call fails 🛑.
- "e2e" means RSVP is required from Alice's UA to Bob's UA 💅.
- "sendrecv" means the reservation goes in both directions 🔁.
Now, RSVP doesn't reserve bandwidth in both directions at once 🙃. If the application needs it (and voice does), the endpoints have to set up 2 one-way reservations. Voice between Alice and Bob needs those 2 one-way reservations, and the UAs are the focal points for both of them ✨.
Message 2 is the 183 "Session Progress" message Bob sends back to Alice. It tells Alice that Bob gets that preconditions are needed for this call 🙌.
[M2 - 183 "Session Progress"]
SIP/2.0 183 Session Progress
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bf9 ;received=10.1.3.33
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>;tag=8321234356
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 31862 INVITE
RSeq: 813520
Resource-Priority: dsn.routine
Contact: <sip:bob@usmc.example.mil>
Content-Type: application/sdp
Content-Length: 210
v=0
o=bob 2890844527 2890844527 IN IP4 usmc.example.mil
c=IN IP4 10.100.50.51
t=0 0
m=audio 3456 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recvThe only header in this message that's really interesting is RSeq 🔢, the "Reliable Sequence" header. Its value goes up by one for every Reliable message sent in this call setup, so nothing gets lost and duplicates can be ignored 🧐.
Bob's SDP sets a few "a=" line statuses and picks a codec for the call 🎶. The codec is in the m=audio line, and that "0" at the end means G.711 is the one 🎧.
The a=curr line tells Alice where Bob stands on RSVP, and right now it's "none" 🫤. The a=des line also says Bob wants mandatory qos e2e in both directions 💜.
Okay so the a=conf line is brand new 🆕✨ and it basically means Bob wants confirmation that Alice has 2 one-way reservations before Bob's UA proceeds with the SIP session setup 🫶
This is where "Note-1" applies in Figure 7 💅 When Bob's UA sends this 183 message, Bob's UA (the one that picked the codec, so it knows how much bandwidth to reserve 🧠) also sends an RSVP PATH message to Alice's UA. This PATH message takes the route we saw back in Figure 5:
Bob -> R4 -> R3 -> R2 -> R1 -> AliceThat's the path of the PATH message, and the reverse is the path of the reservation setup RESV message:
Alice -> R1 -> R2 -> R3 -> R4 -> BobRight after Alice sends the RESV message towards Bob, Alice sends her own PATH message to start the other one-way reservation. Bob gets that PATH message and replies with a RESV 🦋
All of this is independent of SIP 🌸 But during this reservation setup, a Provisional Acknowledgement (PRACK) [M3] goes from Alice to Bob to confirm the request for confirmation of 2 one-way reservations at Alice's UA. That message gets acknowledged with a normal 200 OK message [M4]. You can see it all in Figure 7 ✨
As soon as RSVP wraps up at Alice's UA (she knows it's the last step in the two-way cycle of reservation establishment 👑), an UPDATE message [M5] goes up at the SIP layer to Bob's UA. It tells his UA that the current status of RSVP (or qos) is "e2e" and "sendrecv" 😭
[M5 - UPDATE to Bob that Alice has qos e2e and sendrecv]
UPDATE sip:bob@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: <sip:alice@usmc.example.mil>
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 191
v=0
o=alice 2890844528 2890844528 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e send
a=des:qos mandatory e2e sendrecvThis is shown by the matching table you can build from the a=curr line and the a=des line 🧩 If the two lines match, then no further signaling needs to happen with regard to "qos". [M6] is the 200 OK acknowledging this synchronization between the two UAs 🎀
[M6 - 200 OK to the UPDATE from Bob indicating synchronization]
SIP/2.0 200 OK sip:bob@usmc.example.mil
Via: SIP/2.0/TCP pc33.usmc.example.mil:5060
;branch=z9hG4bK74bfa
From: Alice <sip:alice@usmc.example.mil>;tag=9fxced76sl
To: Bob <sip:bob@usmc.example.mil>
Call-ID: 3848276298220188511@pc33.usmc.example.mil
Resource-Priority: dsn.routine
Contact: < sip:alice@usmc.example.mil >
CSeq: 10197 UPDATE
Content-Type: application/sdp
Content-Length: 195
v=0
o=alice 2890844529 2890844529 IN IP4 usmc.example.mil
c=IN IP4 10.1.3.33
t=0 0
m=audio 49172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=curr:qos e2e sendrecv
a=des:qos mandatory e2e sendrecvAt this point the reservation is operational and both UAs know it 🥹 Bob's UA now rings, telling Bob the user that Alice is calling him. ([M7] is the SIP indication to Alice that this is happening.) Nothing up until now has involved Bob the user 💜 Bob picks up the phone (generating [M10], which Alice's UA answers with the final ACK), and RTP is now running inside the reservations between the two UAs 📞✨
Now we get to Carol calling Dave 👀 Figure 6 shows a common router interface for the reservation between Alice and Bob, and that same interface is also the route for one of the reservations between Carol and Dave. This interface is going to get congested in our example 🚧
Carol is calling Dave at a Resource-Priority level of "Immediate", which outranks Alice to Bob's "routine" 👑 In this continuing example, Router 2's Interface-7 is congested and can't accept any more RSVP traffic. Maybe the offered load is at interface capacity. Or maybe Interface-7 is configured with a fixed amount of bandwidth it can allocate for RSVP traffic, and it has hit that max without any reservation going away through normal termination or forced termination (preemption) 😤
Interface-7 is not so full of offered load that it can't transmit signaling packets, like Carol's SIP messaging to set up a call to Dave. This should be by design (so that not all RSVP traffic can starve an interface of signaling packets) 🫶 Carol sends her own INVITE with these important characteristics:
[M1 - INVITE from Carol to Dave, RP=Immediate, QOS=e2e and mandatory]
This packet does not affect the reservations between Alice and Bob, because SIP and RSVP live at different layers and all the routers are passing signaling packets without problems 🌈 Dave sends his M2:
[M2 - 183 "Session Progress"]
with the SDP chart of:
a=curr:qos e2e none
a=des:qos mandatory e2e sendrecv
a=conf:qos e2e recvThat tells us he understands RSVP reservations are required e2e for this call to count as successful 🧠 Dave sends his PATH message. The PATH message does not affect Alice's reservation. It just sets up a path for the RESV reservation setup message to take 🦋
To keep this example simple, the PATH message from Dave to Carol took this route (which we made different from the route in the reverse direction):
Dave -> R8 -> R7 -> R6 -> R5 -> Carolwhich causes the reservation to be this route:
Carol -> R5 -> R6 -> R7 -> R8 -> DaveThe Carol-to-Dave reservation above won't traverse any of the same routers as the Alice-to-Bob reservation 🙅♀️ When Carol sends her RESV message towards Dave, she immediately sends her PATH message to set up the complementary reservation.
The PATH message from Carol to Dave goes through routers:
Carol -> R5 -> R2 -> R3 -> R8 -> DaveSo the RESV message will go through routers:
Dave -> R8 -> R3 -> R2 -> R5 -> CarolThis RESV message traverses the same routers, R3 and R2, as the Alice-to-Bob reservation. When it arrives at Interface-7 of R2, it creates a congestion situation, and R2 has to decide whether to:
- keep the Alice-to-Bob reservation and error the new RESV from Dave, or
- error the reservation from Alice to Bob in order to make room for the Carol-to-Dave reservation.
Alice's reservation was set up in SIP at the "routine" precedence level. That equates to a comparable RSVP priority number (RSVP has 65,535 priority values, or 2*32 bits per [RFC3181]). Dave's RESV equates to a precedence value of "immediate", which is higher priority 🔥 So R2 preempts the reservation from Alice to Bob and lets Dave's reservation request to Carol through. The proper RSVP error is the ResvErr that indicates preemption. That message travels downstream towards the originator of the RESV message (Bob), and it clears the reservation in all routers downstream of R2 (meaning R3 and R4) 💀
Once Bob gets the ResvErr message saying preemption happened on this reservation, Bob's UA sends a SIP preemption indication back towards Alice's UA. This accomplishes two things. First, it informs all SIP Servers that were in the session setup path and wanted to remain "dialog stateful" per [RFC3261]. Second, it tells Alice's UA that this was a purposeful termination, so it should play a preemption tone 🔊 The proper SIP indication of this termination due to preemption is a BYE Method message with a Reason Header saying why it happened (in this case, "Reserved Resources Preempted"). Here's the message from Bob to Alice that ends the call in SIP:
BYE sip:alice@usmc.example.mil SIP/2.0
Via: SIP/2.0/TCP swp34.usmc.example.mil
;branch=z9hG4bK776asegma
To: Alice <sip:alice@usmc.example.mil>
From: Bob <sip:bob@usmc.example.mil>;tag=192820774
Reason: preemption ;cause=2 ;text=reserved resourced preempted
Call-ID: 3848276298220188511@pc33.usmc.example.mil
CSeq: 6187 BYE
Contact: <sip:bob@usmc.example.mil>When Alice's UA gets this message, it ends the call, sends a 200 OK to Bob to confirm it got the BYE, and plays a preemption tone for Alice the user 📞💔
The RESV message from Dave successfully makes it through R2, and Carol's UA receives it 🎉 Just like with the Alice-to-Bob call setup, Carol sends an UPDATE message to Dave, confirming she has QoS "e2e" in "sendrecv" directions. Dave acknowledges this with a 200 OK that gives his current status (QoS "e2e" and "sendrecv"), and the call setup in SIP carries on to completion 🥳
In summary, Alice set up a call to Bob with RSVP at a Routine priority level. When Carol called Dave at a high priority, that call would have preempted any lower priority calls if there was contention for resources 👑 In this case there was, and it hit the call between Alice and Bob. A router at the congestion point preempted Alice's call to Bob to place the higher-priority call between Carol and Dave. Alice and Bob were both informed of the preemption event, and both their UAs played preemption indications 🔊 What this appendix didn't mention is that this document RECOMMENDS that router R2 (in this example) generate a syslog message to the domain administrator, so such events get properly managed and tracked within this domain 📋 That way the domain administrators have recorded knowledge of where these events happen and what conditions caused them 🌸
Authors' Addresses
Fred Baker
Cisco Systems
1121 Via Del Rey
Santa Barbara, California 93117
USA
Phone: +1-408-526-4257
Fax: +1-413-473-2403
EMail: fred@cisco.com
James Polk
Cisco Systems
2200 East President George Bush Turnpike
Richardson, Texas 75082
USA
Phone: +1-817-271-3552
EMail: jmpolk@cisco.comFull Copyright Statement
Copyright (C) The Internet Society (2006) 🎀
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights 💅
This document and the information contained herein 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 ✨
okay so bestie, the IETF is basically saying "we're not picking a side on who owns what" 💅 They take no position on whether any Intellectual Property Rights (or other rights someone might claim) are valid or how far they reach, and they can't promise any license is available for the tech in this document. They also haven't gone out and hunted down every possible right either, so no cap, that's on you to check 🧐 If you want the rules for rights in RFC documents, they live in BCP 78 and BCP 79 📚
Want a copy of IPR disclosures that were sent to the IETF Secretariat? Or any promised licenses? Or the result of someone trying to get a general license or permission to use those proprietary rights as an implementer or user? You can find all of that in the IETF on-line IPR repository at http://www.ietf.org/ipr 🦋
The IETF also invites anyone to flag copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Just send the info to ietf-ipr@ietf.org 💌 Helping them spot that stuff early is literally such a main character move 🫶
Acknowledgement ✨
Quick shout-out to the people keeping the lights on 💖 Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA). Without that, the whole RFC pipeline would be giving nothing 💀 So yay for the behind-the-scenes crew 👑🌈
📦 where this page comes from
- ietf: rfc4542 2006-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms