idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 25, 2009) is 5238 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXX' is mentioned on line 716, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-18) exists of draft-ietf-nsis-qos-nslp-17 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-22 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft J. Polk 4 Intended status: Standards Track Cisco 5 Expires: May 29, 2010 K. Carlberg 6 G11 7 November 25, 2009 9 Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority 10 draft-ietf-tsvwg-emergency-rsvp-14.txt 12 Abstract 14 Some applications require the ability to provide an elevated 15 probability of session establishment to specific sessions in times of 16 network congestion. When supported over the Internet Protocol suite, 17 this may be facilitated through a network layer admission control 18 solution that supports prioritized access to resources (e.g., 19 bandwidth). These resources may be explicitly set aside for 20 prioritized sessions, or may be shared with other sessions. This 21 document specifies extensions to the Resource reSerVation Protocol 22 (RSVP) that can be used to support such an admission priority 23 capability at the network layer. 25 Based on current security concerns, these extensions are targeting 26 applicability within a single administrative domain. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on May 29, 2010. 51 Copyright Notice 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 82 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 83 3. Overview of RSVP extensions and Operations . . . . . . . . . . 4 84 3.1. Operations of Admission Priority . . . . . . . . . . . . . 6 85 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7 86 4.1. Admission Priority Policy Element . . . . . . . . . . . . 7 87 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 9 88 4.2. Application-Level Resource Priority Policy Element . . . . 10 89 4.2.1. Application-Level Resource Priority Modifying and 90 Merging Rules . . . . . . . . . . . . . . . . . . . . 11 91 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 11 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 93 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 12 94 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 13 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 96 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 100 Appendix A. Examples of Bandwidth Allocation Model for 101 Admission Priority . . . . . . . . . . . . . . . . . 18 102 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18 103 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 22 104 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 25 105 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 28 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 108 1. Introduction 110 Some applications require the ability to provide an elevated 111 probability of session establishment to specific sessions in times of 112 network congestion. 114 Solutions to meet this requirement for elevated session establishment 115 probability may involve session layer capabilities prioritizing 116 access to resources controlled by the session control function. As 117 an example, entities involved in session control (such as SIP user 118 agents, when the Session Initiation Protocol (SIP) [RFC3261], is the 119 session control protocol in use) can influence their treatment of 120 session establishment requests (such as SIP requests). This may 121 include the ability to "queue" session establishment requests when 122 those can not be immediately honored (in some cases with the notion 123 of "bumping", or "displacement", of less important session 124 establishment requests from that queue). It may include additional 125 mechanisms such as exemption from certain network management 126 controls, and alternate routing. 128 Solutions to meet the requirement for elevated session establishment 129 probability may also take advantage of network layer admission 130 control mechanisms supporting admission priority. Networks usually 131 have engineered capacity limits that characterize the maximum load 132 that can be handled (say, on any given link) for a class of traffic 133 while satisfying the quality of service requirements of that traffic 134 class. Admission priority may involve setting aside some network 135 resources (e.g. Bandwidth) out of the engineered capacity limits for 136 the prioritized sessions only. Or alternatively, it may involve 137 allowing the prioritized sessions to seize additional resources 138 beyond the engineered capacity limits applied to normal sessions. 139 This document specifies the necessary extensions to support such 140 admission priority when network layer admission control is performed 141 using the Resource reSerVation Protocol (RSVP) ([RFC2205]). 143 [RFC3181] specifies the Signaled Preemption Priority Policy Element 144 that can be signaled in RSVP so that network node may take into 145 account this policy element in order to preempt some previously 146 admitted low priority sessions in order to make room for a newer, 147 higher priority session. In contrast, this document specifies new 148 RSVP extensions to increase the probability of session establishment 149 without preemption of existing sessions. This is achieved by 150 engineered capacity techniques in the form of bandwidth allocation 151 models. In particular this document specifies two new RSVP Policy 152 Elements allowing the admission priority to be conveyed inside RSVP 153 signaling messages so that RSVP nodes can enforce selective bandwidth 154 admission control decision based on the session admission priority. 155 Appendix A of this document also provides examples of bandwidth 156 allocation models which can be used by RSVP-routers to enforce such 157 admission priority on every link. A given reservation may be 158 signaled with the admission priority extensions specified in the 159 present document, with the preemption priority specified in [RFC3181] 160 or with both. 162 Based on current security concerns (discussed in Section 5), these 163 extensions are targeting applicability within a single administrative 164 domain. 166 1.1. Terminology 168 This document assumes the terminology defined in [RFC2753]. For 169 convenience, the definition of a few key terms is repeated here: 171 o Policy Decision Point (PDP): The point where policy decisions are 172 made. 174 o Local Policy Decision Point (LPDP): PDP local to the network 175 element. 177 o Policy Enforcement Point (PEP): The point where the policy 178 decisions are actually enforced. 180 o Policy Ignorant Node (PIN): A network element that does not 181 explicitly support policy control using the mechanisms defined in 182 [RFC2753]. 184 2. Requirements Language 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 3. Overview of RSVP extensions and Operations 192 Let us consider the case where a session requires elevated 193 probability of establishment, and more specifically that the 194 preference to be granted to this session is in terms of network layer 195 "admission priority" (as opposed to preference granted through 196 preemption of existing sessions). By "admission priority" we mean 197 allowing the priority session to seize network layer resources from 198 the engineered capacity that has been set-aside for priority sessions 199 (and not made available to normal sessions), or alternatively 200 allowing the priority session to seize additional resources beyond 201 the engineered capacity limits applied to normal sessions. 203 Session establishment can be made conditional on resource-based and 204 policy-based network layer admission control achieved via RSVP 205 signaling. In the case where the session control protocol is SIP, 206 the use of RSVP-based admission control in conjunction with SIP is 207 specified in [RFC3312]. 209 Devices involved in the session establishment are expected to be 210 aware of the application-level priority requirements of prioritized 211 sessions. For example, considering the case where the session 212 control protocol is SIP, the SIP user agents may be made aware of the 213 resource priority requirements of a given session using the 214 "Resource-Priority" header mechanism specified in [RFC4412]. The 215 end-devices involved in the upper-layer session establishment simply 216 need to copy the application-level resource priority requirements 217 (e.g. As communicated in SIP "Resource-Priority" header) inside the 218 new RSVP Application-Level Resource Priority Policy Element defined 219 in this document. 221 Conveying the application-level resource priority requirements inside 222 the RSVP message allows this application level requirement to be 223 mapped/remapped into a different RSVP "admission priority" at a 224 policy boundary based on the policy applicable in that policy area. 225 In a typical model (see [RFC2753]) where PDPs control PEPs at the 226 periphery of the policy area (e.g. On the first hop router), PDPs 227 would interpret the RSVP Application-Level Resource Priority Policy 228 Element and map the requirement of the prioritized session into an 229 RSVP "admission priority" level. Then, PDPs would convey this 230 information inside the new Admission Priority Policy Element defined 231 in this document. This way, the RSVP admission priority can be 232 communicated to downstream PEPs (i.e. RSVP Routers) of the same 233 policy domain, which have LPDPs but no controlling PDP. In turn, 234 this means the necessary RSVP Admission priority can be enforced at 235 every RSVP hop, including all the (possibly many) hops which do not 236 have any understanding of Application-Level Resource Priority 237 semantics. It is not expected that the RSVP Application-Level 238 Resource Priority Header Policy Element would be taken into account 239 at RSVP-hops within a given policy area. It is expected to be used 240 at policy area boundaries only in order to set/reset the RSVP 241 Admission Priority Policy Element. 243 Remapping by PDPs of the Admission Priority Policy Element from the 244 Application-Level Resource Priority Policy Element may also be used 245 at boundaries with other signaling protocols, such as the NSIS 246 Signaling Layer Protocol (NSLP) for QoS Signaling 247 ([I-D.ietf-nsis-qos-nslp]). 249 As can be observed, the framework described above for mapping/ 250 remapping application level resource priority requirements into an 251 RSVP admission priority can also be used together with [RFC3181] for 252 mapping/remapping application level resource priority requirements 253 into an RSVP preemption priority (when preemption is indeed deemed 254 necessary by the prioritized session handling policy). In that case, 255 when processing the RSVP Application-Level Resource Priority Policy 256 Element, the PDPs at policy boundaries (or between various QoS 257 signaling protocols) can map it into an RSVP "preemption priority" 258 information. This Preemption priority information comprises a setup 259 preemption level and a defending preemption priority level that can 260 then be encoded inside the Preemption Priority Policy Element of 261 [RFC3181]. 263 Appendix B provides examples of various hypothetical policies for 264 prioritized session handling, some of them involving admission 265 priority, some of them involving both admission priority and 266 preemption priority. Appendix B also identifies how the Application- 267 Level Resource Priority needs to be mapped into RSVP policy elements 268 by the PDPs to realize these policies. 270 3.1. Operations of Admission Priority 272 The RSVP Admission Priority policy element defined in this document 273 allows admission bandwidth to be allocated preferentially to 274 prioritized sessions. Multiple models of bandwidth allocation MAY be 275 used to that end. 277 A number of bandwidth allocation models have been defined in the IETF 278 for allocation of bandwidth across different classes of traffic 279 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 280 Those include the Maximum Allocation Model (MAM) defined in 281 [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and 282 the Maximum Allocation model with Reservation (MAR) defined in 283 [RFC4126]. These same models MAY however be applied for allocation 284 of bandwidth across different levels of admission priority as defined 285 in this document. Appendix A provides an illustration of how these 286 bandwidth allocation models can be applied for such purposes and also 287 introduces an additional bandwidth allocation model that we term the 288 Priority Bypass Model (PrBM). It is important to note that the 289 models described and illustrated in Appendix A are only informative 290 and do not represent a recommended course of action. 292 We can see in these examples how the RSVP Admission Priority can be 293 used by RSVP routers to influence their admission control decision 294 (for example by determining which bandwidth pool is to be used by 295 RSVP for performing its bandwidth allocation) and therefore to 296 increase the probability of reservation establishment. In turn, this 297 increases the probability of application level session establishment 298 for the corresponding session. 300 4. New Policy Elements 302 The Framework document for policy-based admission control [RFC2753] 303 describes the various components that participate in policy decision 304 making (i.e., PDP, PEP and LPDP). 306 As described in Section 3 of the present document, the Application- 307 Level Resource Priority Policy Element and the Admission Priority 308 Policy Element serve different roles in this framework: 310 o the Application-Level Resource Priority Policy Element conveys 311 application level information and is processed by PDPs 313 o the emphasis of Admission Priority Policy Element is to be simple, 314 stateless, and light-weight such that it can be processed 315 internally within a node's LPDP. It can then be enforced 316 internally within a node's PEP. It is set by PDPs based on 317 processing of the Application-Level Resource Priority Policy 318 Element. 320 [RFC2750] defines extensions for supporting generic policy based 321 admission control in RSVP. These extensions include the standard 322 format of POLICY_DATA objects and a description of RSVP handling of 323 policy events. 325 The POLICY_DATA object contains one or more of Policy Elements, each 326 representing a different (and perhaps orthogonal) policy. As an 327 example, [RFC3181] specifies the Preemption Priority Policy Element. 328 This document defines two new Policy Elements called: 330 o the Admission Priority Policy Element 332 o the Application-Level Resource Priority Policy Element 334 4.1. Admission Priority Policy Element 336 The format of the Admission Priority policy element is as shown in 337 Figure 1: 339 0 0 0 1 1 2 2 3 340 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 341 +-------------+-------------+-------------+-------------+ 342 | Length | P-Type = ADMISSION_PRI | 343 +-------------+-------------+-------------+-------------+ 344 | Flags | M. Strategy | Error Code | Reserved | 345 +-------------+-------------+-------------+-------------+ 346 | Reserved |Adm. Priority| 347 +---------------------------+---------------------------+ 349 Figure 1: Admission Priority Policy Element 351 where: 353 o Length: 16 bits 355 * Always 12. The overall length of the policy element, in bytes. 357 o P-Type: 16 bits 359 * ADMISSION_PRI = To be allocated by IANA (see "IANA 360 Considerations" section) 362 o Flags: Reserved 364 * SHALL be set to zero on transmit and SHALL be ignored on 365 reception 367 o Merge Strategy: 8 bits (applicable to multicast flows) 369 * values are defined by corresponding registry maintained by IANA 370 (see "IANA Considerations" section) 372 o Error code: 8 bits (applicable to multicast flows) 374 * values are defined by corresponding registry maintained by IANA 375 (see "IANA Considerations" section) 377 o Reserved: 8 bits 379 * SHALL be set to zero on transmit and SHALL be ignored on 380 reception 382 o Reserved: 24 bits 384 * SHALL be set to zero on transmit and SHALL be ignored on 385 reception 387 o Adm. Priority (Admission Priority): 8 bits (unsigned) 389 * The admission control priority of the flow, in terms of access 390 to network bandwidth in order to provide higher probability of 391 session completion to selected flows. Higher values represent 392 higher priority. A given Admission Priority is encoded in this 393 information element using the same value as when encoded in the 394 "Admission Priority" field of the "Admission Priority" 395 parameter defined in [I-D.ietf-nsis-qspec]. In other words, a 396 given value inside the Admission Priority information element 397 defined in the present document or inside the 398 [I-D.ietf-nsis-qspec] Admission Priority field refers to the 399 same admission priority. Bandwidth allocation models such as 400 those described in Appendix A are to be used by the RSVP router 401 to achieve increased probability of session establishment. The 402 admission priority value effectively indicates which bandwidth 403 constraint(s) of the bandwidth constraint model in use is(are) 404 applicable to admission of this RSVP reservation. 406 Note that the Admission Priority Policy Element does NOT indicate 407 that this RSVP reservation is to preempt any other RSVP reservation. 408 If a priority session justifies both admission priority and 409 preemption priority, the corresponding RSVP reservation needs to 410 carry both an Admission Priority Policy Element and a Preemption 411 Priority Policy Element. The Admission Priority and Preemption 412 Priority are handled by LPDPs and PEPs as separate mechanisms. They 413 can be used one without the other, or they can be used both in 414 combination. 416 4.1.1. Admission Priority Merging Rules 418 This section discusses alternatives for dealing with RSVP admission 419 priority in case of merging of reservations. As merging applies to 420 multicast, this section also applies to multicast sessions. 422 The rules for merging Admission Priority Policy Elements are defined 423 by the value encoded inside the Merge Strategy field in accordance 424 with the corresponding IANA registry. The merge strategies (and 425 associated values) defined by the present document are the same as 426 those defined in [RFC3181] for merging Preemption Priority Policy 427 Elements (see "IANA Considerations" section). 429 The only difference from [RFC3181] is that this document does not 430 recommend any merge strategies for Admission Priority, while 431 [RFC3181] recommends the first of these merge strategies for 432 Preemption Priority. Note that with the Admission Priority (as is 433 the case with the Preemption Priority), "Take highest priority" 434 translates into "take the highest numerical value". 436 4.2. Application-Level Resource Priority Policy Element 438 The format of the Application-Level Resource Priority policy element 439 is as shown in Figure 2: 441 0 0 0 1 1 2 2 3 442 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 443 +-------------+-------------+-------------+-------------+ 444 | Length | P-Type = APP_RESOURCE_PRI | 445 +-------------+-------------+-------------+-------------+ 446 // ALRP List // 447 +---------------------------+---------------------------+ 449 Figure 2: Application-Level Resource Priority Policy Element 451 where: 453 o Length: 455 * The length of the policy element (including the Length and 456 P-Type) is in number of octets (MUST be a multiple of 4) and 457 indicates the end of the ALRP list. 459 o P-Type: 16 bits 461 * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA 462 Considerations" section) 464 o ALRP List: 466 * List of ALRP where each ALRP is encoded as shown in Figure 3. 468 ALRP: 469 0 0 0 1 1 2 2 3 470 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 471 +---------------------------+-------------+-------------+ 472 | ALRP Namespace | Reserved |ALRP Value | 473 +---------------------------+---------------------------+ 475 Figure 3: Application-Level Resource Priority 477 where: 479 o ALRP Namespace (Application-Level Resource Priority Namespace): 16 480 bits (unsigned) 482 * Contains a numerical value identifying the namespace of the 483 application-level resource priority. This value is encoded as 484 per the "Resource Priority Namespaces" IANA registry. (See 485 IANA Considerations section for the request to IANA to extend 486 the registry to include this numerical value). 488 o Reserved: 8 bits 490 * SHALL be set to zero on transmit and SHALL be ignored on 491 reception. 493 o ALRP Value: (Application-Level Resource Priority Value): 8 bits 494 (unsigned) 496 * Contains the priority value within the namespace of the 497 application-level resource priority. This value is encoded as 498 per the "Resource Priority Priority-Value" IANA registry. (See 499 IANA Considerations section for the request to IANA to extend 500 the registry to include this numerical value). 502 4.2.1. Application-Level Resource Priority Modifying and Merging Rules 504 When POLICY_DATA objects are protected by integrity, LPDPs should not 505 attempt to modify them. They MUST be forwarded as-is to ensure their 506 security envelope is not invalidated. 508 In case of multicast, when POLICY_DATA objects are not protected by 509 integrity, LPDPs MAY merge incoming Application-Level Resource 510 Priority elements to reduce their size and number. When they do 511 merge those, LPDPs MUST do so according to the following rule: 513 o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST 514 contain all the ALRPs appearing in the ALRP List of an incoming 515 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 516 once. In other words, the outgoing ALRP List is the union of the 517 incoming ALRP Lists that are merged. 519 As merging applies to Multicast, this rule also applies to Multicast 520 sessions. 522 4.3. Default Handling 524 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 525 (PINs) implement a default handling of POLICY_DATA objects ensuring 526 that those objects can traverse PIN nodes in transit from one PEP to 527 another. This applies to the situations where POLICY_DATA objects 528 contain the Admission Priority Policy Element and the ALRP Policy 529 Element specified in this document, so that those can traverse PIN 530 nodes. 532 Section 4.2 of [RFC2750] also defines a similar default behavior for 533 policy-capable nodes that do not recognized a particular Policy 534 Element. This applies to the Admission Priority Policy Element and 535 the ALRP Policy Element specified in this document, so that those can 536 traverse policy-capable nodes that do not support these extensions 537 defined in the present document. 539 5. Security Considerations 541 As this document defines extensions to RSVP, the security 542 considerations of RSVP apply. Those are discussed in [RFC2205], 543 [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches 544 for addressing those concerns are discussed further below. 546 A subset of RSVP messages are signaled with the Router Alert Option 547 (RAO)([RFC2113],[RFC2711]). The security aspects and common 548 practices around the use of the current IP Router Alert option and 549 consequences on the use of IP Router Alert by applications such as 550 RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations]. 551 As mentioned earlier, based on current security concerns (some of 552 them associated with RAO), the extensions defined in this document 553 are targeting applicability within a single administrative domain. 555 The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in 556 this document are signaled by RSVP through encapsulation in a Policy 557 Data object as defined in [RFC2750]. Therefore, like any other 558 Policy Elements, their integrity can be protected as discussed in 559 section 6 of [RFC2750] by two optional security mechanisms. The 560 first mechanism relies on RSVP Authentication as specified in 561 [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP 562 nodes are policy capable. With this mechanism, the INTEGRITY object 563 is carried inside RSVP messages. The second mechanism relies on the 564 INTEGRITY object within the POLICY_DATA object to guarantee integrity 565 between RSVP Policy Enforcement Points (PEPs) that are not RSVP 566 neighbors. 568 5.1. Use of RSVP Authentication between RSVP neighbors 570 RSVP authentication can be used between RSVP neighbors that are 571 policy capable. RSVP Authentication (defined in [RFC2747] and 572 [RFC3097]) SHOULD be supported by an implementation of the present 573 document. 575 With RSVP authentication, the RSVP neighbors use shared keys to 576 compute the cryptographic signature of the RSVP message. 577 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key 578 provisioning methods as well as their respective applicability. 580 5.2. Use of INTEGRITY object within the POLICY_DATA object 582 The INTEGRITY object within the POLICY_DATA object can be used to 583 guarantee integrity between non-neighboring RSVP PEPs. This is 584 useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). 585 The INTEGRITY object within the POLICY_DATA object MAY be supported 586 by an implementation of the present document. 588 Details for computation of the content of the INTEGRITY object can be 589 found in Appendix B of [RFC2750]. This states that the Policy 590 Decision Point (PDP), at its discretion, and based on destination 591 PEP/PDP or other criteria, selects an Authentication Key and the hash 592 algorithm to be used. Keys to be used between PDPs can be 593 distributed manually or via standard key management protocol for 594 secure key distribution. 596 Note that where non-RSVP hops may exist in between RSVP hops, as well 597 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 598 between PEPs, it may be difficult for the PDP to determine what is 599 the destination PDP for a POLICY_DATA object contained in some RSVP 600 messages (such as a Path message). This is because in those cases 601 the next PEP is not known at the time of forwarding the message. In 602 this situation, key shared across multiple PDPs may be used. This is 603 conceptually similar to the use of key shared across multiple RSVP 604 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 605 We observe also that this issue may not exist in some deployment 606 scenarios where a single (or low number of) PDP is used to control 607 all the PEPs of a region (such as an administrative domain). In such 608 scenarios, it may be easy for a PDP to determine what is the next hop 609 PDP, even when the next hop PEP is not known, simply by determining 610 what is the next region that will be traversed (say based on the 611 destination address). 613 6. IANA Considerations 615 As specified in [RFC2750], Standard RSVP Policy Elements (P-type 616 values) are to be assigned by IANA as per "IETF Consensus" policy 617 following the policies outlined in [RFC2434] (this policy is now 618 called "IETF Review" as per [RFC5226]) . 620 IANA needs to allocate two P-Types from the Standard RSVP Policy 621 Element range: 623 o one P-Type to the Admission Priority Policy Element 625 o one P-Type to the Application-Level Resource Priority Policy 626 Element. 628 In section 3.1, the present document defines a Merge Strategy field 629 inside the Admission Priority policy element. IANA needs to create a 630 registry for this field and allocate the following values: 632 o 1: Take priority of highest QoS 634 o 2: Take highest priority 636 o 3: Force Error on heterogeneous merge 638 Following the policies outlined in [RFC5226], numbers in the range 639 4-127 are allocated according to the "IETF Review" policy, numbers in 640 the range 128-240 as "First Come First Served" and numbers between 641 241-255 are reserved for "Private Use". Value 0 is Reserved (for 642 consistency with [RFC3181] Merge Strategy values). 644 In section 3.1, the present document defines an Error Code field 645 inside the Admission Priority policy element. IANA needs to create a 646 registry for this field and allocate the following values: 648 o 0: NO_ERROR Value used for regular ADMISSION_PRI elements 650 o 2: HETEROGENEOUS This element encountered heterogeneous merge 652 Following the policies outlined in [RFC5226], numbers in the range 653 3-127 are allocated according to the "IETF Review" policy, numbers in 654 the range 128-240 as "First Come First Served" and numbers between 655 241-255 are reserved for "Private Use". Value 1 is Reserved (for 656 consistency with [RFC3181] Error Code values). 658 The present document defines an ALRP Namespace field in section 3.2 659 that contains a numerical value identifying the namespace of the 660 application-level resource priority. The IANA already maintains the 661 Resource-Priority Namespaces registry (under the SIP Parameters) 662 listing all such namespace. However, that registry does not 663 currently allocate a numerical value to each namespace. Hence, this 664 document requests the IANA to extend the Resource-Priority Namespaces 665 registry in the following ways: 667 o a new column should be added to the registry 669 o the title of the new column should be "Namespace Numerical Value 670 *" 672 o in the Legend, add a line saying "Namespace Numerical Value = the 673 unique numerical value identifying the namespace" 675 o add a line at the bottom of the registry stating the following "* 676 : [RFCXXX] " where XXX is the RFC number of the present document 678 o allocate an actual numerical value to each namespace in the 679 registry and state that value in the new "Namespace numerical 680 Value *" column. 682 A numerical value should be allocated immediately by IANA to all 683 existing namespaces. Then, in the future, IANA should automatically 684 allocate a numerical value to any new namespace added to the 685 registry. 687 The present document defines an ALRP Priority field in section 3.2 688 that contains a numerical value identifying the actual application- 689 level resource priority within the application-level resource 690 priority namespace. The IANA already maintains the Resource-Priority 691 Priority-values registry (under the SIP Parameters) listing all such 692 priorities. However, that registry does not currently allocate a 693 numerical value to each priority-value. Hence, this document 694 requests the IANA to extend the Resource-Priority Priority-Values 695 registry in the following ways: 697 o for each namespace, the registry should be structured with two 698 columns 700 o the title of the first column should read "Priority Values (least 701 to greatest)" 703 o the first column should list all the values currently defined in 704 the registry (e.g. For the drsn namespace: "routine", "priority", 705 "immediate", "flash", "flash-override", "flash-override-override" 706 for the drsn namespace) 708 o the title of the second column should read "Priority Numerical 709 Value *" 711 o At the bottom of the registry, add a "Legend" with a line saying 712 "Priority Numerical Value = the unique numerical value identifying 713 the priority within a namespace" 715 o add a line at the bottom of the registry stating the following "* 716 : [RFCXXX] " where XXX is the RFC number of the present document 718 o allocate an actual numerical value to each and state that value in 719 the new "Priority Numerical Value *" column. 721 A numerical value should be allocated immediately by IANA to all 722 existing priorities. Then, in the future, IANA should automatically 723 allocate a numerical value to any new namespace added to the 724 registry. The numerical value must be unique within each namespace. 725 For the initial allocation, within each namespace, values should be 726 allocated in decreasing order ending with 0 (so that the greatest 727 priority is always allocated value 0). For example, in the drsn 728 namespace, "routine" would be allocated numerical value 5 and "flash- 729 override-override" would be allocated numerical value 0. 731 7. Acknowledgments 733 We would like to thank An Nguyen for his encouragement to address 734 this topic and ongoing comments. Also, this document borrows heavily 735 from some of the work of S. Herzog on Preemption Priority Policy 736 Element [RFC3181]. Dave Oran and Janet Gunn provided useful input 737 into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings, 738 and Ross Callon provided specific guidance for the applicability 739 statement of the mechanisms defined in this document. 741 8. References 743 8.1. Normative References 745 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 746 Requirement Levels", BCP 14, RFC 2119, March 1997. 748 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 749 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 750 Functional Specification", RFC 2205, September 1997. 752 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 753 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 754 October 1998. 756 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 757 Authentication", RFC 2747, January 2000. 759 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 760 RFC 2750, January 2000. 762 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 763 Authentication -- Updated Message Type Value", RFC 3097, 764 April 2001. 766 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 767 RFC 3181, October 2001. 769 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 770 A., Peterson, J., Sparks, R., Handley, M., and E. 771 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 772 June 2002. 774 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 775 "Integration of Resource Management and Session Initiation 776 Protocol (SIP)", RFC 3312, October 2002. 778 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 779 Priority for the Session Initiation Protocol (SIP)", 780 RFC 4412, February 2006. 782 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 783 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 784 May 2008. 786 8.2. Informative References 788 [I-D.ietf-nsis-qos-nslp] 789 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 790 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-17 791 (work in progress), October 2009. 793 [I-D.ietf-nsis-qspec] 794 Bader, A., Ash, G., Kappler, C., and D. Oran, "QoS NSLP 795 QSPEC Template", draft-ietf-nsis-qspec-22 (work in 796 progress), November 2009. 798 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 799 Behringer, M. and F. Faucheur, "Applicability of Keying 800 Methods for RSVP Security", 801 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 802 progress), June 2009. 804 [I-D.rahman-rtg-router-alert-considerations] 805 Faucheur, F., "IP Router Alert Considerations and Usage", 806 draft-rahman-rtg-router-alert-considerations-03 (work in 807 progress), October 2009. 809 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 810 February 1997. 812 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 813 RFC 2711, October 1999. 815 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 816 for Policy-based Admission Control", RFC 2753, 817 January 2000. 819 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 820 Constraints Model for Diffserv-aware MPLS Traffic 821 Engineering", RFC 4125, June 2005. 823 [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth 824 Constraints Model for Diffserv-aware MPLS Traffic 825 Engineering & Performance Comparisons", RFC 4126, 826 June 2005. 828 [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints 829 Model for Diffserv-aware MPLS Traffic Engineering", 830 RFC 4127, June 2005. 832 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 833 Properties", RFC 4230, December 2005. 835 Appendix A. Examples of Bandwidth Allocation Model for Admission 836 Priority 838 Sections A.1 and A.2 respectively illustrate how the Maximum 839 Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) 840 ([RFC4127]) can be used for support of admission priority. The 841 Maximum Allocation model with Reservation (MAR) ([RFC4126]) could 842 also be used in a similar manner for support of admission priority. 843 Section A.3 illustrates how a simple "Priority Bypass Model" can also 844 be used for support of admission priority. 846 For simplicity, operations with only a single "priority" level 847 (beyond non-priority) are illustrated here; However, the reader will 848 appreciate that operations with multiple priority levels can easily 849 be supported with these models. 851 In all the figures below: 853 x represents a non-priority session 855 o represents a priority session 857 A.1. Admission Priority with Maximum Allocation Model (MAM) 859 This section illustrates operations of admission priority when a 860 Maximum Allocation Model (MAM) is used for bandwidth allocation 861 across non-priority traffic and priority traffic. A property of the 862 Maximum Allocation Model is that priority traffic can not use more 863 than the bandwidth made available to priority traffic (even if the 864 non-priority traffic is not using all of the bandwidth available for 865 it). 867 ----------------------- 868 ^ ^ ^ | | ^ 869 . . . | | . 870 Total . . . | | . Bandwidth 871 (1)(2)(3) | | . Available 872 Engi- . . . | | . for non-priority use 873 neered .or.or. | | . 874 . . . | | . 875 Capacity. . . | | . 876 v . . | | v 877 . . |--------------| --- 878 v . | | ^ 879 . | | . Bandwidth available for 880 v | | v priority use 881 ------------------------- 883 Figure 4: MAM Bandwidth Allocation 885 Figure 4 shows a link within a routed network conforming to this 886 document. On this link are two amounts of bandwidth available to two 887 types of traffic: non-priority and priority. 889 If the non-priority traffic load reaches the maximum bandwidth 890 available for non-priority, no additional non-priority sessions can 891 be accepted even if the bandwidth reserved for priority traffic is 892 not currently fully utilized. 894 With the Maximum Allocation Model, in the case where the priority 895 load reaches the maximum bandwidth reserved for priority sessions, no 896 additional priority sessions can be accepted. 898 As illustrated in Figure 4, an operator may map the MAM model onto 899 the Engineered Capacity limits according to different policies. At 900 one extreme, where the proportion of priority traffic is reliably 901 known to be fairly small at all times and where there may be some 902 safety margin factored in the engineered capacity limits, the 903 operator may decide to configure the bandwidth available for non- 904 priority use to the full engineered capacity limits; effectively 905 allowing the priority traffic to ride within the safety margin of 906 this engineered capacity. This policy can be seen as an economically 907 attractive approach as all of the engineered capacity is made 908 available to non-priority sessions. This policy is illustrated as 909 (1) in Figure 4. As an example, if the engineered capacity limit on 910 a given link is X, the operator may configure the bandwidth available 911 to non-priority traffic to X, and the bandwidth available to priority 912 traffic to 5% of X. At the other extreme, where the proportion of 913 priority traffic may be significant at times and the engineered 914 capacity limits are very tight, the operator may decide to configure 915 the bandwidth available to non-priority traffic and the bandwidth 916 available to priority traffic such that their sum is equal to the 917 engineered capacity limits. This guarantees that the total load 918 across non-priority and priority traffic is always below the 919 engineered capacity and, in turn, guarantees there will never be any 920 QoS degradation. However, this policy is less attractive 921 economically as it prevents non-priority sessions from using the full 922 engineered capacity, even when there is no or little priority load, 923 which is the majority of time. This policy is illustrated as (3) in 924 Figure 4. As an example, if the engineered capacity limit on a given 925 link is X, the operator may configure the bandwidth available to non- 926 priority traffic to 95% of X, and the bandwidth available to priority 927 traffic to 5% of X. Of course, an operator may also strike a balance 928 anywhere in between these two approaches. This policy is illustrated 929 as (2) in Figure 4. 931 Figure 5 shows some of the non-priority capacity of this link being 932 used. 934 ----------------------- 935 ^ ^ ^ | | ^ 936 . . . | | . 937 Total . . . | | . Bandwidth 938 . . . | | . Available 939 Engi- . . . | | . for non-priority use 940 neered .or.or. |xxxxxxxxxxxxxx| . 941 . . . |xxxxxxxxxxxxxx| . 942 Capacity. . . |xxxxxxxxxxxxxx| . 943 v . . |xxxxxxxxxxxxxx| v 944 . . |--------------| --- 945 v . | | ^ 946 . | | . Bandwidth available for 947 v | | v priority use 948 ------------------------- 950 Figure 5: Partial load of non-priority calls 952 Figure 6 shows the same amount of non-priority load being used at 953 this link, and a small amount of priority bandwidth being used. 955 ----------------------- 956 ^ ^ ^ | | ^ 957 . . . | | . 958 Total . . . | | . Bandwidth 959 . . . | | . Available 960 Engi- . . . | | . for non-priority use 961 neered .or.or. |xxxxxxxxxxxxxx| . 962 . . . |xxxxxxxxxxxxxx| . 963 Capacity. . . |xxxxxxxxxxxxxx| . 964 v . . |xxxxxxxxxxxxxx| v 965 . . |--------------| --- 966 v . | | ^ 967 . | | . Bandwidth available for 968 v |oooooooooooooo| v priority use 969 ------------------------- 971 Figure 6: Partial load of non-priority calls & partial load of 972 priority calls Calls 974 Figure 7 shows the case where non-priority load equates or exceeds 975 the maximum bandwidth available to non-priority traffic. Note that 976 additional non-priority sessions would be rejected even if the 977 bandwidth reserved for priority sessions is not fully utilized. 979 ----------------------- 980 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 981 . . . |xxxxxxxxxxxxxx| . 982 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 983 . . . |xxxxxxxxxxxxxx| . Available 984 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 985 neered .or.or. |xxxxxxxxxxxxxx| . 986 . . . |xxxxxxxxxxxxxx| . 987 Capacity. . . |xxxxxxxxxxxxxx| . 988 v . . |xxxxxxxxxxxxxx| v 989 . . |--------------| --- 990 v . | | ^ 991 . | | . Bandwidth available for 992 v |oooooooooooooo| v priority use 993 ------------------------- 995 Figure 7: Full non-priority load & partial load of priority calls 997 Figure 8 shows the case where the priority traffic equates or exceeds 998 the bandwidth reserved for such priority traffic. 1000 In that case additional priority sessions could not be accepted. 1001 Note that this does not mean that such sessions are dropped 1002 altogether: they may be handled by mechanisms, which are beyond the 1003 scope of this particular document (such as establishment through 1004 preemption of existing non-priority sessions, or such as queuing of 1005 new priority session requests until capacity becomes available again 1006 for priority traffic). 1008 ----------------------- 1009 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1010 . . . |xxxxxxxxxxxxxx| . 1011 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1012 . . . |xxxxxxxxxxxxxx| . Available 1013 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1014 neered .or.or. |xxxxxxxxxxxxxx| . 1015 . . . |xxxxxxxxxxxxxx| . 1016 Capacity. . . | | . 1017 v . . | | v 1018 . . |--------------| --- 1019 v . |oooooooooooooo| ^ 1020 . |oooooooooooooo| . Bandwidth available for 1021 v |oooooooooooooo| v priority use 1022 ------------------------- 1024 Figure 8: Partial non-priority load & Full priority load 1026 A.2. Admission Priority with Russian Dolls Model (RDM) 1028 This section illustrates operations of admission priority when a 1029 Russian Dolls Model (RDM) is used for bandwidth allocation across 1030 non-priority traffic and priority traffic. A property of the Russian 1031 Dolls Model is that priority traffic can use the bandwidth which is 1032 not currently used by non-priority traffic. 1034 As with the MAM model, an operator may map the RDM model onto the 1035 Engineered Capacity limits according to different policies. The 1036 operator may decide to configure the bandwidth available for non- 1037 priority use to the full engineered capacity limits; As an example, 1038 if the engineered capacity limit on a given link is X, the operator 1039 may configure the bandwidth available to non-priority traffic to X, 1040 and the bandwidth available to non-priority and priority traffic to 1041 105% of X. 1043 Alternatively, the operator may decide to configure the bandwidth 1044 available to non-priority and priority traffic to the engineered 1045 capacity limits; As an example, if the engineered capacity limit on a 1046 given link is X, the operator may configure the bandwidth available 1047 to non-priority traffic to 95% of X, and the bandwidth available to 1048 non-priority and priority traffic to X. 1050 Finally, the operator may decide to strike a balance in between. The 1051 considerations presented for these policies in the previous section 1052 in the MAM context are equally applicable to RDM. 1054 Figure 9 shows the case where only some of the bandwidth available to 1055 non-priority traffic is being used and a small amount of priority 1056 traffic is in place. In that situation both new non-priority 1057 sessions and new priority sessions would be accepted. 1059 -------------------------------------- 1060 |xxxxxxxxxxxxxx| . ^ 1061 |xxxxxxxxxxxxxx| . Bandwidth . 1062 |xxxxxxxxxxxxxx| . Available for . 1063 |xxxxxxxxxxxxxx| . non-priority . 1064 |xxxxxxxxxxxxxx| . use . 1065 |xxxxxxxxxxxxxx| . . Bandwidth 1066 | | . . available for 1067 | | v . non-priority 1068 |--------------| --- . and priority 1069 | | . use 1070 | | . 1071 |oooooooooooooo| v 1072 --------------------------------------- 1074 Figure 9: Partial non-priority load & Partial Aggregate load 1076 Figure 10 shows the case where all of the bandwidth available to non- 1077 priority traffic is being used and a small amount of priority traffic 1078 is in place. In that situation new priority sessions would be 1079 accepted but new non-priority sessions would be rejected. 1081 -------------------------------------- 1082 |xxxxxxxxxxxxxx| . ^ 1083 |xxxxxxxxxxxxxx| . Bandwidth . 1084 |xxxxxxxxxxxxxx| . Available for . 1085 |xxxxxxxxxxxxxx| . non-priority . 1086 |xxxxxxxxxxxxxx| . use . 1087 |xxxxxxxxxxxxxx| . . Bandwidth 1088 |xxxxxxxxxxxxxx| . . available for 1089 |xxxxxxxxxxxxxx| v . non-priority 1090 |--------------| --- . and priority 1091 | | . use 1092 | | . 1093 |oooooooooooooo| v 1094 --------------------------------------- 1096 Figure 10: Full non-priority load & Partial Aggregate load 1098 Figure 11 shows the case where only some of the bandwidth available 1099 to non-priority traffic is being used and a heavy load of priority 1100 traffic is in place. In that situation both new non-priority 1101 sessions and new priority sessions would be accepted. Note that, as 1102 illustrated in Figure 10, priority sessions use some of the bandwidth 1103 currently not used by non-priority traffic. 1105 -------------------------------------- 1106 |xxxxxxxxxxxxxx| . ^ 1107 |xxxxxxxxxxxxxx| . Bandwidth . 1108 |xxxxxxxxxxxxxx| . Available for . 1109 |xxxxxxxxxxxxxx| . non-priority . 1110 |xxxxxxxxxxxxxx| . use . 1111 | | . . Bandwidth 1112 | | . . available for 1113 |oooooooooooooo| v . non-priority 1114 |--------------| --- . and priority 1115 |oooooooooooooo| . use 1116 |oooooooooooooo| . 1117 |oooooooooooooo| v 1118 --------------------------------------- 1120 Figure 11: Partial non-priority load & Heavy Aggregate load 1122 Figure 12 shows the case where all of the bandwidth available to non- 1123 priority traffic is being used and all of the remaining available 1124 bandwidth is used by priority traffic. In that situation new non- 1125 priority sessions would be rejected. In that situation new priority 1126 sessions could not be accepted right away. Those priority sessions 1127 may be handled by mechanisms, which are beyond the scope of this 1128 particular document (such as established through preemption of 1129 existing non-priority sessions, or such as queuing of new priority 1130 session requests until capacity becomes available again for priority 1131 traffic). 1133 -------------------------------------- 1134 |xxxxxxxxxxxxxx| . ^ 1135 |xxxxxxxxxxxxxx| . Bandwidth . 1136 |xxxxxxxxxxxxxx| . Available for . 1137 |xxxxxxxxxxxxxx| . non-priority . 1138 |xxxxxxxxxxxxxx| . use . 1139 |xxxxxxxxxxxxxx| . . Bandwidth 1140 |xxxxxxxxxxxxxx| . . available for 1141 |xxxxxxxxxxxxxx| v . non-priority 1142 |--------------| --- . and priority 1143 |oooooooooooooo| . use 1144 |oooooooooooooo| . 1145 |oooooooooooooo| v 1146 --------------------------------------- 1148 Figure 12: Full non-priority load & Full Aggregate load 1150 A.3. Admission Priority with Priority Bypass Model (PrBM) 1152 This section illustrates operations of admission priority when a 1153 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1154 across non-priority traffic and priority traffic. With the Priority 1155 Bypass Model, non-priority traffic is subject to resource based 1156 admission control while priority traffic simply bypasses the resource 1157 based admission control. In other words: 1159 o when a non-priority session arrives, this session is subject to 1160 bandwidth admission control and is accepted if the current total 1161 load (aggregate over non-priority and priority traffic) is below 1162 the engineered/allocated bandwidth. 1164 o when a priority session arrives, this session is admitted 1165 regardless of the current load. 1167 A property of this model is that a priority session is never 1168 rejected. 1170 The rationale for this simple scheme is that, in practice in some 1171 networks: 1173 o the volume of priority sessions is very low for the vast majority 1174 of time, so it may not be economical to completely set aside 1175 bandwidth for priority sessions and preclude the utilization of 1176 this bandwidth by normal sessions in normal situations 1178 o even in congestion periods where priority sessions may be more 1179 heavily used, those always still represent a fairly small 1180 proportion of the overall load which can be absorbed within the 1181 safety margin of the engineered capacity limits. Thus, even if 1182 they are admitted beyond the engineered bandwidth threshold, they 1183 are unlikely to result in noticeable QoS degradation. 1185 As with the MAM and RDM model, an operator may map the Priority 1186 Bypass model onto the Engineered Capacity limits according to 1187 different policies. The operator may decide to configure the 1188 bandwidth limit for admission of non-priority traffic to the full 1189 engineered capacity limits; As an example, if the engineered capacity 1190 limit on a given link is X, the operator may configure the bandwidth 1191 limit for non-priority traffic to X. Alternatively, the operator may 1192 decide to configure the bandwidth limit for non-priority traffic to 1193 below the engineered capacity limits (so that the sum of the non- 1194 priority and priority traffic stays below the engineered capacity); 1195 As an example, if the engineered capacity limit on a given link is X, 1196 the operator may configure the bandwidth limit for non-priority 1197 traffic to 95% of X. Finally, the operator may decide to strike a 1198 balance in between. The considerations presented for these policies 1199 in the previous sections in the MAM and RDM contexts are equally 1200 applicable to the Priority Bypass Model. 1202 Figure 13 illustrates the bandwidth allocation with the Priority 1203 Bypass Model. 1205 ----------------------- 1206 ^ ^ | | ^ 1207 . . | | . 1208 Total . . | | . Bandwidth Limit 1209 (1) (2) | | . (on non-priority + priority) 1210 Engi- . . | | . for admission 1211 neered . or . | | . of non-priority traffic 1212 . . | | . 1213 Capacity. . | | . 1214 v . | | v 1215 . |--------------| --- 1216 . | | 1217 v | | 1218 | | 1220 Figure 13: Priority Bypass Model Bandwidth Allocation 1222 Figure 14 shows some of the non-priority capacity of this link being 1223 used. In this situation, both new non-priority and new priority 1224 sessions would be accepted. 1226 ----------------------- 1227 ^ ^ |xxxxxxxxxxxxxx| ^ 1228 . . |xxxxxxxxxxxxxx| . 1229 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1230 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1231 Engi- . . | | . for admission 1232 neered . or . | | . of non-priority traffic 1233 . . | | . 1234 Capacity. . | | . 1235 v . | | v 1236 . |--------------| --- 1237 . | | 1238 v | | 1239 | | 1241 Figure 14: Partial load of non-priority calls 1243 Figure 15 shows the same amount of non-priority load being used at 1244 this link, and a small amount of priority bandwidth being used. In 1245 this situation, both new non-priority and new priority sessions would 1246 be accepted. 1248 ----------------------- 1249 ^ ^ |xxxxxxxxxxxxxx| ^ 1250 . . |xxxxxxxxxxxxxx| . 1251 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1252 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1253 Engi- . . |oooooooooooooo| . for admission 1254 neered . or . | | . of non-priority traffic 1255 . . | | . 1256 Capacity. . | | . 1257 v . | | v 1258 . |--------------| --- 1259 . | | 1260 v | | 1261 | | 1263 Figure 15: Partial load of non-priority calls & partial load of 1264 priority calls 1266 Figure 16 shows the case where aggregate non-priority and priority 1267 load exceeds the bandwidth limit for admission of non-priority 1268 traffic. In this situation, any new non-priority session is rejected 1269 while any new priority session is admitted. 1271 ----------------------- 1272 ^ ^ |xxxxxxxxxxxxxx| ^ 1273 . . |xxxxxxxxxxxxxx| . 1274 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1275 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1276 Engi- . . |oooooooooooooo| . for admission 1277 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1278 . . |xxoxxxxxxoxxxx| . 1279 Capacity. . |oxxxooooxxxxoo| . 1280 v . |xxoxxxooxxxxxx| v 1281 . |--------------| --- 1282 . |oooooooooooooo| 1283 v | | 1284 | | 1286 Figure 16: Full non-priority load 1288 Appendix B. Example Usages of RSVP Extensions 1290 This section provides examples of how RSVP extensions defined in this 1291 document can be used (in conjunctions with other RSVP functionality 1292 and SIP functionality) to enforce different hypothetical policies for 1293 handling prioritized sessions in a given administrative domain. This 1294 Appendix does not provide additional specification. It is only 1295 included in this document for illustration purposes. 1297 We assume an environment where SIP is used for session control and 1298 RSVP is used for resource reservation. 1300 We refer here to "Session Queueing" as the set of "session" layer 1301 capabilities that may be implemented by SIP user agents to influence 1302 their treatment of SIP requests. This may include the ability to 1303 "queue" session requests when those can not be immediately honored 1304 (in some cases with the notion of "bumping", or "displacement", of 1305 less important session requests from that queue). It may include 1306 additional mechanisms such as exemption from certain network 1307 management controls, and alternate routing. 1309 We only mention below the RSVP policy elements that are to be 1310 enforced by PEPs. It is assumed that these policy elements are set 1311 at a policy area boundary by PDPs. The Admission Priority and 1312 Preemption Priority RSVP policy elements are set by PDPs as a result 1313 of processing the Application Level Resource Priority Policy Element 1314 (which is carried in RSVP messages). 1316 If one wants to implement a prioritized service purely based on 1317 Session Queueing, one can achieve this by signaling prioritized 1318 sessions: 1320 o using "Resource-Priority" header in SIP 1322 o not using Admission-Priority Policy Element in RSVP 1324 o not using Preemption Policy Element in RSVP 1326 If one wants to implement a prioritized service based on Session 1327 Queueing and on "prioritized access to network layer resources", one 1328 can achieve this by signaling prioritized sessions: 1330 o using "Resource-Priority" header in SIP 1332 o using Admission-Priority Policy Element in RSVP 1334 o not using Preemption Policy Element in RSVP 1336 Establishment of prioritized sessions will not result in preemption 1337 of any session. Different bandwidth allocation models can be used to 1338 offer different "prioritized access to network resources". Just as 1339 examples, this includes strict setting aside of capacity for 1340 prioritized sessions as well as simple bypass of admission limits for 1341 prioritized sessions. 1343 If one wants to implement a prioritized service based on Session 1344 Queueing, on "prioritized access to network layer resources", and 1345 ensures that (say) "Prioritized-1" sessions can preempt 1346 "Prioritized-2" sessions, but non-prioritized sessions are not 1347 affected by preemption, one can do that by signaling prioritized 1348 sessions: 1350 o using "Resource-Priority" header in SIP 1352 o using Admission-Priority Policy Element in RSVP 1354 o using Preemption Policy Element in RSVP with: 1356 * setup (Prioritized-1) > defending (Prioritized-2) 1358 * setup (Prioritized-2) <= defending (Prioritized-1) 1360 * setup (Prioritized-1) <= defending (Non-Prioritized) 1362 * setup (Prioritized-2) <= defending (Non-Prioritized) 1364 If one wants to implement a prioritized service based on Session 1365 Queueing, on "prioritized access to network layer resources", and 1366 ensure that prioritized sessions can preempt regular sessions, one 1367 could do that by signaling Prioritized sessions: 1369 o using "Resource-Priority" header in SIP 1371 o using Admission-Priority Policy Element in RSVP 1373 o using Preemption Policy Element in RSVP with: 1375 * setup (Prioritized) > defending (Non-Prioritized) 1377 * setup (Non-Prioritized) <= defending (Prioritized) 1379 If one wants to implement a prioritized service based on Session 1380 Queueing, on "prioritized access to network layer resources", and 1381 ensure that prioritized sessions can partially preempt regular 1382 sessions (i.e. Reduce their reservation size), one could do that by 1383 signaling prioritized sessions: 1385 o using "Resource-Priority" header in SIP 1387 o using Admission-Priority Policy Element in RSVP 1389 o using Preemption in Policy Element RSVP with: 1391 * setup (Prioritized) > defending (Non-Prioritized) 1393 * setup (Non-Prioritized) <= defending (Prioritized) 1395 o activate RFC4495 RSVP Bandwidth Reduction mechanisms 1397 Authors' Addresses 1399 Francois Le Faucheur 1400 Cisco Systems 1401 Greenside, 400 Avenue de Roumanille 1402 Sophia Antipolis 06410 1403 France 1405 Phone: +33 4 97 23 26 19 1406 Email: flefauch@cisco.com 1407 James Polk 1408 Cisco Systems 1409 2200 East President George Bush Highway 1410 Richardson, TX 75082-3550 1411 United States 1413 Phone: +1 972 813 5208 1414 Email: jmpolk@cisco.com 1416 Ken Carlberg 1417 G11 1418 123a Versailles Circle 1419 Towson, MD 21204 1420 United States 1422 Email: carlberg@g11.org.uk