RFC 6401
RSVP Extensions for Admission Priority
RFC 6401: RSVP Extensions for Admission Priority 🎀
okay bestie, this is the title block tea ☕
- Who wrote it: F. Le Faucheur and J. Polk (both from Cisco), with K. Carlberg (listed as G11) 💅
- Category: Standards Track 🔥
- ISSN: 2070-1721
- Date: October 2011 🍓
- Obsoletes / Updates: the title block doesn't list anything here, so no obsoleting or updating to report ✨
Internet Engineering Task Force (IETF), Request for Comments: 6401
Abstract
okay so some apps need a way to get a higher chance of setting up their session when the network is jammed 🚦 when IP is in play, one way to make that happen is a network-layer admission control thing that gives priority access to resources like bandwidth. those resources could be set aside just for the prioritized sessions, or they could be shared with everyone else 🦋 this doc spells out extensions to the Resource reSerVation Protocol (RSVP) that let you support that kind of admission priority at the network layer 💜
because of current security concerns, these extensions are meant for use in a single administrative domain only 🔒 so not for the whole wild internet!!
Status of This Memo
this one is an Internet Standards Track document 🌈
it's a product of the Internet Engineering Task Force (IETF), so it reflects what the IETF community agreed on. it got public review and the Internet Engineering Steering Group (IESG) approved it for publication. if you want more on 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/rfc6401 ✨
Copyright Notice
Copyright (c) 2011 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 stand on the publication date. read those carefully, because they spell out your rights and restrictions for this doc 💅
any Code Components pulled out of this document have to include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they come with no warranty, as the Simplified BSD License describes 🫶
this doc may include material from IETF Documents or IETF Contributions that were published or made publicly available before November 10, 2008. the people who control the copyright in some of that material may not have given the IETF Trust permission to allow modifications outside the IETF Standards Process. so without an adequate license from those copyright holders, this doc can't be modified outside the IETF Standards Process, and derivative works can't be made outside it either. 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 4
3. Requirements Language . . . . . . . . . . . . . . . . . . . . 4
4. Overview of RSVP Extensions and Operations . . . . . . . . . . 4
4.1. Operations of Admission Priority . . . . . . . . . . . . . 6
5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7
5.1. Admission Priority Policy Element . . . . . . . . . . . . 8
5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9
5.2. Application-Level Resource Priority Policy Element . . . . 10
5.2.1. Application-Level Resource Priority Modifying and
Merging Rules . . . . . . . . . . . . . . . . . . . . 11
5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6.1. Use of RSVP Authentication between RSVP Neighbors . . . . 13
6.2. Use of INTEGRITY object within the POLICY_DATA Object . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Examples of Bandwidth Allocation Model for
Admission Priority . . . . . . . . . . . . . . . . . 19
A.1. Admission Priority with Maximum Allocation Model (MAM) . . 19
A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 23
A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 26
Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 291. Introduction ✨
some apps need a higher chance of session establishment for specific sessions when the network is congested 🚦
there are session-layer ways to solve that too, where the session control function prioritizes access to its resources. for example, entities involved in session control (like SIP user agents, when the Session Initiation Protocol (SIP) [RFC3261] is the session control protocol in use) can change how they handle session establishment requests (like SIP requests). that can mean "queueing" requests that can't be honored right away, and sometimes "bumping" or "displacing" less important requests out of that queue. it can also include stuff like alternate routing and getting exempted from some network management controls 💅
network-layer admission control can help with the higher-chance goal as well, as long as it supports admission priority. networks usually have engineered capacity limits, which is the max load a link can handle for a traffic class while still meeting that class's quality-of-service (QoS) requirements. admission priority can mean setting some resources (like bandwidth) aside from those engineered limits, just for prioritized sessions. or it can mean letting prioritized sessions grab extra resources beyond the limits that normal sessions get. this doc specifies what's needed to support that when network-layer admission control is done with the Resource reSerVation Protocol (RSVP) [RFC2205] 🦋
[RFC3181] defines the Signaled Preemption Priority Policy Element. RSVP can carry it so a network node can take it into account and preempt some previously admitted low-priority sessions to make room for a newer, higher-priority one. this doc is different. its goal is to raise the chance of session establishment without preempting anything that already exists 🌸 it does that with engineered capacity techniques in the form of bandwidth allocation models. specifically, it defines two new RSVP policy elements, so the admission priority can be carried inside RSVP signaling messages. then RSVP nodes can make a selective bandwidth admission control decision based on the session's admission priority 👑 Appendix A also has examples of bandwidth allocation models that RSVP-routers can use to enforce admission priority on every link. a given reservation can be signaled with the admission priority extensions from this doc, with the preemption priority from [RFC3181], or with both 🫶
1.1. Terminology 💜
this doc uses the terminology from [RFC2753]. here are a few key terms repeated for convenience:
- Policy Decision Point (PDP): the point where policy decisions get made.
- Local Policy Decision Point (LPDP): the PDP that's local to the network element.
- Policy Enforcement Point (PEP): the point where those policy decisions actually get enforced.
- Policy Ignorant Node (PIN): a network element that doesn't explicitly support policy control using the mechanisms defined in [RFC2753].
2. Applicability Statement 🌈
a subset of RSVP messages is signaled with the Router Alert Option (RAO) ([RFC2113], [RFC2711]). the security aspects and common practices around the current IP Router Alert Option, plus what it means for apps like RSVP, are discussed in [RFC6398] 🔒
based on all that, the extensions in this doc are meant for use within a single administrative domain. so specifically, they're not intended for end-to-end use on the Internet 💖
3. Requirements Language 📚
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] ✨
keep those capitalized key words in mind, they're the ones that carry the weight in the rest of the spec 💅
4. Overview of RSVP Extensions and Operations ✨
Okay bestie, picture this: a session needs a higher chance of actually getting set up 💖. The perk we're talking about is "admission priority" at the network layer. That's different from preemption, which is kicking existing sessions off the line. By "admission priority" we mean the priority session can grab network resources from the capacity that's been engineered and set aside for priority sessions (stuff normal sessions can't touch) or it can go past the engineered capacity limits that normal sessions are stuck with 🦋.
Session establishment can be made conditional on resource-based and policy-based network-layer admission control, done through RSVP signaling. If the session control protocol is SIP, RSVP-based admission control with SIP is specified in [RFC3312] 🎀.
Devices involved in session establishment are expected to know about the application-level priority needs of prioritized sessions. For example, with SIP, the user agents can be made aware of a session's resource priority requirements using the "Resource-Priority" header mechanism specified in [RFC4412] 💅. The end devices in the upper-layer session setup simply need to copy those application-level requirements (e.g., as communicated in the SIP "Resource-Priority" header) into the new RSVP Application-Level Resource Priority Policy Element defined in this document 🫶.
Carrying the application-level requirements inside the RSVP message means they can be mapped or remapped into a different RSVP "admission priority" at a policy boundary, based on the policy for that policy area 🌈. In a typical model (see [RFC2753]), PDPs control PEPs at the edge of the policy area (e.g., on the first hop router). The PDPs read the RSVP Application-Level Resource Priority Policy Element and map the prioritized session's requirement into an RSVP "admission priority" level. Then they convey that info inside the new Admission Priority Policy Element defined in this document. This way, the RSVP admission priority can be communicated to downstream PEPs (i.e., RSVP routers) of the same policy domain that have LPDPs but no controlling PDP 🧚. That means the necessary RSVP admission priority can be enforced at every RSVP hop, including all the (possibly many) hops that don't understand application-level resource priority semantics at all 😭.
It is not expected that the RSVP Application-Level Resource Priority Header Policy Element would be taken into account at RSVP hops within a given policy area. It's only meant for policy area boundaries, where it's used to set or reset the RSVP Admission Priority Policy Element 🍓.
Remapping by PDPs of the Admission Priority Policy Element from the Application-Level Resource Priority Policy Element may also be used at boundaries with other signaling protocols, such as the NSIS Signaling Layer Protocol (NSLP) for QoS Signaling [RFC5974] 👑.
As you can see, the framework above for mapping and remapping application-level resource priority requirements into an RSVP admission priority can also be used together with [RFC3181] to map and remap them into an RSVP preemption priority. That's for when preemption is indeed deemed necessary by the prioritized session handling policy 💜. In that case, when processing the RSVP Application-Level Resource Priority Policy Element, the PDPs at policy boundaries (or between various QoS signaling protocols) can map it into RSVP "preemption priority" information. This preemption priority information comprises a setup preemption level and a defending preemption priority level, which can then be encoded inside the Preemption Priority Policy Element of [RFC3181] 🌸.
Appendix B provides examples of various hypothetical policies for prioritized session handling. Some involve admission priority, and some involve both admission priority and preemption priority. Appendix B also identifies how the application-level resource priority needs to be mapped into RSVP policy elements by the PDPs to realize these policies 📚.
4.1. Operations of Admission Priority 🎀
The RSVP Admission Priority Policy Element defined in this document lets admission bandwidth be allocated preferentially to prioritized sessions. Multiple models of bandwidth allocation MAY be used to that end 🌈.
A number of bandwidth allocation models have been defined in the IETF for allocating bandwidth across different classes of traffic trunks in the context of Diffserv-aware MPLS Traffic Engineering ✨. Those include the Maximum Allocation Model (MAM) defined in [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127], and the Maximum Allocation model with Reservation (MAR) defined in [RFC4126]. However, these same models MAY be applied for allocating bandwidth across different levels of admission priority as defined in this document. Appendix A illustrates how these bandwidth allocation models can be applied for such purposes, and it also introduces an additional bandwidth allocation model that we'll call the Priority Bypass Model (PrBM) 🦋. It is important to note that the models described and illustrated in Appendix A are only informative and do not represent a recommended course of action ⚠️.
We can see in these examples how RSVP routers can use the RSVP Admission Priority to influence their admission control decisions. For example, it determines which bandwidth pool RSVP uses for its bandwidth allocation, and that helps increase the probability of reservation establishment 💅. In turn, this increases the probability of application-level session establishment for the corresponding session 🔥.
5. New Policy Elements 🧚
The Framework document for policy-based admission control [RFC2753] describes the various components that take part in policy decision making (i.e., PDP, PEP, and LPDP) 💖.
As described in Section 4 of the present document, the Application-Level Resource Priority Policy Element and the Admission Priority Policy Element play different roles in this framework:
- The Application-Level Resource Priority Policy Element conveys application-level information and is processed by PDPs.
- The emphasis of the Admission Priority Policy Element is to be simple, stateless, and lightweight, so it can be processed internally within a node's LPDP. It can then be enforced internally within a node's PEP. It is set by PDPs based on processing of the Application-Level Resource Priority Policy Element 🫶.
[RFC2750] defines extensions for supporting generic policy-based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events 🌈.
The POLICY_DATA object contains one or more policy elements, each representing a different (and perhaps orthogonal) policy. As an example, [RFC3181] specifies the Preemption Priority Policy Element. This document defines two new policy elements called:
- the Admission Priority Policy Element
- the Application-Level Resource Priority Policy Element
5.1. Admission Priority Policy Element 🌸
The format of the Admission Priority Policy Element is as shown in Figure 1:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = ADMISSION_PRI |
+-------------+-------------+-------------+-------------+
| Flags | M. Strategy | Error Code | Reserved |
+-------------+-------------+-------------+-------------+
| Reserved |Adm. Priority|
+---------------------------+---------------------------+
Figure 1: Admission Priority Policy Elementwhere:
Length: 16 bits- Always 12. The overall length of the policy element, in bytes.
P-Type: 16 bitsADMISSION_PRI=0x05(see the "IANA Considerations" section).
Flags: Reserved- SHALL be set to zero on transmit and SHALL be ignored on reception.
- Merge Strategy: 8 bits (applicable to multicast flows)
- Values are defined in the corresponding registry maintained by IANA (see the "IANA Considerations" section).
- Error code: 8 bits (applicable to multicast flows)
- Values are defined in the corresponding registry maintained by IANA (see the "IANA Considerations" section).
- Reserved: 8 bits
- SHALL be set to zero on transmit and SHALL be ignored on reception.
- Reserved: 24 bits
- SHALL be set to zero on transmit and SHALL be ignored on reception
Adm. Priority(Admission Priority): 8 bits (unsigned)- The admission control priority of the flow, in terms of access to network bandwidth, in order to provide higher probability of session completion to selected flows. Higher values represent higher priority. Bandwidth allocation models such as those described in Appendix A are to be used by the RSVP router to achieve increased probability of session establishment. The admission priority value effectively indicates which bandwidth constraint(s) of the bandwidth constraint model in use is/are applicable to admission of this RSVP reservation 🔥.
Note that the Admission Priority Policy Element does NOT indicate that this RSVP reservation is to preempt any other RSVP reservation. If a priority session justifies both admission priority and preemption priority, the corresponding RSVP reservation needs to carry both an Admission Priority Policy Element and a Preemption Priority Policy Element. The Admission Priority and Preemption Priority are handled by LPDPs and PEPs as separate mechanisms. They can be used one without the other, or they can be used both in combination 💀.
5.1.1. Admission Priority Merging Rules 💖
Okay bestie, this part is about what happens when reservations get merged 🌈 Merging is a multicast thing, so this whole section applies to multicast sessions too 💜
The merge rules for Admission Priority Policy Elements come from the value in the Merge Strategy field, and that value is looked up in the matching IANA registry. This registry covers the Merge Strategy field in the Admission Priority element and the Merge Strategy field in the Preemption Priority element from [RFC3181]. It starts out with the values that [RFC3181] already defined (see the "IANA Considerations" section) 🎀
Here's the tea 🍵: the only real difference from [RFC3181] is that this document does not recommend a particular merge strategy for Admission Priority, while [RFC3181] recommends the first of those strategies for Preemption Priority. And ngl, the phrase "take highest priority" means "take the highest numerical value" for Admission Priority, just like it does for Preemption Priority ✨
5.2. Application-Level Resource Priority Policy Element 👑
Here's how the Application-Level Resource Priority Policy Element is laid out, as shown in Figure 2 💅
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+-------------+-------------+-------------+-------------+
| Length | P-Type = APP_RESOURCE_PRI |
+-------------+-------------+-------------+-------------+
// ALRP List //
+---------------------------+---------------------------+Figure 2: Application-Level Resource Priority Policy Element
Where:
- Length:
- The length of the policy element (including the Length and P-Type) is in number of octets (MUST be a multiple of 4) and indicates the end of the ALRP list.
- P-Type: 16 bits
APP_RESOURCE_PRI=0x06(see the "IANA Considerations" section).
- ALRP List:
- List of ALRPs where each ALRP is encoded as shown in Figure 3.
Each ALRP looks like this 🦋
ALRP:
0 0 0 1 1 2 2 3
0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1
+---------------------------+-------------+-------------+
| ALRP Namespace | Reserved |ALRP Value |
+---------------------------+---------------------------+Figure 3: Application-Level Resource Priority
Where:
- ALRP Namespace (Application-Level Resource Priority Namespace): 16 bits (unsigned)
- Contains a numerical value identifying the namespace of the application-level resource priority. This value is encoded as per the "Resource Priority Namespaces" IANA registry. (See the "IANA Considerations" section; IANA has extended the registry to include this numerical value).
- Reserved: 8 bits
- SHALL be set to zero on transmit and SHALL be ignored on reception.
- ALRP Value (Application-Level Resource Priority Value): 8 bits (unsigned)
- Contains the priority value within the namespace of the application-level resource priority. This value is encoded as per the "Resource Priority Priority-Value" IANA registry. (See the "IANA Considerations" section; IANA has extended the registry to include this numerical value).
5.2.1. Application-Level Resource Priority Modifying and Merging Rules 🌸
When POLICY_DATA objects are protected by integrity, LPDPs should not try to modify them 🙈 They MUST be forwarded without modification so their security envelope doesn't get invalidated. Don't mess with the sealed envelope, babe 💌
In multicast, when POLICY_DATA objects are not protected by integrity, LPDPs MAY merge incoming Application-Level Resource Priority Elements to shrink their size and count. But if they do merge, they MUST follow this rule:
- The ALRP List in the outgoing APP_RESOURCE_PRI element MUST contain all the ALRPs that appear in the ALRP List of an incoming APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than once. In other words, the outgoing ALRP List is the union of the incoming ALRP Lists that get merged 🧠
Since merging applies to multicast, this rule also applies to multicast sessions ✨
5.3. Default Handling 🧚
As specified in Section 4.2 of [RFC2750], Policy Ignorant Nodes (PINs) use a default handling for POLICY_DATA objects so those objects can get through PINs on their way from one PEP to another. This covers the situations where POLICY_DATA objects contain the Admission Priority Policy Element and the ALRP Policy Element specified in this document, so those objects can make it through PINs 🛸
Section 4.2 of [RFC2750] also describes a similar default behaviour for policy-capable nodes that don't recognise a particular policy element. This applies to the Admission Priority Policy Element and the ALRP Policy Element specified here, so those elements can pass through policy-capable nodes that don't support the extensions in this document 🫶
6. Security Considerations 🔥
Okay, this part is seriously important 😭 Because this document defines extensions to RSVP, the security considerations of RSVP apply. Those are discussed in [RFC2205], [RFC4230], and [RFC6411]. Approaches for addressing those concerns are discussed further below.
A subset of RSVP messages are signalled with the Router Alert Option (RAO) ([RFC2113], [RFC2711]). The security aspects and common practices around the use of the current IP Router Alert Option, and the consequences for applications such as RSVP that use IP Router Alert, are discussed in [RFC6398]. As discussed in Section 2, the extensions defined in this document are intended for use within a single administrative domain 🔐
[RFC6398] discusses router alert protection approaches for service providers. These approaches can be used to protect a given network against the potential risks of router alert packets leaking out of the use of these extensions in another domain. Also, where RSVP is not used, a network can generally isolate itself from any RSVP signalling that may leak from another network using these extensions, simply by not enabling RSVP on its routers (since the routers will then typically ignore RSVP messages). Where RSVP is to be used internally within a given network, the network operator can activate, on the edge of the network, mechanisms that either tunnel or, as a last resort, drop incoming RSVP messages, in order to protect the network from RSVP signalling that may leak from another network using these extensions 🛡️
The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in this document are signalled by RSVP through encapsulation in a POLICY_DATA object as defined in [RFC2750]. So, like any other policy elements, their integrity can be protected as discussed in Section 6 of [RFC2750] by two optional security mechanisms 💜 The first mechanism relies on RSVP authentication as specified in [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages. The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP PEPs that are not RSVP neighbours.
6.1. Use of RSVP Authentication between RSVP Neighbors 🔑
RSVP authentication can be used between RSVP neighbours that are policy capable. RSVP authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of the present document.
With RSVP authentication, the RSVP neighbours use shared keys to compute the cryptographic signature of the RSVP message. [RFC6411] discusses key types and key provisioning methods, as well as their respective applicability 🗝️
6.2. Use of INTEGRITY object within the POLICY_DATA Object 🎀
The INTEGRITY object within the POLICY_DATA object can be used to guarantee integrity between non-neighbouring RSVP PEPs. This is useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of the present document.
Details for computing the content of the INTEGRITY object can be found in Appendix B of [RFC2750]. That says the Policy Decision Point (PDP), at its discretion and based on the destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used. Keys to be used between PDPs can be distributed manually or via a standard key management protocol for secure key distribution 🌈
Note that where non-RSVP hops may exist between RSVP hops, and where RSVP-capable PINs may exist between PEPs, it may be difficult for the PDP to determine the destination PDP for a POLICY_DATA object contained in some RSVP messages (such as a Path message). This is because in those cases the next PEP is not known at the time the message is forwarded. In this situation, a key shared across multiple PDPs may be used. This is conceptually similar to using a key shared across multiple RSVP neighbours, as discussed in [RFC6411] 🤔
We also observe that this issue may not exist in some deployment scenarios, where a single (or a low number of) PDP is used to control all the PEPs of a region (such as an administrative domain). In such scenarios, it may be easy for a PDP to determine the next-hop PDP, even when the next-hop PEP is not known, simply by working out which region will be traversed next (say, based on the destination address) 🦋
7. IANA Considerations 🎀
Okay, bestie, this is IANA's to-do list 📋✨ Like [RFC2750] says, standard RSVP policy element P-type values get assigned by IANA under the "IETF Consensus" policy, which is outlined in [RFC2434]. That policy is now called "IETF Review" per [RFC5226] 💅
IANA has already handed out two P-Types from the standard RSVP policy element range:
0x05ADMISSION_PRIfor the Admission Priority Policy Element 🔥0x06APP_RESOURCE_PRIfor the Application-Level Resource Priority Policy Element 💖
In Section 5.1, this document adds a Merge Strategy field inside the Admission Priority Policy Element. The registry for it is also meant to apply to the Merge Strategy field of the Preemption Priority Policy Elements from [RFC3181] 🦋 Since values might get added someday that only work for one of those two elements (and not both), IANA listed the applicable documents for each value. Here's what's allocated so far:
0: Reserved
1: Take priority of highest QoS [RFC3181] [RFC6401]
2: Take highest priority [RFC3181] [RFC6401]
3: Force Error on heterogeneous merge [RFC3181] [RFC6401]Following the policies in [RFC5226], numbers in the range 0-127 are allocated according to the "IETF Review" policy, numbers in the range 128-240 are "First Come First Served", and numbers in the range 241-255 are "Reserved for Private Use" 🌈
In Section 5.1, this document also adds an Error Code field inside the Admission Priority Policy Element. IANA made a registry for that field and allocated these values:
0: NO_ERROR - Value used for regular ADMISSION_PRI elements
2: HETEROGENEOUS - This element encountered heterogeneous mergeSame deal as before: following [RFC5226], numbers in the range 0-127 are "IETF Review", numbers in the range 128-240 are "First Come First Served", and numbers in the range 241-255 are "Reserved for Private Use". Value 1 is Reserved (for consistency with the Error Code values in [RFC3181]) 🙈
Section 5.2 defines an ALRP Namespace field, which holds a numerical value identifying the namespace of the application-level resource priority. IANA already keeps the Resource-Priority Namespaces registry (under the SIP Parameters) listing all those namespaces, and it has been updated so every namespace gets a numerical value. Specifically, IANA did the following to that registry:
- Added a new column.
- Titled the new column "Namespace Numerical Value *".
- Added a line to the Legend stating "Namespace Numerical Value = the unique numerical value identifying the namespace".
- Added a line to the Legend stating "* : [RFC6401]".
- Allocated an actual numerical value to each namespace in the registry, listed in the new "Namespace Numerical Value *" column.
IANA has allocated a numerical value for all existing namespaces. Going forward, IANA should automatically allocate a numerical value to any new namespace added to the registry ✨
Section 5.2 also defines an ALRP Priority field, which holds a numerical value identifying the actual application-level resource priority within its namespace. IANA already keeps the Resource-Priority Priority-Values registry (under the SIP Parameters) listing all those priorities, and it's been updated to give each priority-value a numerical value. Here's what changed in that registry:
- For each namespace, the registry is now structured with two columns.
- The first column is titled "Priority Values (least to greatest)".
- The first column lists all the values currently defined in the registry. For example, in the drsn namespace: "routine", "priority", "immediate", "flash", "flash-override", and "flash-override-override".
- The second column is titled "Priority Numerical Value *".
- A "Legend" was added at the bottom of the registry, with a line stating "Priority Numerical Value = the unique numerical value identifying the priority within a namespace".
- The Legend also got a line stating "* : [RFC6401]".
- Every priority value got an actual numerical value, listed in the new "Priority Numerical Value *" column.
IANA has allocated a numerical value to all existing priorities. In the future, IANA should automatically allocate a numerical value to any new namespace added to the registry 💜 The numerical value must be unique within each namespace. Within each namespace, values should be allocated in decreasing order, ending with 0, so the greatest priority always gets value 0 👑 For example, in the drsn namespace, "routine" gets numerical value 5 and "flash-override-override" gets numerical value 0 🫶
8. Acknowledgments 🌸
We'd like to thank An Nguyen for encouraging us to tackle this topic and for ongoing comments 🥰 This document also borrows heavily from some of the work of S. Herzog on the Preemption Priority Policy Element [RFC3181]. Dave Oran and Janet Gunn gave useful input for this document. Ron Bonica, Magnus Westerlund, Cullen Jennings, Ross Callon, and Tim Polk provided specific guidance for the applicability statement of the mechanisms defined here, so huge shoutout to all of them 🧚✨
9. References 📚
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
RFC 3181, October 2001.
[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.
[RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg,
"Integration of Resource Management and Session Initiation
Protocol (SIP)", RFC 3312, October 2002.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)", RFC
4412, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC6398] Le Faucheur, F., Ed., "IP Router Alert Considerations and
Usage", BCP 168, RFC 6398, October 2011.9.2. Informative References
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February
1997.
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
RFC 2711, October 1999.
[RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework
for Policy-based Admission Control", RFC 2753, January
2000.
[RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering", RFC 4125, June 2005.
[RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth
Constraints Model for Diffserv-aware MPLS Traffic
Engineering & Performance Comparisons", RFC 4126, June
2005.
[RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints
Model for Diffserv-aware MPLS Traffic Engineering", RFC
4127, June 2005.
[RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security
Properties", RFC 4230, December 2005.
[RFC4495] Polk, J. and S. Dhesikan, "A Resource Reservation Protocol
(RSVP) Extension for the Reduction of Bandwidth of a
Reservation Flow", RFC 4495, May 2006.
[RFC5974] Manner, J., Karagiannis, G., and A. McDonald, "NSIS
Signaling Layer Protocol (NSLP) for Quality-of-Service
Signaling", RFC 5974, October 2010.
[RFC6411] Behringer, M., Le Faucheur, F., and B. Weis,
"Applicability of Keying Methods for RSVP Security", RFC
6411, October 2011.Appendix A. Examples of Bandwidth Allocation Model for Admission Priority 🦋
Appendices A.1 and A.2 show how the Maximum Allocation Model (MAM) [RFC4125] and the Russian Dolls Model (RDM) [RFC4127] can be used to support admission priority, respectively. The Maximum Allocation model with Reservation (MAR) [RFC4126] can also be used in a similar way for supporting admission priority. Appendix A.3 shows how a simple "Priority Bypass Model" can also be used for supporting admission priority 💅
For simplicity, these examples only illustrate operations with a single "priority" level (beyond non-priority). You'll totally get that operations with multiple priority levels can be supported with these models too 🧠
In all the figures below:
xrepresents a non-priority sessionorepresents a priority session
Fr fr, the registry rules in here are the part you'll be quoting the most, so screenshot them 📸💜
A.1. Admission Priority with Maximum Allocation Model (MAM) 🎀
okay bestie, so this part shows how admission priority works when we use the Maximum Allocation Model (MAM) 💅 for splitting bandwidth between non-priority traffic and priority traffic. The big thing to know about MAM is that priority traffic can't use more than the bandwidth set aside for it, even if the non-priority traffic isn't using all of its share 🧚
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
(1)(2)(3) | | . available
Engi- . . . | | . for non-priority use
neered .or.or. | | .
. . . | | .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
Figure 4: MAM Bandwidth AllocationFigure 4 shows a link inside a routed network that follows this document 🌸 There are two chunks of bandwidth on it, one for non-priority traffic and one for priority traffic.
If the non-priority traffic hits the max bandwidth allowed for non-priority, no more non-priority sessions can get in, even if the priority chunk isn't fully used right now 😭
With MAM, when the priority load hits the max bandwidth reserved for priority sessions, no more priority sessions can get in either. Rude, but that's the rule 💀
As Figure 4 shows, an operator can map MAM onto the engineered capacity limits in different ways 🦋 At one extreme, the priority traffic is reliably known to stay pretty small all the time, and there's some safety margin baked into the engineered capacity limits. In that case the operator might set the non-priority bandwidth to the full engineered capacity limits. That basically lets priority traffic ride inside the safety margin of that capacity. This is economically hot 🔥 because all of the engineered capacity goes to non-priority sessions. This policy is illustrated as (1) in Figure 4. For example, if the engineered capacity limit on a link is X, the operator could set non-priority bandwidth to X and priority bandwidth to 5% of X.
At the other extreme, the priority traffic might get pretty heavy at times and the engineered capacity limits are very tight. Then the operator might set the non-priority bandwidth and the priority bandwidth so their sum equals the engineered capacity limits. This makes sure the total load across both kinds of traffic always stays below the engineered capacity, so there's never any QoS degradation ✨ The catch is that it's less economically attractive, because non-priority sessions can't use the full engineered capacity even when there's little or no priority load, which is most of the time 😩 This policy is illustrated as (3) in Figure 4. For example, if the engineered capacity limit on a link is X, the operator could set non-priority bandwidth to 95% of X and priority bandwidth to 5% of X.
And of course, operators can strike a balance anywhere in between these two approaches 🫶 That middle ground is illustrated as (2) in Figure 4.
Figure 5 shows some of the non-priority capacity on this link being used 👀
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v | | v priority use
-------------------------
Figure 5: Partial Load of Non-Priority CallsFigure 6 shows that same amount of non-priority load, plus a small amount of priority bandwidth being used 🌈
-----------------------
^ ^ ^ | | ^
. . . | | .
Total . . . | | . Bandwidth
. . . | | . available
Engi- . . . | | . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 6: Partial Load of Non-Priority Calls and Partial Load of
Priority CallsFigure 7 shows the case where non-priority load equals or goes over the max bandwidth available to non-priority traffic 😤 Notice that extra non-priority sessions would get rejected even though the priority bandwidth isn't fully used.
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . |xxxxxxxxxxxxxx| .
v . . |xxxxxxxxxxxxxx| v
. . |--------------| ---
v . | | ^
. | | . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 7: Full Non-Priority Load and Partial Load of Priority CallsFigure 8 shows the case where priority traffic equals or goes over the bandwidth reserved for it 🔥
In that case, no more priority sessions can be accepted. But hold on, that doesn't mean they get dropped altogether! They might be handled by mechanisms that are outside the scope of this document 🧚 Examples include establishing them by preempting existing non-priority sessions, or queueing new priority session requests until capacity frees up again for priority traffic.
-----------------------
^ ^ ^ |xxxxxxxxxxxxxx| ^
. . . |xxxxxxxxxxxxxx| .
Total . . . |xxxxxxxxxxxxxx| . Bandwidth
. . . |xxxxxxxxxxxxxx| . available
Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use
neered .or.or. |xxxxxxxxxxxxxx| .
. . . |xxxxxxxxxxxxxx| .
Capacity. . . | | .
v . . | | v
. . |--------------| ---
v . |oooooooooooooo| ^
. |oooooooooooooo| . Bandwidth available for
v |oooooooooooooo| v priority use
-------------------------
Figure 8: Partial Non-Priority Load and Full Priority LoadA.2. Admission Priority with Russian Dolls Model (RDM) ✨
okay so this bit is all about admission priority when the Russian Dolls Model (RDM) is splitting bandwidth between non-priority and priority traffic 🎀 the big thing to know is that priority traffic can use bandwidth that non-priority traffic isn't using right now. that's literally the whole point 💅
just like with the MAM, an operator can map the RDM onto the engineered capacity limits in different ways, depending on their policies 🧚 they could give the bandwidth for non-priority use the full engineered capacity limits. for example, if the engineered capacity limit on a link is X, they could set the bandwidth for non-priority traffic to X, and the bandwidth for non-priority and priority traffic to 105% of X 🍓
or they could go the other way and set the bandwidth for non-priority and priority traffic to the engineered capacity limits. for example, if the engineered capacity limit on a link is X, they could set the bandwidth for non-priority traffic to 95% of X, and the bandwidth for non-priority and priority traffic to X 🌸
or they can strike a balance in between 🫶 the considerations from the previous section, the MAM one, apply to RDM just as much.
Figure 9 shows the case where only some of the bandwidth for non-priority traffic is being used, and there's a small amount of priority traffic. in that situation, both new non-priority sessions and new priority sessions would get accepted ✨
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
| | . . available for
| | v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------Figure 9: Partial Non-Priority Load and Partial Aggregate Load
Figure 10 shows the case where all of the bandwidth for non-priority traffic is being used, and a small amount of priority traffic is in place. in that situation, new priority sessions would get accepted, but new non-priority sessions would get rejected 🙈
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
| | . use
| | .
|oooooooooooooo| v
---------------------------------------Figure 10: Full Non-Priority Load and Partial Aggregate Load
Figure 11 shows the case where only some of the bandwidth for non-priority traffic is being used, and there's a heavy load of priority traffic. in that situation, both new non-priority sessions and new priority sessions would get accepted. note that, like we saw in Figure 10, priority sessions use some of the bandwidth that isn't being used by non-priority traffic 👑
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
| | . . Bandwidth
| | . . available for
|oooooooooooooo| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------Figure 11: Partial Non-Priority Load and Heavy Aggregate Load
Figure 12 shows the case where all of the bandwidth for non-priority traffic is being used, and all of the remaining available bandwidth is used by priority traffic. in that situation, new non-priority sessions would get rejected, and new priority sessions could not get accepted right away 💀 those priority sessions may be handled by mechanisms that are beyond the scope of this particular document, like preemption of existing non-priority sessions, or queueing new priority session requests until capacity frees up again for priority traffic 🌈
--------------------------------------
|xxxxxxxxxxxxxx| . ^
|xxxxxxxxxxxxxx| . Bandwidth .
|xxxxxxxxxxxxxx| . available for .
|xxxxxxxxxxxxxx| . non-priority .
|xxxxxxxxxxxxxx| . use .
|xxxxxxxxxxxxxx| . . Bandwidth
|xxxxxxxxxxxxxx| . . available for
|xxxxxxxxxxxxxx| v . non-priority
|--------------| --- . and priority
|oooooooooooooo| . use
|oooooooooooooo| .
|oooooooooooooo| v
---------------------------------------Figure 12: Full Non-Priority Load and Full Aggregate Load
A.3. Admission Priority with Priority Bypass Model (PrBM) 🦋
Okay so this one is the Priority Bypass Model (PrBM), and it's giving simple but iconic 💅. It shows how admission priority works when non-priority and priority traffic share bandwidth. Non-priority traffic gets resource-based admission control, while priority traffic just strolls past that check 🚶♀️✨. Here's the deal:
- When a non-priority session shows up, it goes through bandwidth admission control and gets in only if the current total load (the aggregate of non-priority and priority traffic) is below the engineered/allocated bandwidth.
- When a priority session shows up, it's admitted regardless of the current load.
The big property here is that a priority session is never rejected 🫶. Main character energy for priority calls, periodt.
The reasoning behind this simple scheme is that, in practice, on some networks:
- Priority sessions are very low volume for the vast majority of the time, so it may not be economical to completely set aside bandwidth for them and block normal sessions from using that bandwidth in normal situations 🤷♀️.
- Even during congestion, when priority sessions may be used more heavily, they still make up a fairly small share of the overall load that can be absorbed within the safety margin of the engineered capacity limits. So even if they're admitted beyond the engineered bandwidth threshold, they're unlikely to cause noticeable QoS degradation 🌸.
As with the MAM and RDM, an operator can map the PrBM onto the engineered capacity limits using different policies 🧚. The operator might set the bandwidth limit for admission of non-priority traffic to the full engineered capacity limit. For example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to X. Or the operator could set the non-priority limit below the engineered capacity limits, so that non-priority plus priority traffic stays under the engineered capacity. For example, if the engineered capacity limit on a given link is X, the operator may configure the bandwidth limit for non-priority traffic to 95% of X. Or they can strike a balance somewhere in between 💖. The considerations presented for these policies in the previous sections on the MAM and RDM are equally applicable to the PrBM, so no need to repeat yourself, bestie 😌.
Figure 13 illustrates the bandwidth allocation with the PrBM 🎀:
-----------------------
^ ^ | | ^
. . | | .
Total . . | | . Bandwidth limit
(1) (2) | | . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 13: Priority Bypass Model Bandwidth AllocationFigure 14 shows some of the non-priority capacity on this link being used. In this situation, both new non-priority and new priority sessions would be accepted 💅.
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . | | . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 14: Partial Load of Non-Priority CallsFigure 15 shows the same amount of non-priority load on this link, plus a small amount of priority bandwidth being used. In this situation, both new non-priority and new priority sessions would be accepted 🦋.
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . | | . of non-priority traffic
. . | | .
Capacity. . | | .
v . | | v
. |--------------| ---
. | |
v | |
| |
Figure 15: Partial Load of Non-Priority Calls and Partial Load of
Priority CallsFigure 16 shows the case where the aggregate non-priority and priority load exceeds the bandwidth limit for admission of non-priority traffic. In this situation, any new non-priority session is rejected 🙈, while any new priority session is still admitted 👑.
-----------------------
^ ^ |xxxxxxxxxxxxxx| ^
. . |xxxxxxxxxxxxxx| .
Total . . |xxxxxxxxxxxxxx| . Bandwidth limit
(1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority)
Engi- . . |oooooooooooooo| . for admission
neered . or . |xxxooxxxooxxxo| . of non-priority traffic
. . |xxoxxxxxxoxxxx| .
Capacity. . |oxxxooooxxxxoo| .
v . |xxoxxxooxxxxxx| v
. |--------------| ---
. |oooooooooooooo|
v | |
| |
Figure 16: Full Non-Priority LoadAppendix B. Example Usages of RSVP Extensions ✨
This section shows examples of how the RSVP extensions defined in this document can be used (together with other RSVP and SIP functionality) to enforce different hypothetical policies for handling prioritized sessions in a given administrative domain 🎀. This appendix doesn't add any extra specification. It's only here for illustration purposes 🌈.
We're assuming an environment where SIP is used for session control and RSVP is used for resource reservation 📞.
"Session Queueing" refers to the set of "session-layer" capabilities that SIP user agents may implement to influence how they treat SIP requests. This may include the ability to "queue" session requests when they can't be immediately honored (in some cases with the notion of "bumping", or "displacement", of less important session requests from that queue). It may also include additional mechanisms such as alternate routing and exemption from certain network management controls 🧠.
We only mention below the RSVP policy elements that are to be enforced by PEPs. It's assumed that these policy elements are set at a policy area boundary by PDPs. The Admission Priority and Preemption Priority RSVP policy elements are set by PDPs as a result of processing the Application-Level Resource Priority Policy Element (which is carried in RSVP messages) 💌.
If you want to implement a prioritized service purely based on Session Queueing, you can do that by signaling prioritized sessions:
- using the
"Resource-Priority"header in SIP - not using the Admission-Priority Policy Element in RSVP
- not using the Preemption Policy Element in RSVP
If you want to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", you can do that by signaling prioritized sessions:
- using the
"Resource-Priority"header in SIP - using the Admission-Priority Policy Element in RSVP
- not using the Preemption Policy Element in RSVP
Establishing prioritized sessions will not result in preemption of any session 🙅♀️. Different bandwidth allocation models can be used to offer different "prioritized access to network-layer resources". Just as examples, this includes setting aside capacity exclusively for prioritized sessions, as well as simple bypass of admission limits for prioritized sessions 💫.
If you want to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and you want to ensure that (say) "Prioritized-1" sessions can preempt "Prioritized-2" sessions, but non-prioritized sessions are not affected by preemption, you can do that by signaling prioritized sessions:
- using the
"Resource-Priority"header in SIP - using the Admission-Priority Policy Element in RSVP
- using the Preemption Policy Element in RSVP with:
- setup (Prioritized-1) > defending (Prioritized-2)
- setup (Prioritized-2) <= defending (Prioritized-1)
- setup (Prioritized-1) <= defending (Non-Prioritized)
- setup (Prioritized-2) <= defending (Non-Prioritized)
If you want to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and you want to ensure that prioritized sessions can preempt regular sessions, you could do that by signaling Prioritized sessions:
- using the
"Resource-Priority"header in SIP - using the Admission-Priority Policy Element in RSVP
- using the Preemption Policy Element in RSVP with:
- setup (Prioritized) > defending (Non-Prioritized)
- setup (Non-Prioritized) <= defending (Prioritized)
If you want to implement a prioritized service based on Session Queueing and "prioritized access to network-layer resources", and you want to ensure that prioritized sessions can partially preempt regular sessions (i.e., reduce their reservation size), you could do that by signaling prioritized sessions:
- using the
"Resource-Priority"header in SIP - using the Admission-Priority Policy Element in RSVP
- using the Preemption Policy Element in RSVP with:
- setup (Prioritized) > defending (Non-Prioritized)
- setup (Non-Prioritized) <= defending (Prioritized)
- activate [RFC4495] RSVP bandwidth reduction mechanisms
Authors' Addresses 💌
Francois Le Faucheur
Cisco Systems
Greenside, 400 Avenue de Roumanille
Sophia Antipolis 06410
France
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
James Polk
Cisco Systems
2200 East President George Bush Highway
Richardson, TX 75082-3550
United States
Phone: +1 972 813 5208
EMail: jmpolk@cisco.com
Ken Carlberg
G11
123a Versailles Circle
Towson, MD 21204
United States
EMail: carlberg@g11.org.uk📦 where this page comes from
- ietf: rfc6401 2011-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms