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