idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1414. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1425. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1432. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1438. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 11, 2008) is 5859 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: 'ITU.I.225' is mentioned on line 138, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 693, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-05 == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-03 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-20 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-00 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 7 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: October 13, 2008 K. Carlberg 6 G11 7 April 11, 2008 9 Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services 10 draft-ietf-tsvwg-emergency-rsvp-07.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on October 13, 2008. 37 Abstract 39 An Emergency Telecommunications Service (ETS) requires the ability to 40 provide an elevated probability of session establishment to an 41 authorized user in times of network congestion (typically, during a 42 crisis). When supported over the Internet Protocol suite, this may 43 be facilitated through a network layer admission control solution, 44 which supports prioritized access to resources (e.g., bandwidth). 45 These resources may be explicitly set aside for emergency services, 46 or they may be shared with other sessions. 48 This document specifies RSVP extensions that can be used to support 49 such an admission priority capability at the network layer. Note 50 that these extensions represent one possible solution component in 51 satisfying ETS requirements. Other solution components, or other 52 solutions, are outside the scope of this document. 54 Requirements Language 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC 2119 [RFC2119]. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Related Technical Documents . . . . . . . . . . . . . . . 4 64 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Overview of RSVP extensions and Operations . . . . . . . . . . 5 66 2.1. Operations of Admission Priority . . . . . . . . . . . . . 7 67 3. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 7 68 3.1. Admission Priority Policy Element . . . . . . . . . . . . 8 69 3.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10 70 3.2. Application-Level Resource Priority Policy Element . . . . 10 71 3.2.1. Application-Level Resource Priority Modifying and 72 Merging Rules . . . . . . . . . . . . . . . . . . . . 12 73 3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 4.1. Use of RSVP Authentication between RSVP nighbors . . . . . 13 76 4.2. Use of INTEGRITY object within the POLICY_DATA object . . 13 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 7.1. Normative References . . . . . . . . . . . . . . . . . . . 16 81 7.2. Informative References . . . . . . . . . . . . . . . . . . 16 82 Appendix A. Examples of Bandwidth Allocation Model for 83 Admission Priority . . . . . . . . . . . . . . . . . 18 84 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 18 85 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 22 86 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 25 87 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 28 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 89 Intellectual Property and Copyright Statements . . . . . . . . . . 32 91 1. Introduction 93 [RFC3689] and [RFC3690] detail requirements for an Emergency 94 Telecommunications Service (ETS), which is an umbrella term 95 identifying those networks and specific services used to support 96 emergency communications. An underlying goal of these documents is 97 to present requirements that elevate the probability of session 98 establishment from an authorized user in times of network congestion 99 (presumably because of a crisis condition). In some extreme cases, 100 the requirement for this probability may reach 100%, but that is a 101 topic subject to policy and most likely local regulation (the latter 102 being outside the scope of this document). 104 Solutions to meet this requirement for elevated session establishment 105 probability may involve session layer capabilities prioritizing 106 access to resources controlled by the session control function. As 107 an example, entities involved in session control (such as SIP user 108 agents, when the Session Initiation Protocol (SIP) [RFC3261], is the 109 session control protocol in use) can influence their treatment of 110 session establishment requests (such as SIP requests). This may 111 include the ability to "queue" call requests when those can not be 112 immediately honored (in some cases with the notion of "bumping", or 113 "displacement", of less important call request from that queue). It 114 may include additional mechanisms such as exemption from certain 115 network management controls, and alternate routing. 117 Solutions to meet the requirement for elevated session establishment 118 probability may also take advantage of network layer admission 119 control mechanisms supporting admission priority. Networks usually 120 have engineered capacity limits that characterize the maximum load 121 that can be handled (say, on any given link) for a class of traffic 122 while satisfying the quality of service requirements of that traffic 123 class. Admission priority may involve setting aside some network 124 resources (e.g. bandwidth) out of the engineered capacity limits for 125 the emergency services only. Or alternatively, it may involve 126 allowing the emergency related sessions to seize additional resources 127 beyond the engineered capacity limits applied to normal calls. 129 Note: Below, this document references several examples of IP 130 telephony and its use of "calls", which is one form of the term 131 "sessions" (Video over IP and Instant Messaging being other examples 132 that rely on session establishment). For the sake of simplicity, we 133 shall use the widely known term "call" for the remainder of this 134 document. 136 1.1. Related Technical Documents 138 [RFC4542] is patterned after [ITU.I.225] and describes an example of 139 one type of prioritized network layer admission control procedure 140 that may be used for emergency services operating over an IP network 141 infrastructure. It discusses initial call set up, as well as 142 operations after call establishment through maintenance of a 143 continuing call model of the status of all calls. [RFC4542] also 144 describes how these network layer admission control procedures can be 145 realized using the Resource reSerVation Protocol [RFC2205] along with 146 its associated protocol suite and extensions, including those for 147 policy based admission control ([RFC2753], [RFC2750]), for user 148 authentication and authorization ([RFC3182]) and for integrity and 149 authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter 150 QoS Application ([I-D.ietf-dime-diameter-qos]) allows network 151 elements to interact with Diameter servers when allocating QoS 152 resources in the network and thus, is also a possible method for 153 authentication and authorization of RSVP reservations in the context 154 of emergency services. 156 [RFC4542] describes how the RSVP Signaled Preemption Priority Policy 157 Element specified in [RFC3181] can be used to enforce the call 158 preemption that may be needed by some emergency services. In 159 contrast to [RFC4542], this document specifies new RSVP extensions to 160 increase the probability of call completion without preemption. 161 Engineered capacity techniques in the form of bandwidth allocation 162 models are used to satisfy the "admission priority" required by an 163 RSVP capable ETS network. In particular this document specifies two 164 new RSVP Policy Elements allowing the admission priority to be 165 conveyed inside RSVP signaling messages so that RSVP nodes can 166 enforce selective bandwidth admission control decision based on the 167 call admission priority. Appendix A of this document also provides 168 examples of bandwidth allocation models which can be used by RSVP- 169 routers to enforce such admission priority on every link. 171 1.2. Terminology 173 This document assumes the terminology defined in [RFC2753]. For 174 convenience, the definition of a few key terms is repeated here: 176 o Policy Decision Point (PDP): The point where policy decisions are 177 made. 179 o Local Policy Decision Point (LPDP): PDP local to the network 180 element. 182 o Policy Enforcement Point (PEP): The point where the policy 183 decisions are actually enforced. 185 o Policy Ignorant Node (PIN): A network element that does not 186 explicitly support policy control using the mechanisms defined in 187 [RFC2753]. 189 2. Overview of RSVP extensions and Operations 191 Let us consider the case where a call requiring ETS type service is 192 to be established, and more specifically that the preference to be 193 granted to this call is in terms of network layer "admission 194 priority" (as opposed to preference granted through preemption of 195 existing calls). By "admission priority" we mean allowing that 196 priority call to seize network layer resources from the engineered 197 capacity that have been set-aside and not made available to normal 198 calls, or alternatively by allowing that call to seize additional 199 resources beyond the engineered capacity limits applied to normal 200 calls. 202 As described in [RFC4542], the session establishment can be 203 conditioned to resource-based and policy-based network layer 204 admission control achieved via RSVP signaling. In the case where the 205 session control protocol is SIP, the use of RSVP-based admission 206 control by SIP is specified in [RFC3312]. 208 Devices involved in the session establishment are expected to be 209 aware of the application-level priority requirements of emergency 210 calls. Again considering the case where the session control protocol 211 is SIP, the SIP user agents can be made aware of the resource 212 priority requirements in the case of an emergency call using the 213 Resource-Priority Header mechanism specified in [RFC4412]. The end- 214 devices involved in the upper-layer session establishment simply need 215 to copy the application-level resource priority requirements (e.g. as 216 communicated in SIP Resource-Priority Header) inside the new RSVP 217 Application-Level Resource-Priority Policy Element defined in this 218 document. 220 Conveying the application-level resource priority requirements inside 221 the RSVP message allows this application level requirement to be 222 mapped/remapped into a different RSVP "admission priority" at every 223 administrative domain boundary based on the policy applicable in that 224 domain. In a typical model (see [RFC2753]) where PDPs control PEPs 225 at the periphery of the policy domain (e.g., in border routers), PDPs 226 would interpret the RSVP Application-Level Resource-Priority Policy 227 Element and map the requirement of the emergency session into an RSVP 228 "admission priority" level. Then, PDPs would convey this information 229 inside the new Admission Priority Policy Element defined in this 230 document. This way, the RSVP admission priority can be communicated 231 to downstream PEPs (ie RSVP Routers) of the same policy domain, which 232 have LPDPs but no controlling PDP. In turn, this means the necessary 233 RSVP Admission priority can be enforced at every RSVP hop, including 234 all the (many) hops which do not have any understanding of 235 Application-Level Resource-Priority semantics. 237 As an example of operation across multiple administrative domains, a 238 first domain might decide to provide network layer admission priority 239 to calls of a given Application Level Resource Priority and map it 240 into a high RSVP admission control priority inside the Admission 241 Priority Policy Element; while a second domain may decide to not 242 provide admission priority to calls of this same Application Level 243 Resource Priority and hence map it into a low RSVP admission control 244 priority. 246 As another example of operation across multiple administrative 247 domains, we can consider the case where the resource priority header 248 enumerates several namespaces, as explicitly allowed by [RFC4412], 249 for support of scenarios where calls traverse multiple administrative 250 domains using different namespace. In that case, the relevant 251 namespace can be used at each domain boundary to map into an RSVP 252 Admission priority for that domain. It is not expected that the RSVP 253 Application-Level Resource-Priority Header Policy Element would be 254 taken into account at RSVP-hops within a given administrative domain. 255 It is expected to be used at administrative domain boundaries only in 256 order to set/reset the RSVP Admission Priority Policy Element. 258 The existence of pre-established inter-domain policy agreements or 259 Service Level Agreements may avoid the need to take real-time action 260 at administrative domain boundaries for mapping/remapping of 261 admission priorities. 263 Mapping/remapping by PDPs may also be applied to boundaries between 264 various signaling protocols, such as those advanced by the NSIS 265 working group. 267 As can be observed, the framework described above for mapping/ 268 remapping application level resource priority requirements into an 269 RSVP admission priority can also be used together with [RFC3181] for 270 mapping/remapping application level resource priority requirements 271 into an RSVP preemption priority (when preemption is indeed needed). 272 In that case, when processing the RSVP Application-Level Resource- 273 Priority Policy Element, the PDPs at boundaries between 274 administrative domains (or between various QoS signaling protocols) 275 can map it into an RSVP "preemption priority" information. This 276 Preemption priority information comprises a setup preemption level 277 and a defending preemption priority level. This preemption priority 278 information can then be encoded inside the Preemption Priority Policy 279 Element of [RFC3181] and thus, can be taken into account at every 280 RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides 281 examples of various hypothetical policies for emergency call 282 handling, some of them involving admission priority, some of them 283 involving both admission priority and preemption priority. Appendix 284 B also identifies how the Application-Level Resource Priority need to 285 be mapped into RSVP policy elements by the PDPs to realize these 286 policies. 288 2.1. Operations of Admission Priority 290 The RSVP Admission Priority policy element defined in this document 291 allows admission bandwidth to be allocated preferentially to an 292 authorized priority service. Multiple models of bandwidth allocation 293 MAY be used to that end. 295 A number of bandwidth allocation models have been defined in the IETF 296 for allocation of bandwidth across different classes of traffic 297 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 298 Those include the Maximum Allocation Model (MAM) defined in 299 [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and 300 the Maximum Allocation model with Reservation (MAR) defined in 301 [RFC4126]. These same models MAY however be applied for allocation 302 of bandwidth across different levels of admission priority as defined 303 in this document. Appendix A provides an illustration of how these 304 bandwidth allocation models can be applied for such purposes and 305 introduces an additional bandwidth allocation model that we term the 306 Priority Bypass Model (PrBM). It is important to note that the 307 models described and illustrated in Appendix A are only informative 308 and do not represent a recommended course of action. 310 We can see in these examples, that the RSVP Admission Priority may 311 effectively influence the fundamental admission control decision of 312 RSVP (for example by determining which bandwidth pool is to be used 313 by RSVP for performing its fundamental bandwidth allocation). In 314 that sense, we observe that the policy control and admission control 315 are not separate logics but instead somewhat blended. 317 3. New Policy Elements 319 The Framework document for policy-based admission control [RFC2753] 320 describes the various components that participate in policy decision 321 making (i.e., PDP, PEP and LPDP). 323 As described in section 2 of the present document, the Application- 324 Level Resource Priority Policy Element and the Admission Priority 325 Policy Element serve different roles in this framework: 327 o the Application-Level Resource Priority Policy Element conveys 328 application level information and is processed by PDPs 330 o the emphasis of Admission Priority Policy Element is to be simple, 331 stateless, and light-weight such that it can be processed 332 internally within a node's LPDP. It can then be enforced 333 internally within a node's PEP. It is set by PDPs based on 334 processing of the Application-Level Resource Priority Policy 335 Element. 337 [RFC2750] defines extensions for supporting generic policy based 338 admission control in RSVP. These extensions include the standard 339 format of POLICY_DATA objects and a description of RSVP handling of 340 policy events. 342 The POLICY_DATA object contains one or more of Policy Elements, each 343 representing a different (and perhaps orthogonal) policy. As an 344 example, [RFC3181] specifies the Preemption Priority Policy Element. 345 This document defines two new Policy Elements called: 347 o the Admission Priority Policy Element 349 o the Application-Level Resource Priority Policy Element 351 3.1. Admission Priority Policy Element 353 The format of the Admission Priority policy element is as shown in 354 Figure 1: 356 0 0 0 1 1 2 2 3 357 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 358 +-------------+-------------+-------------+-------------+ 359 | Length | P-Type = ADMISSION_PRI | 360 +-------------+-------------+-------------+-------------+ 361 | Flags | M. Strategy | Error Code | Reserved | 362 +-------------+-------------+-------------+-------------+ 363 | Reserved |Adm. Priority| 364 +---------------------------+---------------------------+ 366 Figure 1: Admission Priority Policy Element 368 where: 370 o Length: 16 bits 372 * Always 12. The overall length of the policy element, in bytes. 374 o P-Type: 16 bits 376 * ADMISSION_PRI = To be allocated by IANA (see "IANA 377 Considerations" section) 379 o Flags: Reserved 381 * SHALL be set to zero on transmit and SHALL be ignored on 382 reception 384 o Merge Strategy: 8 bits (only applicable to multicast flows) 386 * 1 Take priority of highest QoS 388 * 2 Take highest priority 390 * 3 Force Error on heterogeneous merge (See section 3.1.1) 392 o Error code: 8 bits (only applicable to multicast flows) 394 * 0 NO_ERROR Value used for regular ADMISSION_PRI elements 396 * 2 HETEROGENEOUS This element encountered heterogeneous merge 398 o Reserved: 8 bits 400 * SHALL be set to zero on transmit and SHALL be ignored on 401 reception 403 o Reserved: 24 bits 405 * SHALL be set to zero on transmit and SHALL be ignored on 406 reception 408 o Adm. Priority (Admission Priority): 8 bits (unsigned) 410 * The admission control priority of the flow, in terms of access 411 to network bandwidth in order to provide higher probability of 412 call completion to selected flows. Higher values represent 413 higher Priority. A given Admission Priority is encoded in this 414 information element using the same value as when encoded in the 415 "Admission Priority" field of the "Admission Priority" 416 parameter defined in [I-D.ietf-nsis-qspec], or in the 417 "Admission Priority" parameter defined in 418 [I-D.ietf-dime-qos-parameters]. In other words, a given value 419 inside the Admission Priority information element defined in 420 the present document, inside the [I-D.ietf-nsis-qspec] 421 Admission Priority field or inside the 423 [I-D.ietf-dime-qos-parameters] Admission Priority parameter, 424 refers to the same admission priority. Bandwidth allocation 425 models such as those described in Appendix A are to be used by 426 the RSVP router to achieve such increased probability of call 427 completion. The admission priority value effectively indicates 428 which bandwidth constraint(s) of the bandwidth constraint model 429 in use is(are) applicable to admission of this RSVP 430 reservation. 432 Note that the Admission Priority Policy Element does NOT indicate 433 that this RSVP reservation is to preempt any other RSVP reservation. 434 If a priority session justifies both admission priority and 435 preemption priority, the corresponding RSVP reservation needs to 436 carry both an Admission Priority Policy Element and a Preemption 437 Priority Policy Element. The Admission Priority and Preemption 438 Priority are handled by LPDPs and PEPs as separate mechanisms. They 439 can be used one without the other, or they can be used both in 440 combination. 442 3.1.1. Admission Priority Merging Rules 444 This section discusses alternatives for dealing with RSVP admission 445 priority in case of merging of reservations. As merging is only 446 applicable to multicast, this section also only applies to multicast 447 sessions. 449 The rules for merging Admission Priority Policy Elements are the same 450 as those defined in [RFC3181] for merging Preemption Priority Policy 451 Elements. In particular, the following merging strategies are 452 supported: 454 o Take priority of highest QoS 456 o Take highest priority 458 o Force Error on heterogeneous merge. 460 The only difference with [RFC3181] is that this document does not 461 recommend any merge strategies for Admission Priority while [RFC3181] 462 recommends the first of these merge strategies for Preemption 463 Priority. Note that with the Admission Priority (as is the case with 464 the Preemption Priority), "Take highest priority" translates into 465 "take the highest numerical value". 467 3.2. Application-Level Resource Priority Policy Element 469 The format of the Application-Level Resource Priority policy element 470 is as shown in Figure 2: 472 0 0 0 1 1 2 2 3 473 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 474 +-------------+-------------+-------------+-------------+ 475 | Length | P-Type = APP_RESOURCE_PRI | 476 +-------------+-------------+-------------+-------------+ 477 // ALRP List // 478 +---------------------------+---------------------------+ 480 Figure 2: Application-Level Resource Priority Policy Element 482 where: 484 o Length: 486 * The length of the policy element (including the Length and 487 P-Type) is in number of octets (MUST be a multiple of 4) and 488 indicates the end of the ALRP list. 490 o P-Type: 16 bits 492 * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA 493 Considerations" section) 495 o ALRP List: 497 * List of ALRP where each ALRP is encoded as shown in Figure 3. 499 ALRP: 500 0 0 0 1 1 2 2 3 501 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 502 +---------------------------+-------------+-------------+ 503 | ALRP Namespace | Reserved |ALRP Priority| 504 +---------------------------+---------------------------+ 506 Figure 3: Application-Level Resource Priority 508 where: 510 o ALRP Namespace (Application-Level Resource Priority Namespace): 16 511 bits (unsigned) 513 * Contains a numerical value identifying the namespace of the 514 application-level resource priority. This value is encoded as 515 per the "Resource-Priority Namespaces" IANA registry. (See 516 IANA Considerations section for the request to IANA to extend 517 the registry to include this numerical value). 519 o Reserved: 8 bits 521 * SHALL be set to zero on transmit and SHALL be ignored on 522 reception. 524 o ALRP Priority: (Application-Level Resource Priority Priority): 8 525 bits (unsigned) 527 * Contains the priority value within the namespace of the 528 application-level resource priority. This value is encoded as 529 per the "Resource-Priority Priority-Value" IANA registry. (See 530 IANA Considerations section for the request to IANA to extend 531 the registry to include this numerical value). 533 3.2.1. Application-Level Resource Priority Modifying and Merging Rules 535 When POLICY_DATA objects are protected by integrity, LPDPs should not 536 attempt to modify them. They MUST be forwarded as-is to ensure their 537 security envelope is not invalidated. 539 In case of multicast, when POLICY_DATA objects are not protected by 540 integrity, LPDPs MAY merge incoming Application-Level Resource 541 Priority elements to reduce their size and number. When they do 542 merge those, LPDPs MUST do so according to the following rule: 544 o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 545 all the ALRPs appearing in the ALRP List of an incoming 546 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 547 once. In other words, the outgoing ALRP List is the union of the 548 incoming ALRP Lists that are merged. 550 As merging is only applicable to Multicast, this rule only applies to 551 Multicast sessions. 553 3.3. Default Handling 555 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 556 (PINs) implement a default handling of POLICY_DATA objects ensuring 557 that those objects can traverse PIN nodes in transit from one PEP to 558 another. This applies to the situations where POLICY_DATA objects 559 contain the Admission Priority Policy Element and the ALRP Policy 560 Element specified in this document, so that those can traverse PIN 561 nodes. 563 Section 4.2 of [RFC2750] also defines a similar default behavior for 564 policy-capable nodes that do not recognized a particular Policy 565 Element. This applies to the Admission Priority Policy Element and 566 the ALRP Policy Element specified in this document, so that those can 567 traverse policy-capable nodes that do not support this document. 569 4. Security Considerations 571 The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can 572 be signaled by RSVP through encapsulation in a Policy Data object as 573 defined in [RFC2750]. Therefore, like any other Policy Elements, 574 their integrity can be protected as discussed in section 6 of 575 [RFC2750] by two optional security mechanisms. The first mechanism 576 relies on RSVP Authentication as specified in [RFC2747] and [RFC3097] 577 to provide a chain of trust when all RSVP nodes are policy capable. 578 With this mechanism, the INTEGRITY object is carried inside RSVP 579 messages. The second mechanism relies on the INTEGRITY object within 580 the POLICY_DATA object to guarantee integrity between RSVP Policy 581 Enforcement Points (PEPs) that are not RSVP neighbors. 583 4.1. Use of RSVP Authentication between RSVP nighbors 585 This mechanism can be used can be used between RSVP neighbors that 586 are policy capable. The RSVP neighbors use shared keys to compute 587 the cryptographic signature of the RSVP message. 588 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key 589 provisioning methods as well as their respective applicability. 591 4.2. Use of INTEGRITY object within the POLICY_DATA object 593 The INTEGRITY object within the POLICY_DATA object can be used to 594 guarantee integrity between non-neighboring RSVP PEPs. 596 Details for computation of the content of the INTEGRITY object can be 597 found in Appendix B of [RFC2750]. This states that the Policy 598 Decision Point (PDP), at its discretion, and based on destination 599 PEP/PDP or other criteria, selects an Authentication Key and the hash 600 algorithm to be used. Keys to be used between PDPs can be 601 distributed manually or via standard key management protocol for 602 secure key distribution. 604 Note that where non-RSVP hops may exist in between RSVP hops, as well 605 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 606 between PEPs, it may be difficult for the PDP to determine what is 607 the destination PDP for a POLICY_DATA object contained in some RSVP 608 messages (such as a Path message). This is because in those cases 609 the next PEP is not known at the time of forwarding the message. In 610 this situation, key shared across multiple PDPs may be used. This is 611 conceptually similar to the use of key shared across multiple RSVP 612 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 613 We observe also that this issue may not exist in some deployment 614 scenarios where a single (or low number of) PDP is used to control 615 all the PEPs of a region (such as an administrative domain). In such 616 scenarios, it may be easy for a PDP to determine what is the next hop 617 PDP, even when the next hop PEP is not known, simply by determining 618 what is the next region that will be traversed (say based on the 619 destination address). 621 5. IANA Considerations 623 As specified in [RFC2750], Standard RSVP Policy Elements (P-type 624 values) are to be assigned by IANA as per "IETF Consensus" following 625 the policies outlined in [RFC2434]. 627 IANA needs to allocate two P-Types from the Standard RSVP Policy 628 Element range: 630 o one P-Type to the Admission Priority Policy Element 632 o one P-Type to the Application-Level Resource Priority Policy 633 Element. 635 The present document defines an ALRP Namespace field in section 3.2 636 that contains a numerical value identifying the namespace of the 637 application-level resource priority. The IANA already maintains the 638 Resource-Priority Namespaces registry (under the SIP Parameters) 639 listing all such namespace. However, that registry does not 640 currently allocate a numerical value to each namespace. Hence, this 641 document requests the IANA to extend the Resource-Priority Namespace 642 registry in the following ways: 644 o a new column should be added to the registry 646 o the title of the new column should be "Namespace Numerical Value 647 *" 649 o in the Legend, add a line saying "Namespace Numerical Value = the 650 unique numerical value identifying the namespace" 652 o add a line at the bottom of the registry stating the following "* 653 : [RFCXXX] " where XXX is the RFC number of the present document 655 o allocate an actual numerical value to each namespace in the 656 registry and state that value in the new "Namespace numerical 657 Value *" column. 659 A numerical value should be allocated immediately by IANA to all 660 existing namespace. Then, in the future, IANA should automatically 661 allocate a numerical value to any new namespace added to the 662 registry. 664 The present document defines an ALRP Priority field in section 3.2 665 that contains a numerical value identifying the actual application- 666 level resource priority within the application-level resource 667 priority namespace. The IANA already maintains the Resource-Priority 668 Priority-values registry (under the SIP Parameters) listing all such 669 priorities. However, that registry does not currently allocate a 670 numerical value to each priority-value. Hence, this document 671 requests the IANA to extend the Resource-Priority Priority-Values 672 registry in the following ways: 674 o for each namespace, the registry should be structured with two 675 columns 677 o the title of the first column should read "Priority Values (least 678 to greatest)" 680 o the first column should list all the values currently defined in 681 the registry (e.g. for the drsn namespace: "routine", "priority", 682 "immediate", "flash", "flash-override", "flash-override-override" 683 for the drsn namespace) 685 o the title of the second column should read "Priority Numerical 686 Value *" 688 o At the bottom of the registry, add a "Legend" with a line saying 689 "Priority Numerical Value = the unique numerical value identifying 690 the priority within a namespace" 692 o add a line at the bottom of the registry stating the following "* 693 : [RFCXXX] " where XXX is the RFC number of the present document 695 o allocate an actual numerical value to each and state that value in 696 the new "Priority Numerical Value *" column. 698 A numerical value should be allocated immediately by IANA to all 699 existing priority. Then, in the future, IANA should automatically 700 allocate a numerical value to any new namespace added to the 701 registry. The numerical value must be unique within each namespace. 702 Within each namespace, values should be allocated in decreasing order 703 ending with 0 (so that the greatest priority is always allocated 704 value 0). For example, in the drsn namespace, "routine" would be 705 allocated numerical value 5 and "flash-override-override" would be 706 allocated numerical value 0. 708 6. Acknowledgments 710 We would like to thank An Nguyen for his encouragement to address 711 this topic and ongoing comments. Also, this document borrows heavily 712 from some of the work of S. Herzog on Preemption Priority Policy 713 Element [RFC3181]. Dave Oran and Janet Gunn provided useful input 714 into this document. 716 7. References 718 7.1. Normative References 720 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 721 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 722 Functional Specification", RFC 2205, September 1997. 724 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 725 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 726 October 1998. 728 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 729 Authentication", RFC 2747, January 2000. 731 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 732 RFC 2750, January 2000. 734 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 735 Authentication -- Updated Message Type Value", RFC 3097, 736 April 2001. 738 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 739 RFC 3181, October 2001. 741 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 742 A., Peterson, J., Sparks, R., Handley, M., and E. 743 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 744 June 2002. 746 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 747 Priority for the Session Initiation Protocol (SIP)", 748 RFC 4412, February 2006. 750 7.2. Informative References 752 [I-D.ietf-dime-diameter-qos] 753 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 754 and G. Zorn, "Diameter Quality of Service Application", 755 draft-ietf-dime-diameter-qos-05 (work in progress), 756 February 2008. 758 [I-D.ietf-dime-qos-parameters] 759 Korhonen, J. and H. Tschofenig, "Quality of Service 760 Parameters for Usage with the AAA Framework", 761 draft-ietf-dime-qos-parameters-03 (work in progress), 762 February 2008. 764 [I-D.ietf-nsis-qspec] 765 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 766 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 767 progress), April 2008. 769 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 770 Behringer, M. and F. Faucheur, "Applicability of Keying 771 Methods for RSVP Security", 772 draft-ietf-tsvwg-rsvp-security-groupkeying-00 (work in 773 progress), February 2008. 775 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 776 Requirement Levels", BCP 14, RFC 2119, March 1997. 778 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 779 for Policy-based Admission Control", RFC 2753, 780 January 2000. 782 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 783 Herzog, S., and R. Hess, "Identity Representation for 784 RSVP", RFC 3182, October 2001. 786 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 787 "Integration of Resource Management and Session Initiation 788 Protocol (SIP)", RFC 3312, October 2002. 790 [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for 791 Emergency Telecommunication Service (ETS)", RFC 3689, 792 February 2004. 794 [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 795 for Emergency Telecommunication Service (ETS)", RFC 3690, 796 February 2004. 798 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 799 Constraints Model for Diffserv-aware MPLS Traffic 800 Engineering", RFC 4125, June 2005. 802 [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth 803 Constraints Model for Diffserv-aware MPLS Traffic 804 Engineering & Performance Comparisons", RFC 4126, 805 June 2005. 807 [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints 808 Model for Diffserv-aware MPLS Traffic Engineering", 809 RFC 4127, June 2005. 811 [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency 812 Telecommunications Service (ETS) for Real-Time Services in 813 the Internet Protocol Suite", RFC 4542, May 2006. 815 Appendix A. Examples of Bandwidth Allocation Model for Admission 816 Priority 818 Sections A.1 and A.2 respectively illustrate how the Maximum 819 Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) 820 ([RFC4127]) can be used for support of admission priority. The 821 Maximum Allocation model with Reservation (MAR) ([RFC4126]) could 822 also be used in a similar manner for support of admission priority. 823 Section A.3 illustrates how a simple "Priority Bypass Model" can also 824 be used for support of admission priority. 826 For simplicity, operations with only a single "priority" level 827 (beyond non-priority) are illustrated here; However, the reader will 828 appreciate that operations with multiple priority levels can easily 829 be supported with these models. 831 In all the figures below: 833 x represents a non-priority session 835 o represents a priority session 837 A.1. Admission Priority with Maximum Allocation Model (MAM) 839 This section illustrates operations of admission priority when a 840 Maximum Allocation Model (MAM) is used for bandwidth allocation 841 across non-priority traffic and priority traffic. A property of the 842 Maximum Allocation Model is that priority traffic can not use more 843 than the bandwidth made available to priority traffic (even if the 844 non-priority traffic is not using all of the bandwidth available for 845 it). 847 ----------------------- 848 ^ ^ ^ | | ^ 849 . . . | | . 850 Total . . . | | . Bandwidth 851 (1)(2)(3) | | . Available 852 Engi- . . . | | . for non-priority use 853 neered .or.or. | | . 854 . . . | | . 855 Capacity. . . | | . 856 v . . | | v 857 . . |--------------| --- 858 v . | | ^ 859 . | | . Bandwidth available for 860 v | | v priority use 861 ------------------------- 863 Figure 4: MAM Bandwidth Allocation 865 Figure 4 shows a link within a routed network conforming to this 866 document. On this link are two amounts of bandwidth available to two 867 types of traffic: non-priority and priority. 869 If the non-priority traffic load reaches the maximum bandwidth 870 available for non-priority, no additional non-priority sessions can 871 be accepted even if the bandwidth reserved for priority traffic is 872 not currently fully utilized. 874 With the Maximum Allocation Model, in the case where the priority 875 load reaches the maximum bandwidth reserved for priority calls, no 876 additional priority sessions can be accepted. 878 As illustrated in Figure 4, an operator may map the MAM model onto 879 the Engineered Capacity limits according to different policies. At 880 one extreme, where the proportion of priority traffic is reliably 881 known to be fairly small at all times and where there may be some 882 safety margin factored in the engineered capacity limits, the 883 operator may decide to configure the bandwidth available for non- 884 priority use to the full engineered capacity limits; effectively 885 allowing the priority traffic to ride within the safety margin of 886 this engineered capacity. This policy can be seen as an economically 887 attractive approach as all of the engineered capacity is made 888 available to non-priority calls. This policy is illustrated as (1) 889 in Figure 4. As an example, if the engineered capacity limit on a 890 given link is X, the operator may configure the bandwidth available 891 to non-priority traffic to X, and the bandwidth available to priority 892 traffic to 5% of X. At the other extreme, where the proportion of 893 priority traffic may be significant at times and the engineered 894 capacity limits are very tight, the operator may decide to configure 895 the bandwidth available to non-priority traffic and the bandwidth 896 available to priority traffic such that their sum is equal to the 897 engineered capacity limits. This guarantees that the total load 898 across non-priority and priority traffic is always below the 899 engineered capacity and, in turn, guarantees there will never be any 900 QoS degradation. However, this policy is less attractive 901 economically as it prevents non-priority calls from using the full 902 engineered capacity, even when there is no or little priority load, 903 which is the majority of time. This policy is illustrated as (3) in 904 Figure 4. As an example, if the engineered capacity limit on a given 905 link is X, the operator may configure the bandwidth available to non- 906 priority traffic to 95% of X, and the bandwidth available to priority 907 traffic to 5% of X. Of course, an operator may also strike a balance 908 anywhere in between these two approaches. This policy is illustrated 909 as (2) in Figure 4. 911 Figure 5 shows some of the non-priority capacity of this link being 912 used. 914 ----------------------- 915 ^ ^ ^ | | ^ 916 . . . | | . 917 Total . . . | | . Bandwidth 918 . . . | | . Available 919 Engi- . . . | | . for non-priority use 920 neered .or.or. |xxxxxxxxxxxxxx| . 921 . . . |xxxxxxxxxxxxxx| . 922 Capacity. . . |xxxxxxxxxxxxxx| . 923 v . . |xxxxxxxxxxxxxx| v 924 . . |--------------| --- 925 v . | | ^ 926 . | | . Bandwidth available for 927 v | | v priority use 928 ------------------------- 930 Figure 5: Partial load of non-priority calls 932 Figure 6 shows the same amount of non-priority load being used at 933 this link, and a small amount of priority bandwidth being used. 935 ----------------------- 936 ^ ^ ^ | | ^ 937 . . . | | . 938 Total . . . | | . Bandwidth 939 . . . | | . Available 940 Engi- . . . | | . for non-priority use 941 neered .or.or. |xxxxxxxxxxxxxx| . 942 . . . |xxxxxxxxxxxxxx| . 943 Capacity. . . |xxxxxxxxxxxxxx| . 944 v . . |xxxxxxxxxxxxxx| v 945 . . |--------------| --- 946 v . | | ^ 947 . | | . Bandwidth available for 948 v |oooooooooooooo| v priority use 949 ------------------------- 951 Figure 6: Partial load of non-priority calls & partial load of 952 priority calls Calls 954 Figure 7 shows the case where non-priority load equates or exceeds 955 the maximum bandwidth available to non-priority traffic. Note that 956 additional non-priority sessions would be rejected even if the 957 bandwidth reserved for priority sessions is not fully utilized. 959 ----------------------- 960 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 961 . . . |xxxxxxxxxxxxxx| . 962 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 963 . . . |xxxxxxxxxxxxxx| . Available 964 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 965 neered .or.or. |xxxxxxxxxxxxxx| . 966 . . . |xxxxxxxxxxxxxx| . 967 Capacity. . . |xxxxxxxxxxxxxx| . 968 v . . |xxxxxxxxxxxxxx| v 969 . . |--------------| --- 970 v . | | ^ 971 . | | . Bandwidth available for 972 v |oooooooooooooo| v priority use 973 ------------------------- 975 Figure 7: Full non-priority load & partial load of priority calls 977 Figure 8 shows the case where the priority traffic equates or exceeds 978 the bandwidth reserved for such priority traffic. 980 In that case additional priority sessions could not be accepted. 981 Note that this does not mean that such calls are dropped altogether: 982 they may be handled by mechanisms, which are beyond the scope of this 983 particular document (such as establishment through preemption of 984 existing non-priority sessions, or such as queuing of new priority 985 session requests until capacity becomes available again for priority 986 traffic). 988 ----------------------- 989 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 990 . . . |xxxxxxxxxxxxxx| . 991 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 992 . . . |xxxxxxxxxxxxxx| . Available 993 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 994 neered .or.or. |xxxxxxxxxxxxxx| . 995 . . . |xxxxxxxxxxxxxx| . 996 Capacity. . . | | . 997 v . . | | v 998 . . |--------------| --- 999 v . |oooooooooooooo| ^ 1000 . |oooooooooooooo| . Bandwidth available for 1001 v |oooooooooooooo| v priority use 1002 ------------------------- 1004 Figure 8: Partial non-priority load & Full priority load 1006 A.2. Admission Priority with Russian Dolls Model (RDM) 1008 This section illustrates operations of admission priority when a 1009 Russian Dolls Model (RDM) is used for bandwidth allocation across 1010 non-priority traffic and priority traffic. A property of the Russian 1011 Dolls Model is that priority traffic can use the bandwidth which is 1012 not currently used by non-priority traffic. 1014 As with the MAM model, an operator may map the RDM model onto the 1015 Engineered Capacity limits according to different policies. The 1016 operator may decide to configure the bandwidth available for non- 1017 priority use to the full engineered capacity limits; As an example, 1018 if the engineered capacity limit on a given link is X, the operator 1019 may configure the bandwidth available to non-priority traffic to X, 1020 and the bandwidth available to non-priority and priority traffic to 1021 105% of X. 1023 Alternatively, the operator may decide to configure the bandwidth 1024 available to non-priority and priority traffic to the engineered 1025 capacity limits; As an example, if the engineered capacity limit on a 1026 given link is X, the operator may configure the bandwidth available 1027 to non-priority traffic to 95% of X, and the bandwidth available to 1028 non-priority and priority traffic to X. 1030 Finally, the operator may decide to strike a balance in between. The 1031 considerations presented for these policies in the previous section 1032 in the MAM context are equally applicable to RDM. 1034 Figure 9 shows the case where only some of the bandwidth available to 1035 non-priority traffic is being used and a small amount of priority 1036 traffic is in place. In that situation both new non-priority 1037 sessions and new priority sessions would be accepted. 1039 -------------------------------------- 1040 |xxxxxxxxxxxxxx| . ^ 1041 |xxxxxxxxxxxxxx| . Bandwidth . 1042 |xxxxxxxxxxxxxx| . Available for . 1043 |xxxxxxxxxxxxxx| . non-priority . 1044 |xxxxxxxxxxxxxx| . use . 1045 |xxxxxxxxxxxxxx| . . Bandwidth 1046 | | . . available for 1047 | | v . non-priority 1048 |--------------| --- . and priority 1049 | | . use 1050 | | . 1051 |oooooooooooooo| v 1052 --------------------------------------- 1054 Figure 9: Partial non-priority load & Partial Aggregate load 1056 Figure 10 shows the case where all of the bandwidth available to non- 1057 priority traffic is being used and a small amount of priority traffic 1058 is in place. In that situation new priority sessions would be 1059 accepted but new non-priority sessions would be rejected. 1061 -------------------------------------- 1062 |xxxxxxxxxxxxxx| . ^ 1063 |xxxxxxxxxxxxxx| . Bandwidth . 1064 |xxxxxxxxxxxxxx| . Available for . 1065 |xxxxxxxxxxxxxx| . non-priority . 1066 |xxxxxxxxxxxxxx| . use . 1067 |xxxxxxxxxxxxxx| . . Bandwidth 1068 |xxxxxxxxxxxxxx| . . available for 1069 |xxxxxxxxxxxxxx| v . non-priority 1070 |--------------| --- . and priority 1071 | | . use 1072 | | . 1073 |oooooooooooooo| v 1074 --------------------------------------- 1076 Figure 10: Full non-priority load & Partial Aggregate load 1078 Figure 11 shows the case where only some of the bandwidth available 1079 to non-priority traffic is being used and a heavy load of priority 1080 traffic is in place. In that situation both new non-priority 1081 sessions and new priority sessions would be accepted. Note that, as 1082 illustrated in Figure 10, priority calls use some of the bandwidth 1083 currently not used by non-priority traffic. 1085 -------------------------------------- 1086 |xxxxxxxxxxxxxx| . ^ 1087 |xxxxxxxxxxxxxx| . Bandwidth . 1088 |xxxxxxxxxxxxxx| . Available for . 1089 |xxxxxxxxxxxxxx| . non-priority . 1090 |xxxxxxxxxxxxxx| . use . 1091 | | . . Bandwidth 1092 | | . . available for 1093 |oooooooooooooo| v . non-priority 1094 |--------------| --- . and priority 1095 |oooooooooooooo| . use 1096 |oooooooooooooo| . 1097 |oooooooooooooo| v 1098 --------------------------------------- 1100 Figure 11: Partial non-priority load & Heavy Aggregate load 1102 Figure 12 shows the case where all of the bandwidth available to non- 1103 priority traffic is being used and all of the remaining available 1104 bandwidth is used by priority traffic. In that situation new non- 1105 priority sessions would be rejected. In that situation new priority 1106 sessions could not be accepted right away. Those priority sessions 1107 may be handled by mechanisms, which are beyond the scope of this 1108 particular document (such as established through preemption of 1109 existing non-priority sessions, or such as queuing of new priority 1110 session requests until capacity becomes available again for priority 1111 traffic). 1113 -------------------------------------- 1114 |xxxxxxxxxxxxxx| . ^ 1115 |xxxxxxxxxxxxxx| . Bandwidth . 1116 |xxxxxxxxxxxxxx| . Available for . 1117 |xxxxxxxxxxxxxx| . non-priority . 1118 |xxxxxxxxxxxxxx| . use . 1119 |xxxxxxxxxxxxxx| . . Bandwidth 1120 |xxxxxxxxxxxxxx| . . available for 1121 |xxxxxxxxxxxxxx| v . non-priority 1122 |--------------| --- . and priority 1123 |oooooooooooooo| . use 1124 |oooooooooooooo| . 1125 |oooooooooooooo| v 1126 --------------------------------------- 1128 Figure 12: Full non-priority load & Full Aggregate load 1130 A.3. Admission Priority with Priority Bypass Model (PrBM) 1132 This section illustrates operations of admission priority when a 1133 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1134 across non-priority traffic and priority traffic. With the Priority 1135 Bypass Model, non-priority traffic is subject to resource based 1136 admission control while priority traffic simply bypasses the resource 1137 based admission control. In other words: 1139 o when a non-priority call arrives, this call is subject to 1140 bandwidth admission control and is accepted if the current total 1141 load (aggregate over non-priority and priority traffic) is below 1142 the engineered/allocated bandwidth. 1144 o when a priority call arrives, this call is admitted regardless of 1145 the current load. 1147 A property of this model is that a priority call is never rejected. 1149 The rationale for this simple scheme is that, in practice in some 1150 networks: 1152 o the volume of priority calls is very low for the vast majority of 1153 time, so it may not be economical to completely set aside 1154 bandwidth for priority calls and preclude the utilization of this 1155 bandwidth by normal calls in normal situations 1157 o even in emergency periods where priority calls are more heavily 1158 used, those always still represent a fairly small proportion of 1159 the overall load which can be absorbed within the safety margin of 1160 the engineered capacity limits. Thus, even if they are admitted 1161 beyond the engineered bandwidth threshold, they are unlikely to 1162 result in noticeable QoS degradation. 1164 As with the MAM and RDM model, an operator may map the Priority 1165 Bypass model onto the Engineered Capacity limits according to 1166 different policies. The operator may decide to configure the 1167 bandwidth limit for admission of non-priority traffic to the full 1168 engineered capacity limits; As an example, if the engineered capacity 1169 limit on a given link is X, the operator may configure the bandwidth 1170 limit for non-priority traffic to X. Alternatively, the operator may 1171 decide to configure the bandwidth limit for non-priority traffic to 1172 below the engineered capacity limits (so that the sum of the non- 1173 priority and priority traffic stays below the engineered capacity); 1174 As an example, if the engineered capacity limit on a given link is X, 1175 the operator may configure the bandwidth limit for non-priority 1176 traffic to 95% of X. Finally, the operator may decide to strike a 1177 balance in between. The considerations presented for these policies 1178 in the previous sections in the MAM and RDM contexts are equally 1179 applicable to the Priority Bypass Model. 1181 Figure 13 illustrates the bandwidth allocation with the Priority 1182 Bypass Model. 1184 ----------------------- 1185 ^ ^ | | ^ 1186 . . | | . 1187 Total . . | | . Bandwidth Limit 1188 (1) (2) | | . (on non-priority + priority) 1189 Engi- . . | | . for admission 1190 neered . or . | | . of non-priority traffic 1191 . . | | . 1192 Capacity. . | | . 1193 v . | | v 1194 . |--------------| --- 1195 . | | 1196 v | | 1197 | | 1199 Figure 13: Priority Bypass Model Bandwidth Allocation 1201 Figure 14 shows some of the non-priority capacity of this link being 1202 used. In this situation, both new non-priority and new priority 1203 calls would be accepted. 1205 ----------------------- 1206 ^ ^ |xxxxxxxxxxxxxx| ^ 1207 . . |xxxxxxxxxxxxxx| . 1208 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1209 (1) (2) |xxxxxxxxxxxxxx| . (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 14: Partial load of non-priority calls 1222 Figure 15 shows the same amount of non-priority load being used at 1223 this link, and a small amount of priority bandwidth being used. In 1224 this situation, both new non-priority and new priority calls would be 1225 accepted. 1227 ----------------------- 1228 ^ ^ |xxxxxxxxxxxxxx| ^ 1229 . . |xxxxxxxxxxxxxx| . 1230 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1231 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1232 Engi- . . |oooooooooooooo| . for admission 1233 neered . or . | | . of non-priority traffic 1234 . . | | . 1235 Capacity. . | | . 1236 v . | | v 1237 . |--------------| --- 1238 . | | 1239 v | | 1240 | | 1242 Figure 15: Partial load of non-priority calls & partial load of 1243 priority calls 1245 Figure 16 shows the case where aggregate non-priority and priority 1246 load exceeds the bandwidth limit for admission of non-priority 1247 traffic. In this situation, any new non-priority call is rejected 1248 while any new priority call is admitted. 1250 ----------------------- 1251 ^ ^ |xxxxxxxxxxxxxx| ^ 1252 . . |xxxxxxxxxxxxxx| . 1253 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1254 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1255 Engi- . . |oooooooooooooo| . for admission 1256 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1257 . . |xxoxxxxxxoxxxx| . 1258 Capacity. . |oxxxooooxxxxoo| . 1259 v . |xxoxxxooxxxxxx| v 1260 . |--------------| --- 1261 . |oooooooooooooo| 1262 v | | 1263 | | 1265 Figure 16: Full non-priority load 1267 Appendix B. Example Usages of RSVP Extensions 1269 This section provides examples of how RSVP extensions defined in this 1270 document can be used (in conjunctions with other RSVP functionality 1271 and SIP functionality) to enforce different hypothetical policies for 1272 handling Emergency sessions in a given administrative domain. This 1273 Appendix does not provide additional specification. It is only 1274 included in this document for illustration purposes. 1276 We assume an environment where SIP is used for session control and 1277 RSVP is used for resource reservation. 1279 In a mild abuse of language, we refer here to "Call Queueing" as the 1280 set of "session" layer capabilities that may be implemented by SIP 1281 user agents to influence their treatment of SIP requests. This may 1282 include the ability to "queue" call requests when those can not be 1283 immediately honored (in some cases with the notion of "bumping", or 1284 "displacement", of less important call request from that queue). It 1285 may include additional mechanisms such as exemption from certain 1286 network management controls, and alternate routing. 1288 We only mention below the RSVP policy elements that are to be 1289 enforced by PEPs. It is assumed that these policy elements are set 1290 at administrative domain boundaries by PDPs. The Admission Priority 1291 and Preemption Priority RSVP policy elements are set by PDPs as a 1292 result of processing the Application Level Resource Priority Policy 1293 Element (which is carried in RSVP messages). 1295 If one wants to implement an emergency service purely based on Call 1296 Queueing, one can achieve this by signaling emergency calls: 1298 o using "Resource-Priority" Header in SIP 1300 o not using Admission-Priority Policy Element in RSVP 1302 o not using Preemption Policy Element in RSVP 1304 If one wants to implement an emergency service based on Call Queueing 1305 and on "prioritized access to network layer resources", one can 1306 achieve this by signaling emergency calls: 1308 o using "Resource-Priority" Header in SIP 1310 o using Admission-Priority Policy Element in RSVP 1312 o not using Preemption Policy Element in RSVP 1314 Emergency calls will not result in preemption of any session. 1315 Different bandwidth allocation models can be used to offer different 1316 "prioritized access to network resources". Just as examples, this 1317 includes strict setting aside of capacity for emergency sessions as 1318 well as simple bypass of admission limits for emergency sessions. 1320 If one wants to implement an emergency service based on Call 1321 Queueing, on "prioritized access to network layer resources", and 1322 ensures that (say) "Emergency-1" sessions can preempt "Emergency-2" 1323 sessions, but non-emergency sessions are not affected by preemption, 1324 one can do that by signaling emergency calls: 1326 o using "Resource-Priority" Header in SIP 1328 o using Admission-Priority Policy Element in RSVP 1330 o using Preemption Policy Element in RSVP with: 1332 * setup (Emergency-1) > defending (Emergency-2) 1334 * setup (Emergency-2) <= defending (Emergency-1) 1336 * setup (Emergency-1) <= defending (Non-Emergency) 1338 * setup (Emergency-2) <= defending (Non-Emergency) 1340 If one wants to implement an emergency service based on Call 1341 Queueing, on "prioritized access to network layer resources", and 1342 ensure that "emergency" sessions can preempt regular sessions, one 1343 could do that by signaling emergency calls: 1345 o using "Resource-Priority" Header in SIP 1347 o using Admission-Priority Policy Element in RSVP 1349 o using Preemption Policy Element in RSVP with: 1351 * setup (Emergency) > defending (Non-Emergency) 1353 * setup (Non-Emergency) <= defending (Emergency) 1355 If one wants to implement an emergency service based on Call 1356 Queueing, on "prioritized access to network layer resources", and 1357 ensure that "emergency" sessions can partially preempt regular 1358 sessions (ie reduce their reservation size), one could do that by 1359 signaling emergency calls: 1361 o using "Resource-Priority" Header in SIP 1363 o using Admission-Priority Policy Element in RSVP 1365 o using Preemption in Policy Element RSVP with: 1367 * setup (Emergency) > defending (Non-Emergency) 1369 * setup (Non-Emergency) <= defending (Emergency) 1371 o activate RFC4495 RSVP Bandwidth Reduction mechanisms 1373 Authors' Addresses 1375 Francois Le Faucheur 1376 Cisco Systems 1377 Greenside, 400 Avenue de Roumanille 1378 Sophia Antipolis 06410 1379 France 1381 Phone: +33 4 97 23 26 19 1382 Email: flefauch@cisco.com 1383 James Polk 1384 Cisco Systems 1385 2200 East President George Bush Highway 1386 Richardson, TX 75082-3550 1387 United States 1389 Phone: +1 972 813 5208 1390 Email: jmpolk@cisco.com 1392 Ken Carlberg 1393 G11 1394 123a Versailles Circle 1395 Towson, MD 21204 1396 United States 1398 Email: carlberg@g11.org.uk 1400 Full Copyright Statement 1402 Copyright (C) The IETF Trust (2008). 1404 This document is subject to the rights, licenses and restrictions 1405 contained in BCP 78, and except as set forth therein, the authors 1406 retain all their rights. 1408 This document and the information contained herein are provided on an 1409 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1410 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1411 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1412 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1413 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1414 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1416 Intellectual Property 1418 The IETF takes no position regarding the validity or scope of any 1419 Intellectual Property Rights or other rights that might be claimed to 1420 pertain to the implementation or use of the technology described in 1421 this document or the extent to which any license under such rights 1422 might or might not be available; nor does it represent that it has 1423 made any independent effort to identify any such rights. Information 1424 on the procedures with respect to rights in RFC documents can be 1425 found in BCP 78 and BCP 79. 1427 Copies of IPR disclosures made to the IETF Secretariat and any 1428 assurances of licenses to be made available, or the result of an 1429 attempt made to obtain a general license or permission for the use of 1430 such proprietary rights by implementers or users of this 1431 specification can be obtained from the IETF on-line IPR repository at 1432 http://www.ietf.org/ipr. 1434 The IETF invites any interested party to bring to its attention any 1435 copyrights, patents or patent applications, or other proprietary 1436 rights that may cover technology that may be required to implement 1437 this standard. Please address the information to the IETF at 1438 ietf-ipr@ietf.org.