idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-04.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1331. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1315. 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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 1 character in excess of 72. 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 (November 19, 2007) is 6002 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXX' is mentioned on line 644, but not defined ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) == Outdated reference: A later version (-01) exists of draft-behringer-tsvwg-rsvp-security-groupkeying-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RSVP Extensions for Emergency Services November 2007 3 TSVWG Francois Le Faucheur 4 Internet-Draft James Polk 5 Intended Status: Standards Track Cisco Systems, Inc. 7 Ken Carlberg 8 G11 9 draft-ietf-tsvwg-emergency-rsvp-04.txt 10 Expires: May 2008 November 19, 2007 12 Resource ReSerVation Protovol (RSVP) Extensions for Emergency 13 Services 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 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 be 43 facilitated through a network layer admission control solution, which 44 supports prioritized access to resources (e.g., bandwidth). These 45 resources may be explicitly set aside for emergency services, or they 46 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 that 50 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 Copyright Notice 55 Copyright (C) The IETF Trust (2007). 57 Specification of Requirements 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119. 63 Table of Contents 65 1. Introduction...................................................3 66 1.1. Related Technical Documents.................................3 67 1.2. Terminology.................................................4 68 2. Overview of RSVP extensions and Operations.....................5 69 2.1. Operations of Admission Priority..........................7 70 3. New Policy Elements............................................7 71 3.1. Admission Priority Policy Element.........................8 72 3.1.1. Admission Priority Merging Rules 9 73 3.2. Application-Level Resource Priority Policy Element.......10 74 3.2.1. Application-Level Resource Priority Modifying and 75 Merging Rules 11 76 3.3. Default Handling.........................................11 77 4. Security Considerations.......................................12 78 4.1. Use of RSVP Authentication between RSVP nighbors.........12 79 4.2. Use of INTEGRITY object within the POLICY_DATA object....12 80 5. IANA Considerations...........................................13 81 6. Acknowledgments...............................................15 82 7. Normative References..........................................15 83 8. Informative References........................................15 84 Appendix A: Examples of Bandwidth Allocation Model for Admission 85 Priority.........................................................17 86 A.1 Admission Priority with Maximum Allocation Model (MAM)......17 87 A.2 Admission Priority with Russian Dolls Model (RDM)...........21 88 A.3 Admission Priority with Priority Bypass Model (PrBM)........23 89 Appendix B: Example Usages of RSVP Extensions....................26 90 Authors' Address.................................................28 92 1. Introduction 94 [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency 95 Telecommunications Service (ETS), which is an umbrella term 96 identifying those networks and specific services used to support 97 emergency communications. An underlying goal of these documents is to 98 present requirements that elevate the probability of session 99 establishment from an authorized user in times of network congestion 100 (presumably because of a crisis condition). In some extreme cases, 101 the requirement for this probability may reach 100%, but that is a 102 topic subject to policy and most likely local regulation (the latter 103 being outside the scope of this document). 105 Solutions to meet this requirement for elevated session establishment 106 probability may involve session layer capabilities prioritizing 107 access to resources controlled by the session control function. As an 108 example, entities involved in session control (such as SIP user 109 agents, when the Session Initiation Protocol, SIP [SIP], is the 110 session control protocol in use) can influence their treatment of 111 session establishment requests (such as SIP requests). This may 112 include the ability to "queue" call requests when those can not be 113 immediately honored (in some cases with the notion of "bumping", or 114 "displacement", of less important call request from that queue). It 115 may include additional mechanisms such as exemption from certain 116 network management controls, and alternate routing. 118 Solutions to meet the requirement for elevated session establishment 119 probability may also take advantage of network layer admission 120 control mechanisms supporting admission priority. Networks usually 121 have engineered capacity limits that characterize the maximum load 122 that can be handled (say, on any given link) for a class of traffic 123 while satisfying the quality of service requirements of that traffic 124 class. Admission priority may involve setting aside some network 125 resources (e.g. bandwidth) out of the engineered capacity limits for 126 the emergency services only. Or alternatively, it may involve 127 allowing the emergency related sessions to seize additional resources 128 beyond the engineered capacity limits applied to normal calls. 130 Note: Below, this document references several examples of IP 131 telephony and its use of "calls", which is one form of the term 132 "sessions" (Video over IP and Instant Messaging being other examples 133 that rely on session establishment). For the sake of simplicity, we 134 shall use the widely known term "call" for the remainder of this 135 document. 137 1.1. Related Technical Documents 139 [EMERG-IMP] is patterned after [ITU.I.225] and describes an example 140 of one type of prioritized network layer admission control procedure 141 that may be used for emergency services operating over an IP network 142 infrastructure. It discusses initial call set up, as well as 143 operations after call establishment through maintenance of a 144 continuing call model of the status of all calls. [EMERG-IMP] also 145 describes how these network layer admission control procedures can be 146 realized using the Resource reSerVation Protocol [RSVP] along with 147 its associated protocol suite and extensions, including those for 148 policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user 149 authentication and authorization ([RSVP-ID]) and for integrity and 150 authentication of RSVP messages ([RSVP-CRYPTO-1], [RSVP-CRYPTO-2]). 152 Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption 153 Priority Policy Element specified in [RSVP-PREEMP] can be used to 154 enforce the call preemption that may be needed by some emergency 155 services. 157 In contrast to [EMERG-IMP], this document specifies new RSVP 158 extensions to increase the probability of call completion without 159 preemption. Engineered capacity techniques in the form of bandwidth 160 allocation models are used to satisfy the "admission priority" 161 required by an RSVP capable ETS network. In particular this document 162 specifies two new RSVP Policy Elements allowing the admission 163 priority to be conveyed inside RSVP signaling messages so that RSVP 164 nodes can enforce selective bandwidth admission control decision 165 based on the call admission priority. Appendix A of this document 166 also provides three examples of a bandwidth allocation model, which 167 can be used by RSVP-routers to enforce such admission priority on 168 every link. 170 1.2. Terminology 172 This document assumes the terminology defined in [FW-POLICY]. For 173 convenience, the definition of a few key terms is repeated here: 175 - Policy Decision Point (PDP): The point where policy decisions are 176 made. 178 - Local Policy Decision Point (LPDP): PDP local to the network 179 element 181 - Policy Enforcement Point (PEP): The point where the policy 182 decisions are actually enforced. 184 - Policy Ignorant Node (PIN): A network element that does not 185 explicitly support policy control using the mechanisms defined in 186 [FW-POLICY]. 188 2. Overview of RSVP extensions and Operations 190 Let us consider the case where a call requiring ETS type service is 191 to be established, and more specifically that the preference to be 192 granted to this call is in terms of network layer "admission 193 priority" (as opposed to preference granted through preemption of 194 existing calls). By "admission priority" we mean allowing that 195 priority call to seize network layer resources from the engineered 196 capacity that have been set-aside and not made available to normal 197 calls, or alternatively by allowing that call to seize additional 198 resources beyond the engineered capacity limits applied to normal 199 calls. 201 As described in [EMERG-IMP], the session establishment can be 202 conditioned to resource-based and policy-based network layer 203 admission control achieved via RSVP signaling. In the case where the 204 session control protocol is SIP, the use of RSVP-based admission 205 control by SIP is specified in [SIP-RESOURCE]. 207 Devices involved in the session establishment are expected to be 208 aware of the application-level priority requirements of emergency 209 calls. Again considering the case where the session control protocol 210 is SIP, the SIP user agents can be made aware of the resource 211 priority requirements in the case of an emergency call using the 212 Resource-Priority Header mechanism specified in [SIP-PRIORITY]. The 213 end-devices involved in the upper-layer session establishment simply 214 need to copy the application-level resource priority requirements 215 (e.g. as communicated in SIP Resource-Priority Header) inside the new 216 RSVP Application-Level Resource-Priority Policy Element defined in 217 this document. 219 Conveying the application-level resource priority requirements inside 220 the RSVP message allows this application level requirement to be 221 mapped/remapped into a different RSVP "admission priority" at every 222 administrative domain boundary based on the policy applicable in that 223 domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs 224 at the periphery of the policy domain (e.g., in border routers), PDPs 225 would interpret the RSVP Application-Level Resource-Priority Policy 226 Element and map the requirement of the emergency session into an RSVP 227 "admission priority" level. Then, PDPs would convey this information 228 inside the new Admission Priority Policy Element defined in this 229 document. This way, the RSVP admission priority can be communicated 230 to downstream PEPs (ie RSVP Routers) of the same policy domain, which 231 have LPDPs but no controlling PDP. In turn, this means the necessary 232 RSVP Admission priority can be enforced at every RSVP hop, including 233 all the (many) hops which do not have any understanding of 234 Application-Level Resource-Priority semantics. 236 As an example of operation across multiple administrative domains, a 237 first domain might decide to provide network layer admission priority 238 to calls of a given Application Level Resource Priority and map it 239 into a high RSVP admission control priority inside the Admission 240 Priority Policy Element; while a second domain may decide to not 241 provide admission priority to calls of this same Application Level 242 Resource Priority and hence map it into a low RSVP admission control 243 priority. 245 As another example of operation across multiple administrative 246 domains, we can consider the case where the resource priority header 247 enumerates several namespaces, as explicitly allowed by [SIP- 248 PRIORITY], for support of scenarios where calls traverse multiple 249 administrative domains using different namespace. In that case, the 250 relevant namespace can be used at each domain boundary to map into an 251 RSVP Admission priority for that domain. It is not expected that the 252 RSVP Application-Level Resource-Priority Header Policy Element would 253 be taken into account at RSVP-hops within a given administrative 254 domain. It is expected to be used at administrative domain boundaries 255 only in order to set/reset the RSVP Admission Priority Policy Element. 257 The existence of pre-established inter-domain policy agreements or 258 Service Level Agreements may avoid the need to take real-time action 259 at administrative domain boundaries for mapping/remapping of 260 admission priorities. 262 Mapping/remapping by PDPs may also be applied to boundaries between 263 various signaling protocols, such as those advanced by the NSIS 264 working group. 266 As can be observed, the framework described above for 267 mapping/remapping application level resource priority requirements 268 into an RSVP admission priority can also be used together with [RSVP- 269 PREEMP] for mapping/remapping application level resource priority 270 requirements into an RSVP preemption priority (when preemption is 271 indeed needed). In that case, when processing the RSVP Application- 272 Level Resource-Priority Policy Element, the PDPs at boundaries 273 between administrative domains (or between various QoS signaling 274 protocols) can map it into an RSVP "preemption priority" information. 275 This Preemption priority information comprises a setup preemption 276 level and a defending preemption priority level. This preemption 277 priority information can then be encoded inside the Preemption 278 Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into 279 account at every RSVP-enabled network hop as discussed [EMERG-IMP]. 280 Appendix B provides examples of various hypothetical policies for 281 emergency call handling, some of them involving admission priority, 282 some of them involving both admission priority and preemption 283 priority. Appendix B also identifies how the Application-Level 284 Resource Priority need to be mapped into RSVP policy elements by the 285 PDPs to realize these policies. 287 2.1. Operations of Admission Priority 289 The RSVP Admission Priority policy element defined in this document 290 allows admission bandwidth to be allocated preferentially to an 291 authorized priority service. Multiple models of bandwidth allocation 292 MAY be used to that end. 294 A number of bandwidth allocation models have been defined in the IETF 295 for allocation of bandwidth across different classes of traffic 296 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 297 Those include the Maximum Allocation Model (MAM) defined in [DSTE- 298 MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These 299 same models MAY however be applied for allocation of bandwidth across 300 different levels of admission priority as defined in this document. 301 Appendix A provides an illustration of how these bandwidth allocation 302 models can be applied for such purposes and introduces an additional 303 bandwidth allocation model that we term the Priority Bypass Model 304 (PrBM). It is important to note that the models described and 305 illustrated in Appendix A are only informative and do not represent a 306 recommended course of action. 308 We can see in these examples, that the RSVP Admission Priority may 309 effectively influence the fundamental admission control decision of 310 RSVP (for example by determining which bandwidth pool is to be used 311 by RSVP for performing its fundamental bandwidth allocation). In that 312 sense, we observe that the policy control and admission control are 313 not separate logics but instead somewhat blended. 315 3. New Policy Elements 317 The Framework document for policy-based admission control [FW-POLICY] 318 describes the various components that participate in policy decision 319 making (i.e., PDP, PEP and LPDP). 321 As described in section 2 of the present document, the Application- 322 Level Resource Priority Policy Element and the Admission Priority 323 Policy Element serve different roles in this framework: 325 - the Application-Level Resource Priority Policy Element conveys 326 application level information and is processed by PDPs 328 - the emphasis of Admission Priority Policy Element is to be 329 simple, stateless, and light-weight such that it can be 330 processed internally within a node's LPDP. It can then be 331 enforced internally within a node's PEP. It is set by PDPs 332 based on processing of the Application-Level Resource Priority 333 Policy Element. 335 [RSVP-POLICY] defines extensions for supporting generic policy based 336 admission control in RSVP. These extensions include the standard 337 format of POLICY_DATA objects and a description of RSVP handling of 338 policy events. 340 The POLICY_DATA object contains one or more of Policy Elements, each 341 representing a different (and perhaps orthogonal) policy. As an 342 example, [RSVP-PREEMP] specifies the Preemption Priority Policy 343 Element. 345 This document defines two new Policy Elements called: 346 - the Admission Priority Policy Element 347 - the Application-Level Resource Priority Policy Element 349 3.1. Admission Priority Policy Element 351 The format of the Admission Priority policy element is as follows: 353 0 0 0 1 1 2 2 3 354 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 355 +-------------+-------------+-------------+-------------+ 356 | Length | P-Type = ADMISSION_PRI | 357 +-------------+-------------+-------------+-------------+ 358 | Flags | M. Strategy | Error Code | Reserved | 359 +-------------+-------------+-------------+-------------+ 360 | Reserved |Adm. Priority| 361 +---------------------------+---------------------------+ 363 Length: 16 bits 364 Always 12. The overall length of the policy element, in bytes. 366 P-Type: 16 bits 367 ADMISSION_PRI = To be allocated by IANA 368 (see "IANA Considerations" section) 370 Flags: Reserved (MUST be set to zero on transmit and ignored on 371 receive) 373 Merge Strategy: 8 bits (only applicable to multicast flows) 374 1 Take priority of highest QoS 375 2 Take highest priority 376 3 Force Error on heterogeneous merge 377 (See section 3.1.1) 379 Error code: 8 bits (only applicable to multicast flows) 380 0 NO_ERROR Value used for regular ADMISSION_PRI elements 381 2 HETEROGENEOUS This element encountered heterogeneous merge 383 Reserved: 8 bits 384 Always 0. 386 Reserved: 24 bits 387 Always 0. 389 Adm. Priority (Admission Priority): 8 bits (unsigned) 390 The admission control priority of the flow, in terms of access 391 to network bandwidth in order to provide higher probability of 392 call completion to selected flows. Higher values represent 393 higher Priority. 395 Bandwidth allocation models such as those described in Appendix 396 A are to be used by the RSVP router to achieve such increased 397 probability of call completion. The admission priority value 398 effectively indicates which bandwidth constraint(s) of the 399 bandwidth constraint model in use is(are) applicable to 400 admission of this RSVP reservation. 402 Note that the Admission Priority Policy Element does NOT indicate 403 that this RSVP reservation is to preempt any other RSVP reservation. 404 If a priority session justifies both admission priority and 405 preemption priority, the corresponding RSVP reservation needs to 406 carry both an Admission Priority Policy Element and a Preemption 407 Priority Policy Element. The Admission Priority and Preemption 408 Priority are handled by LPDPs and PEPs as separate mechanisms. They 409 can be used one without the other, or they can be used both in 410 combination. 412 3.1.1. 413 Admission Priority Merging Rules 415 This section discusses alternatives for dealing with RSVP admission 416 priority in case of merging of reservations. As merging is only 417 applicable to multicast, this section also only applies to multicast 418 sessions. 420 The rules for merging Admission Priority Policy Elements are the same 421 as those defined in [RSVP-PREEMP] for merging Preemption Priority 422 Policy Elements. In particular, the following merging strategies are 423 supported: 424 - Take priority of highest QoS 425 - Take highest priority 426 - Force Error on heterogeneous merge. 428 The only difference with [RSVP-PREEMP] is that this document does not 429 recommend any merge strategies for Admission Priority while [RSVP- 430 PREEMP] recommends the first of these merge strategies for Preemption 431 Priority. 433 Note that with the Admission Priority (as is the case with the 434 Preemption Priority), "Take highest priority" translates into "take 435 the highest numerical value". 437 3.2. Application-Level Resource Priority Policy Element 439 The format of the Application-Level Resource Priority policy element 440 is as follows: 442 0 0 0 1 1 2 2 3 443 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 444 +-------------+-------------+-------------+-------------+ 445 | Length | P-Type = APP_RESOURCE_PRI | 446 +-------------+-------------+-------------+-------------+ 447 // ALRP List // 448 +---------------------------+---------------------------+ 450 Length: The length of the policy element (including the Length and P- 451 Type) is in number of octets (MUST be a multiple of 4) and 452 indicates the end of the ALRP list. 454 P-Type: 16 bits 455 APP_RESOURCE_PRI = To be allocated by IANA 456 (see "IANA Considerations" section) 458 ALRP: 460 0 0 0 1 1 2 2 3 461 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 462 +---------------------------+-------------+-------------+ 463 | ALRP Namespace | Reserved |ALRP Priority| 464 +---------------------------+---------------------------+ 466 ALRP Namespace (Application-Level Resource Priority Namespace): 467 16 bits (unsigned) 468 Contains a numerical value identifying the namespace of the 469 application-level resource priority. This value is encoded 470 as per the "Resource-Priority Namespaces" IANA registry. (See 471 IANA Considerations section for the request to IANA to 472 extend the registry to include this numerical value). 474 Reserved: 8 bits 475 Always 0. 477 ALRP Priority: (Application-Level Resource Priority Priority): 478 8 bits (unsigned) 479 Contains the priority value within the namespace of the 480 application-level resource priority. This value is encoded 481 as per the "Resource-Priority Priority-Value" IANA registry. 482 (See IANA Considerations section for the request to IANA to 483 extend the registry to include this numerical value). 485 3.2.1. 486 Application-Level Resource Priority Modifying and Merging Rules 488 When POLICY_DATA objects are protected by integrity, LPDPs should not 489 attempt to modify them. They MUST be forwarded as-is to ensure their 490 security envelope is not invalidated. 492 In case of multicast, when POLICY_DATA objects are not protected by 493 integrity, LPDPs MAY merge incoming Application-Level Resource 494 Priority elements to reduce their size and number. When they do merge 495 those, LPDPs MUST do so according to the following rule: 497 The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 498 all the ALRPs appearing in the ALRP List of an incoming 499 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 500 once. In other words, the outgoing ALRP List is the union of the 501 incoming ALRP Lists that are merged. 503 As merging is only applicable to Multicast, this rule only applies to 504 Multicast sessions. 506 3.3. Default Handling 508 As specified in section 4.2 of [RSVP-POLICY], Policy Ignorant Nodes 509 (PINs) implement a default handling of POLICY_DATA objects ensuring 510 that those objects can traverse PIN nodes in transit from one PEP to 511 another. This applies to the situations where POLICY_DATA objects 512 contain the Admission Priority Policy Element and the ALRP Policy 513 Element specified in this document, so that those can traverse PIN 514 nodes. 516 Section 4.2 of [RSVP-POLICY] also defines a similar default behavior 517 for policy-capable nodes that do not recognized a particular Policy 518 Element. This applies to the Admission Priority Policy Element and 519 the ALRP Policy Element specified in this document, so that those can 520 traverse policy-capable nodes that do not support this document. 522 4. Security Considerations 524 The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can 525 be signaled by RSVP through encapsulation in a Policy Data object as 526 defined in [RSVP-POLICY]. Therefore, like any other Policy Elements, 527 their integrity can be protected as discussed in section 6 of [RSVP- 528 POLICY] by two optional security mechanisms. The first mechanism 529 relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and 530 [RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are 531 policy capable. With this mechanism, the INTEGRITY object is carried 532 inside RSVP messages. The second mechanism relies on the INTEGRITY 533 object within the POLICY_DATA object to guarantee integrity between 534 RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. 536 4.1. Use of RSVP Authentication between RSVP nighbors 538 This mechanism can be used can be used between RSVP neighbors that 539 are policy capable. The RSVP neighbors use shared keys to compute the 540 cryptographic signature of the RSVP message. [RSVP-GROUPKEYING] 541 discusses key types, key provisioning methods as well as their 542 respective applicability. 544 4.2. Use of INTEGRITY object within the POLICY_DATA object 546 The INTEGRITY object within the POLICY_DATA object can be used to 547 guarantee integrity between non-neighboring RSVP PEPs. 549 Details for computation of the content of the INTEGRITY object can be 550 found in Appendix B of [RSVP-POLICY]. This states that the Policy 551 Decision Point (PDP), at its discretion, and based on destination 552 PEP/PDP or other criteria, selects an Authentication Key and the hash 553 algorithm to be used. Keys to be used between PDPs can be distributed 554 manually or via standard key management protocol for secure key 555 distribution. 557 Note that where non-RSVP hops may exist in between RSVP hops, as well 558 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 559 between PEPs, it may be difficult for the PDP to determine what is 560 the destination PDP for a POLICY_DATA object contained in some RSVP 561 messages (such as a Path message). This is because in those cases the 562 next PEP is not known at the time of forwarding the message. In this 563 situation, key shared across multiple PDPs may be used. This is 564 conceptually similar to the use of key shared across multiple RSVP 565 neighbors discussed in [RSVP-GROUPKEYING]. We observe also that this 566 issue may not exist in some deployment scenarios where a single (or 567 low number of) PDP is used to control all the PEPs of a region (such 568 as an administrative domain). In such scenarios, it may be easy for a 569 PDP to determine what is the next hop PDP, even when the next hop PEP 570 is not known, simply by determining what is the next region that will 571 be traversed (say based on the destination address). 573 5. IANA Considerations 575 As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type 576 values) are to be assigned by IANA as per "IETF Consensus" following 577 the policies outlined in [IANA-CONSIDERATIONS]. 579 IANA needs to allocate two P-Types from the Standard RSVP Policy 580 Element range: 581 - one P-Type to the Admission Priority Policy Element 582 - one P-Type to the Application-Level Resource Priority 583 Policy Element 585 The present document defines an ALRP Namespace field in section 3.2 586 that contains a numerical value identifying the namespace of the 587 application-level resource priority. The IANA already maintains the 588 Resource-Priority Namespaces registry (under the SIP Parameters) 589 listing all such namespace. However, that registry does not currently 590 allocate a numerical value to each namespace. Hence, this document 591 requests the IANA to extend the Resource-Priority Namespace registry 592 in the following ways: 593 - a new column should be added to the registry 594 - the title of the new column should be "Namespace Numerical 595 Value *" 596 - in the Legend, add a line saying "Namespace Numerical 597 Value = the unique numerical value identifying the 598 namespace" 599 - add a line at the bottom of the registry stating the 600 following "* : [RFCXXX] " where XXX is the RFC number of 601 the present document 602 - allocate an actual numerical value to each namespace in 603 the registry and state that value in the new "Namespace 604 numerical Value *" column. 605 A numerical value should be allocated immediately by IANA to all 606 existing namespace. Then, in the future, IANA should automatically 607 allocate a numerical value to any new namespace added to the registry. 609 [draft-ietf-nsis-qspec] also uses numerical values for Resource- 610 Priority Namespaces. To that end, the document requests IANA to 611 create a new registry to allocate numerical values to each namespace. 612 We suggest that the approach above be followed instead (i.e. extend 613 the existing registry) and that [draft-ietf-nsis-qspec] also makes 614 use of the values defined in the new "Namespace numerical Value *" 615 column of the extended existing Resource-Priority Namespace registry. 617 In any case, the IANA should honor only one of the two competing 618 requests (and not both). 620 The present document defines an ALRP Priority field in section 3.2 621 that contains a numerical value identifying the actual application- 622 level resource priority within the application-level resource 623 priority namespace. The IANA already maintains the Resource-Priority 624 Priority-values registry (under the SIP Parameters) listing all such 625 priorities. However, that registry does not currently allocate a 626 numerical value to each priority-value. Hence, this document requests 627 the IANA to extend the Resource-Priority Priority-Values registry in 628 the following ways: 629 - for each namespace, the registry should be structured with 630 two columns 631 - the title of the first column should read "Priority Values 632 (least to greatest)" 633 - the first column should list all the values currently 634 defined in the registry (e.g. for the drsn namespace: 635 "routine", "priority", "immediate", "flash", "flash- 636 override", "flash-override-override" for the drsn 637 namespace) 638 - the title of the second column should read "Priority 639 Numerical Value *" 640 - At the bottom of the registry, add a "Legend" with a line 641 saying "Priority Numerical Value = the unique numerical 642 value identifying the priority within a namespace" 643 - add a line at the bottom of the registry stating the 644 following "* : [RFCXXX] " where XXX is the RFC number of 645 the present document 646 - allocate an actual numerical value to each and state that 647 value in the new "Priority Numerical Value *" column. 648 A numerical value should be allocated immediately by IANA to all 649 existing priority. Then, in the future, IANA should automatically 650 allocate a numerical value to any new namespace added to the registry. 651 The numerical value must be unique within each namespace. Within each 652 namespace, values should be allocated in decreasing order ending with 653 0 (so that the greatest priority is always allocated value 0). For 654 example, in the drsn namespace, "routine" would be allocated 655 numerical value 5 and "flash-override-override" would be allocated 656 numerical value 0. 658 [draft-ietf-nsis-qspec] also uses numerical values for Resource- 659 Priority Priorities. To that end, the document requests IANA to 660 create a new registry to allocate numerical values to each priority. 661 We suggest that the approach above be followed instead (i.e. extend 662 the existing registry) and that [draft-ietf-nsis-qspec] also makes 663 use of the values defined in the new "Priority Numerical Value *" 664 column of the extended existing Resource-Priority Priority-Values 665 registry. In any case, the IANA should honor only one of the two 666 competing requests (and not both). 668 6. Acknowledgments 670 We would like to thank An Nguyen for his encouragement to address 671 this topic and ongoing comments. Also, this document borrows heavily 672 from some of the work of S. Herzog on Preemption Priority Policy 673 Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input 674 into this document. 676 7. Normative References 678 [IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an 679 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 681 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 682 (RSVP)- Functional Specification", RFC 2205, September 1997. 684 [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 685 Cryptographic Authentication", RFC 2747, January 2000. 687 [RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic 688 Authentication -- Updated Message Type Value", RFC 3097, April 2001. 690 [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC 691 2750, January 2000. 693 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 694 Element", RFC 3181, October 2001. 696 [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261, 697 June 2002 699 [SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource 700 Priority for the Session Initiation Protocol (SIP)", RFC4412, 701 February 2006. 703 8. Informative References 705 [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth 706 Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 707 4125, June 2005. 709 [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints 710 Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June 711 2005 713 [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency 714 Telecommunications Service for Real Time Services in the Internet 715 Protocol Suite", RFC 4542, May 2006. 717 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for 718 Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. 720 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 721 for Emergency Telecommunication Service (ETS)", RFC 3690, February 722 2004. 724 [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 725 for Policy-based Admission Control", RFC 2753, January 2000. 727 [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, 728 Recommendation, I.255.3, July, 1990. 730 [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 731 Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, 732 October 2001. 734 [RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "A Framework for 735 RSVP Security using Dynamic Group Keying", draft-behringer-tsvwg- 736 rsvp-security-groupkeying-00.txt, work in progress. 738 [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, 739 "Integration of Resource Management and Session Initiation Protocol 740 (SIP)", RFC 3312, October 2002. 742 Appendix A: Examples of Bandwidth Allocation Model for Admission 743 Priority 745 Sections A.1 and A.2 respectively illustrate how the Maximum 746 Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- 747 RDM] can be used for support of admission priority. Section A.3 748 illustrates how a simple "Priority Bypass Model" can also be used for 749 support of admission priority. 751 For simplicity, operations with only a single "priority" level 752 (beyond non-priority) are illustrated here; However, the reader will 753 appreciate that operations with multiple priority levels can easily 754 be supported with these models. 756 In all the charts below: 757 x represents a non-priority session 758 o represents a priority session 760 A.1 Admission Priority with Maximum Allocation Model (MAM) 762 This section illustrates operations of admission priority when a 763 Maximum Allocation Model (MAM) is used for bandwidth allocation 764 across non-priority traffic and priority traffic. A property of the 765 Maximum Allocation Model is that priority traffic can not use more 766 than the bandwidth made available to priority traffic (even if the 767 non-priority traffic is not using all of the bandwidth available for 768 it). 770 ----------------------- 771 ^ ^ ^ | | ^ 772 . . . | | . 773 Total . . . | | . Bandwidth 774 (1)(2)(3) | | . Available 775 Engi- . . . | | . for non-priority use 776 neered .or.or. | | . 777 . . . | | . 778 Capacity. . . | | . 779 v . . | | v 780 . . |--------------| --- 781 v . | | ^ 782 . | | . Bandwidth available for 783 v | | v priority use 784 ------------------------- 786 Chart 1. MAM Bandwidth Allocation 788 Chart 1 shows a link within a routed network conforming to this 789 document. On this link are two amounts of bandwidth available to two 790 types of traffic: non-priority and priority. 791 If the non-priority traffic load reaches the maximum bandwidth 792 available for non-priority, no additional non-priority sessions can 793 be accepted even if the bandwidth reserved for priority traffic is 794 not currently fully utilized. 796 With the Maximum Allocation Model, in the case where the priority 797 load reaches the maximum bandwidth reserved for priority calls, no 798 additional priority sessions can be accepted. 800 As illustrated in Chart 1, an operator may map the MAM model onto the 801 Engineered Capacity limits according to different policies. At one 802 extreme, where the proportion of priority traffic is reliably known 803 to be fairly small at all times and where there may be some safety 804 margin factored in the engineered capacity limits, the operator may 805 decide to configure the bandwidth available for non-priority use to 806 the full engineered capacity limits; effectively allowing the 807 priority traffic to ride within the safety margin of this engineered 808 capacity. This policy can be seen as an economically attractive 809 approach as all of the engineered capacity is made available to non- 810 priority calls. This policy illustrated as (1) in Chart 1. As an 811 example, if the engineered capacity limit on a given link is X, the 812 operator may configure the bandwidth available to non-priority 813 traffic to X, and the bandwidth available to priority traffic to 5% 814 of X. 816 At the other extreme, where the proportion of priority traffic may be 817 significant at times and the engineered capacity limits are very 818 tight, the operator may decide to configure the bandwidth available 819 to non-priority traffic and the bandwidth available to priority 820 traffic such that their sum is equal to the engineered capacity 821 limits. This guarantees that the total load across non-priority and 822 priority traffic is always below the engineered capacity and, in turn, 823 guarantees there will never be any QoS degradation. However, this 824 policy is less attractive economically as it prevents non-priority 825 calls from using the full engineered capacity, even when there is no 826 or little priority load, which is the majority of time. This policy 827 illustrated as (3) in Chart 1. As an example, if the engineered 828 capacity limit on a given link is X, the operator may configure the 829 bandwidth available to non-priority traffic to 95% of X, and the 830 bandwidth available to priority traffic to 5% of X. 832 Of course, an operator may also strike a balance anywhere in between 833 these two approaches. This policy illustrated as (2) in Chart 1. 835 Chart 2 shows some of the non-priority capacity of this link being 836 used. 838 ----------------------- 839 ^ ^ ^ | | ^ 840 . . . | | . 841 Total . . . | | . Bandwidth 842 . . . | | . Available 843 Engi- . . . | | . for non-priority use 844 neered .or.or. |xxxxxxxxxxxxxx| . 845 . . . |xxxxxxxxxxxxxx| . 846 Capacity. . . |xxxxxxxxxxxxxx| . 847 v . . |xxxxxxxxxxxxxx| v 848 . . |--------------| --- 849 v . | | ^ 850 . | | . Bandwidth available for 851 v | | v priority use 852 ------------------------- 853 Chart 2. Partial load of non-priority calls 855 Chart 3 shows the same amount of non-priority load being used at this 856 link, and a small amount of priority bandwidth being used. 858 ----------------------- 859 ^ ^ ^ | | ^ 860 . . . | | . 861 Total . . . | | . Bandwidth 862 . . . | | . Available 863 Engi- . . . | | . for non-priority use 864 neered .or.or. |xxxxxxxxxxxxxx| . 865 . . . |xxxxxxxxxxxxxx| . 866 Capacity. . . |xxxxxxxxxxxxxx| . 867 v . . |xxxxxxxxxxxxxx| v 868 . . |--------------| --- 869 v . | | ^ 870 . | | . Bandwidth available for 871 v |oooooooooooooo| v priority use 872 ------------------------- 874 Chart 3. Partial load of non-priority calls 875 & partial load of priority calls 877 Chart 4 shows the case where non-priority load equates or exceeds the 878 maximum bandwidth available to non-priority traffic. Note that 879 additional non-priority sessions would be rejected even if the 880 bandwidth reserved for priority sessions is not fully utilized. 882 ----------------------- 883 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 884 . . . |xxxxxxxxxxxxxx| . 885 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 886 . . . |xxxxxxxxxxxxxx| . Available 887 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 888 neered .or.or. |xxxxxxxxxxxxxx| . 889 . . . |xxxxxxxxxxxxxx| . 890 Capacity. . . |xxxxxxxxxxxxxx| . 891 v . . |xxxxxxxxxxxxxx| v 892 . . |--------------| --- 893 v . | | ^ 894 . | | . Bandwidth available for 895 v |oooooooooooooo| v priority use 896 ------------------------- 897 Chart 4. Full non-priority load 898 & partial load of priority calls 900 Chart 5 shows the case where the priority traffic equates or exceeds 901 the bandwidth reserved for such priority traffic. 903 In that case additional priority sessions could not be accepted. Note 904 that this does not mean that such calls are dropped altogether: they 905 may be handled by mechanisms, which are beyond the scope of this 906 particular document (such as establishment through preemption of 907 existing non-priority sessions, or such as queuing of new priority 908 session requests until capacity becomes available again for priority 909 traffic). 911 ----------------------- 912 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 913 . . . |xxxxxxxxxxxxxx| . 914 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 915 . . . |xxxxxxxxxxxxxx| . Available 916 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 917 neered .or.or. |xxxxxxxxxxxxxx| . 918 . . . |xxxxxxxxxxxxxx| . 919 Capacity. . . | | . 920 v . . | | v 921 . . |--------------| --- 922 v . |oooooooooooooo| ^ 923 . |oooooooooooooo| . Bandwidth available for 924 v |oooooooooooooo| v priority use 925 ------------------------- 927 Chart 5. Partial non-priority load & Full priority load 929 A.2 Admission Priority with Russian Dolls Model (RDM) 931 This section illustrates operations of admission priority when a 932 Russian Dolls Model (RDM) is used for bandwidth allocation across 933 non-priority traffic and priority traffic. A property of the Russian 934 Dolls Model is that priority traffic can use the bandwidth which is 935 not currently used by non-priority traffic. 937 As with the MAM model, an operator may map the RDM model onto the 938 Engineered Capacity limits according to different policies. The 939 operator may decide to configure the bandwidth available for non- 940 priority use to the full engineered capacity limits; As an example, 941 if the engineered capacity limit on a given link is X, the operator 942 may configure the bandwidth available to non-priority traffic to X, 943 and the bandwidth available to non-priority and priority traffic to 944 105% of X. 946 Alternatively, the operator may decide to configure the bandwidth 947 available to non-priority and priority traffic to the engineered 948 capacity limits; As an example, if the engineered capacity limit on a 949 given link is X, the operator may configure the bandwidth available 950 to non-priority traffic to 95% of X, and the bandwidth available to 951 non-priority and priority traffic to X. 953 Finally, the operator may decide to strike a balance in between. The 954 considerations presented for these policies in the previous section 955 in the MAM context are equally applicable to RDM. 957 Chart 6 shows the case where only some of the bandwidth available to 958 non-priority traffic is being used and a small amount of priority 959 traffic is in place. In that situation both new non-priority sessions 960 and new priority sessions would be accepted. 962 -------------------------------------- 963 |xxxxxxxxxxxxxx| . ^ 964 |xxxxxxxxxxxxxx| . Bandwidth . 965 |xxxxxxxxxxxxxx| . Available for . 966 |xxxxxxxxxxxxxx| . non-priority . 967 |xxxxxxxxxxxxxx| . use . 968 |xxxxxxxxxxxxxx| . . Bandwidth 969 | | . . available for 970 | | v . non-priority 971 |--------------| --- . and priority 972 | | . use 973 | | . 974 |oooooooooooooo| v 975 --------------------------------------- 977 Chart 6. Partial non-priority load & Partial Aggregate load 979 Chart 7 shows the case where all of the bandwidth available to non- 980 priority traffic is being used and a small amount of priority traffic 981 is in place. In that situation new priority sessions would be 982 accepted but new non-priority sessions would be rejected. 984 -------------------------------------- 985 |xxxxxxxxxxxxxx| . ^ 986 |xxxxxxxxxxxxxx| . Bandwidth . 987 |xxxxxxxxxxxxxx| . Available for . 988 |xxxxxxxxxxxxxx| . non-priority . 989 |xxxxxxxxxxxxxx| . use . 990 |xxxxxxxxxxxxxx| . . Bandwidth 991 |xxxxxxxxxxxxxx| . . available for 992 |xxxxxxxxxxxxxx| v . non-priority 993 |--------------| --- . and priority 994 | | . use 995 | | . 996 |oooooooooooooo| v 997 --------------------------------------- 999 Chart 7. Full non-priority load & Partial Aggregate load 1001 Chart 8 shows the case where only some of the bandwidth available to 1002 non-priority traffic is being used and a heavy load of priority 1003 traffic is in place. In that situation both new non-priority sessions 1004 and new priority sessions would be accepted. 1005 Note that, as illustrated in Chart 7, priority calls use some of the 1006 bandwidth currently not used by non-priority traffic. 1008 -------------------------------------- 1009 |xxxxxxxxxxxxxx| . ^ 1010 |xxxxxxxxxxxxxx| . Bandwidth . 1011 |xxxxxxxxxxxxxx| . Available for . 1012 |xxxxxxxxxxxxxx| . non-priority . 1013 |xxxxxxxxxxxxxx| . use . 1014 | | . . Bandwidth 1015 | | . . available for 1016 |oooooooooooooo| v . non-priority 1017 |--------------| --- . and priority 1018 |oooooooooooooo| . use 1019 |oooooooooooooo| . 1020 |oooooooooooooo| v 1021 --------------------------------------- 1023 Chart 8. Partial non-priority load & Heavy Aggregate load 1025 Chart 9 shows the case where all of the bandwidth available to non- 1026 priority traffic is being used and all of the remaining available 1027 bandwidth is used by priority traffic. In that situation new non- 1028 priority sessions would be rejected. In that situation new priority 1029 sessions could not be accepted right away. Those priority sessions 1030 may be handled by mechanisms, which are beyond the scope of this 1031 particular document (such as established through preemption of 1032 existing non-priority sessions, or such as queuing of new priority 1033 session requests until capacity becomes available again for priority 1034 traffic). 1036 -------------------------------------- 1037 |xxxxxxxxxxxxxx| . ^ 1038 |xxxxxxxxxxxxxx| . Bandwidth . 1039 |xxxxxxxxxxxxxx| . Available for . 1040 |xxxxxxxxxxxxxx| . non-priority . 1041 |xxxxxxxxxxxxxx| . use . 1042 |xxxxxxxxxxxxxx| . . Bandwidth 1043 |xxxxxxxxxxxxxx| . . available for 1044 |xxxxxxxxxxxxxx| v . non-priority 1045 |--------------| --- . and priority 1046 |oooooooooooooo| . use 1047 |oooooooooooooo| . 1048 |oooooooooooooo| v 1049 --------------------------------------- 1051 Chart 9. Full non-priority load & Full Aggregate load 1053 A.3 Admission Priority with Priority Bypass Model (PrBM) 1055 This section illustrates operations of admission priority when a 1056 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1057 across non-priority traffic and priority traffic. With the Priority 1058 Bypass Model, non-priority traffic is subject to resource based 1059 admission control while priority traffic simply bypasses the resource 1060 based admission control. In other words: 1061 - when a non-priority call arrives, this call is subject to 1062 bandwidth admission control and is accepted if the current total load 1063 (aggregate over non-priority and priority traffic) is below the 1064 engineered/allocated bandwidth. 1065 - when a priority call arrives, this call is admitted regardless 1066 of the current load. 1068 A property of this model is that a priority call is never rejected. 1070 The rationale for this simple scheme is that, in practice in some 1071 networks: 1072 - the volume of priority calls is very low for the vast majority 1073 of time, so it may not be economical to completely set aside 1074 bandwidth for priority calls and preclude the utilization of 1075 this bandwidth by normal calls in normal situations 1076 - even in emergency periods where priority calls are more heavily 1077 used, those always still represent a fairly small proportion of 1078 the overall load which can be absorbed within the safety margin 1079 of the engineered capacity limits. Thus, even if they are 1080 admitted beyond the engineered bandwidth threshold, they are 1081 unlikely to result in noticeable QoS degradation. 1083 As with the MAM and RDM model, an operator may map the Priority 1084 Bypass model onto the Engineered Capacity limits according to 1085 different policies. The operator may decide to configure the 1086 bandwidth limit for admission of non-priority traffic to the full 1087 engineered capacity limits; As an example, if the engineered capacity 1088 limit on a given link is X, the operator may configure the bandwidth 1089 limit for non-priority traffic to X. Alternatively, the operator may 1090 decide to configure the bandwidth limit for non-priority traffic to 1091 below the engineered capacity limits (so that the sum of the non- 1092 priority and priority traffic stays below the engineered capacity); 1093 As an example, if the engineered capacity limit on a given link is X, 1094 the operator may configure the bandwidth limit for non-priority 1095 traffic to 95% of X. Finally, the operator may decide to strike a 1096 balance in between. The considerations presented for these policies 1097 in the previous sections in the MAM and RDM contexts are equally 1098 applicable to the Priority Bypass Model. 1100 Chart 10 shows illustrates the bandwidth allocation with the Priority 1101 Bypass Model. 1103 ----------------------- 1104 ^ ^ | | ^ 1105 . . | | . 1106 Total . . | | . Bandwidth Limit 1107 (1) (2) | | . (on non-priority + priority) 1108 Engi- . . | | . for admission 1109 neered . or . | | . of non-priority traffic 1110 . . | | . 1111 Capacity. . | | . 1112 v . | | v 1113 . |--------------| --- 1114 . | | 1115 v | | 1116 | | 1118 Chart 10. Priority Bypass Model Bandwidth Allocation 1120 Chart 11 shows some of the non-priority capacity of this link being 1121 used. In this situation, both new non-priority and new priority calls 1122 would be accepted. 1124 ----------------------- 1125 ^ ^ |xxxxxxxxxxxxxx| ^ 1126 . . |xxxxxxxxxxxxxx| . 1127 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1128 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1129 Engi- . . | | . for admission 1130 neered . or . | | . of non-priority traffic 1131 . . | | . 1132 Capacity. . | | . 1133 v . | | v 1134 . |--------------| --- 1135 . | | 1136 v | | 1137 | | 1139 Chart 11. Partial load of non-priority calls 1141 Chart 12 shows the same amount of non-priority load being used at 1142 this link, and a small amount of priority bandwidth being used. In 1143 this situation, both new non-priority and new priority calls would be 1144 accepted. 1146 ----------------------- 1147 ^ ^ |xxxxxxxxxxxxxx| ^ 1148 . . |xxxxxxxxxxxxxx| . 1149 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1150 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1151 Engi- . . |oooooooooooooo| . for admission 1152 neered . or . | | . of non-priority traffic 1153 . . | | . 1154 Capacity. . | | . 1155 v . | | v 1156 . |--------------| --- 1157 . | | 1158 v | | 1159 | | 1161 Chart 12. Partial load of non-priority calls 1162 & partial load of priority calls 1164 Chart 13 shows the case where aggregate non-priority and priority 1165 load exceeds the bandwidth limit for admission of non-priority 1166 traffic. In this situation, any new non-priority call is rejected 1167 while any new priority call is admitted. 1169 ----------------------- 1170 ^ ^ |xxxxxxxxxxxxxx| ^ 1171 . . |xxxxxxxxxxxxxx| . 1172 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1173 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1174 Engi- . . |oooooooooooooo| . for admission 1175 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1176 . . |xxoxxxxxxoxxxx| . 1177 Capacity. . |oxxxooooxxxxoo| . 1178 v . |xxoxxxooxxxxxx| v 1179 . |--------------| --- 1180 . |oooooooooooooo| 1181 v | | 1182 | | 1184 Chart 13. Full non-priority load 1186 Appendix B: Example Usages of RSVP Extensions 1188 This section provides examples of how RSVP extensions defined in this 1189 document can be used (in conjunctions with other RSVP functionality 1190 and SIP functionality) to enforce different hypothetical policies for 1191 handling Emergency sessions in a given administrative domain. This 1192 Appendix does not provide additional specification. It is only 1193 included in this document for illustration purposes. The content of 1194 this appendix may be moved into a future applicability statement 1195 document. 1197 We assume an environment where SIP is used for session control and 1198 RSVP is used for resource reservation. 1200 In a mild abuse of language, we refer here to "Call Queueing" as the 1201 set of "session" layer capabilities that may be implemented by SIP 1202 user agents to influence their treatment of SIP requests. This may 1203 include the ability to "queue" call requests when those can not be 1204 immediately honored (in some cases with the notion of "bumping", or 1205 "displacement", of less important call request from that queue). It 1206 may include additional mechanisms such as exemption from certain 1207 network management controls, and alternate routing. 1209 We only mention below the RSVP policy elements that are to be 1210 enforced by PEPs. It is assumed that these policy elements are set at 1211 administrative domain boundaries by PDPs. The Admission Priority and 1212 Preemption Priority RSVP policy elements are set by PDPs as a result 1213 of processing the Application Level Resource Priority Policy Element 1214 (which is carried in RSVP messages). 1216 If one wants to implement an emergency service purely based on Call 1217 Queueing, one can achieve this by signaling emergency calls: 1218 * using "Resource-Priority" Header in SIP 1219 * not using Admission-Priority Policy Element in RSVP 1220 * not using Preemption Policy Element in RSVP 1222 If one wants to implement an emergency service based on Call 1223 Queueing and on "prioritized access to network layer resources", one 1224 can achieve this by signaling emergency calls: 1225 * using "Resource-Priority" Header in SIP 1226 * using Admission-Priority Policy Element in RSVP 1227 * not using Preemption Policy Element in RSVP 1228 Emergency calls will not result in preemption of any session. 1229 Different bandwidth allocation models can be used to offer different 1230 "prioritized access to network resources". Just as examples, this 1231 includes strict setting aside of capacity for emergency sessions as 1232 well as simple bypass of admission limits for emergency sessions. 1234 If one wants to implement an emergency service based on Call Queueing, 1235 on "prioritized access to network layer resources", and ensures that 1236 (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 1237 non-emergency sessions are not affected by preemption, one can do 1238 that by signaling emergency calls: 1239 * using "Resource-Priority" Header in SIP 1240 * using Admission-Priority Policy Element in RSVP 1241 * using Preemption Policy Element in RSVP with: 1242 o setup (Emergency-1) > defending (Emergency-2) 1243 o setup (Emergency-2) <= defending (Emergency-1) 1244 o setup (Emergency-1) <= defending (Non-Emergency) 1245 o setup (Emergency-2) <= defending (Non-Emergency) 1247 If one wants to implement an emergency service based on Call Queueing, 1248 on "prioritized access to network layer resources", and ensure that 1249 "emergency" sessions can preempt regular sessions, one could do that 1250 by signaling emergency calls: 1251 * using "Resource-Priority" Header in SIP 1252 * using Admission-Priority Policy Element in RSVP 1253 * using Preemption Policy Element in RSVP with: 1254 o setup (Emergency) > defending (Non-Emergency) 1255 o setup (Non-Emergency) <= defending (Emergency) 1257 If one wants to implement an emergency service based on Call Queueing, 1258 on "prioritized access to network layer resources", and ensure that 1259 "emergency" sessions can partially preempt regular sessions (ie 1260 reduce their reservation size), one could do that by signaling 1261 emergency calls: 1262 * using "Resource-Priority" Header in SIP 1263 * using Admission-Priority Policy Element in RSVP 1264 * using Preemption in Policy Element RSVP with: 1265 o setup (Emergency) > defending (Non-Emergency) 1266 o setup (Non-Emergency) <= defending (Emergency) 1267 * activate RFC4495 RSVP Bandwidth Reduction mechanisms 1269 Authors' Address 1271 Francois Le Faucheur 1272 Cisco Systems, Inc. 1273 Village d'Entreprise Green Side - Batiment T3 1274 400, Avenue de Roumanille 1275 06410 Biot Sophia-Antipolis 1276 France 1277 Email: flefauch@cisco.com 1279 James Polk 1280 Cisco Systems, Inc. 1281 2200 East President George Bush Turnpike 1282 Richardson, Texas 75082 1283 USA 1284 Email: jmpolk@cisco.com 1286 Ken Carlberg 1287 G11 1288 123a Versailles Circle 1289 Towson, MD. 21204 1290 USA 1291 email: carlberg@g11.org.uk 1293 Intellectual Property 1295 The IETF takes no position regarding the validity or scope of any 1296 Intellectual Property Rights or other rights that might be claimed to 1297 pertain to the implementation or use of the technology described in 1298 this document or the extent to which any license under such rights 1299 might or might not be available; nor does it represent that it has 1300 made any independent effort to identify any such rights. Information 1301 on the procedures with respect to rights in RFC documents can be 1302 found in BCP 78 and BCP 79. 1304 Copies of IPR disclosures made to the IETF Secretariat and any 1305 assurances of licenses to be made available, or the result of an 1306 attempt made to obtain a general license or permission for the use of 1307 such proprietary rights by implementers or users of this 1308 specification can be obtained from the IETF on-line IPR repository at 1309 http://www.ietf.org/ipr. 1311 The IETF invites any interested party to bring to its attention any 1312 copyrights, patents or patent applications, or other proprietary 1313 rights that may cover technology that may be required to implement 1314 this standard. Please address the information to the IETF at ietf- 1315 ipr@ietf.org. 1317 Full Copyright Statement 1319 Copyright (C) The IETF Trust (2007). 1321 This document is subject to the rights, licenses and restrictions 1322 contained in BCP 78, and except as set forth therein, the authors 1323 retain all their rights. 1325 This document and the information contained herein are provided on an 1326 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1327 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1328 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1329 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1330 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1331 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.