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