idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1257. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1270. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 26 pages 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. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 298 has weird spacing: '...riority and h...' -- 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 (October 2006) is 6404 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: 'RFC2119' is mentioned on line 63, but not defined == Missing Reference: 'POLICY-RSVP' is mentioned on line 587, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 589, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3689 (ref. 'EMERG-RQTS') ** Downref: Normative reference to an Informational RFC: RFC 3690 (ref. 'EMERG-TEL') ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'FW-POLICY') ** Downref: Normative reference to an Experimental RFC: RFC 4125 (ref. 'DSTE-MAM') ** Downref: Normative reference to an Experimental RFC: RFC 4127 (ref. 'DSTE-RDM') Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RSVP Extensions for Emergency Services October 2006 3 Internet Draft Francois Le Faucheur 4 James Polk 5 Cisco Systems, Inc. 7 Ken Carlberg 8 G11 9 draft-ietf-tsvwg-emergency-rsvp-00.txt 10 Expires: April 2007 October 2006 12 RSVP Extensions for Emergency Services 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 An Emergency Telecommunications Service (ETS) requires the ability to 39 provide an elevated probability of session establishment to an 40 authorized user in times of network congestion (typically, during a 41 crisis). When supported over the Internet Protocol suite, this may be 42 facilitated through a network layer admission control solution, which 43 supports prioritized access to resources (e.g., bandwidth). These 44 resources may be explicitly set aside for emergency services, or they 45 may be shared with other sessions. 47 RSVP Extensions for Emergency Services October 2006 49 This document specifies RSVP extensions that can be used to support 50 such an admission priority capability at the network layer. Note that 51 these extensions represent one possible solution component in 52 satisfying ETS requirements. Other solution components, or other 53 solutions, are outside the scope of this document. 55 Copyright Notice 56 Copyright (C) The Internet Society (2006). 58 Specification of Requirements 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. 64 Table of Contents 66 1. Introduction...................................................2 67 1.1. Related Work...............................................3 68 1.2. Terminology................................................4 69 1.3. Changes from previous versions.............................4 70 2. Overview of RSVP extensions and Operations.....................5 71 2.1. Operations of Admission Priority..........................8 72 3. New Policy Elements............................................8 73 3.1. Admission Priority Policy Element.........................9 74 3.1.1. Admission Priority Merging Rules 10 75 3.2. Application-Level Resource Priority Policy Element.......10 76 3.2.1. Application-Level Resource Priority Modifying and 77 Merging Rules 12 78 4. Security Considerations.......................................12 79 5. IANA Considerations...........................................12 80 6. Acknowledgments...............................................13 81 7. Normative References..........................................13 82 8. Informative References........................................13 83 Appendix A: Examples of Bandwidth Allocation Model for Admission 84 Priority.........................................................14 85 A.1 Admission Priority with Maximum Allocation Model (MAM)......14 86 A.2 Admission Priority with Russian Dolls Model (RDM)...........18 87 A.3 Admission Priority with Priority Bypass Model (PBM).........20 88 Appendix B: Example Usages of RSVP Extensions....................23 89 Authors' Address.................................................25 91 1. Introduction 93 RSVP Extensions for Emergency Services October 2006 95 [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency 96 Telecommunications Service (ETS), which is an umbrella term 97 identifying those networks and specific services used to support 98 emergency communications. An underlying goal of these documents is to 99 present requirements that elevate the probability of session 100 establishment from an authorized user in times of network congestion 101 (presumably because of a crisis condition). In some extreme cases, 102 the requirement for this probability may reach 100%, but that is a 103 topic subject to policy and most likely local regulation (the latter 104 being outside the scope of this document). 106 Solutions to meet this requirement for elevated session establishment 107 probability may involve session layer capabilities prioritizing 108 access to resources controlled by the session control function. As an 109 example, entities involved in session control (such as SIP user 110 agents, when SIP is the session control protocol in use) can 111 influence their treatment of session establishment requests (such as 112 SIP requests). This may include the ability to "queue" call requests 113 when those can not be immediately honored (in some cases with the 114 notion of "bumping", or "displacement", of less important call 115 request from that queue). It may include additional mechanisms such 116 as exemption from certain network management controls, and alternate 117 routing. 119 Solutions to meet the requirement for elevated session establishment 120 probability may also take advantage of network layer admission 121 control mechanisms supporting admission priority. Networks usually 122 have engineered capacity limits that characterize the maximum load 123 that can be handled (say, on any given link) for a class of traffic 124 while satisfying the quality of service requirements of that traffic 125 class. Admission priority may involve setting aside some network 126 resources (e.g. bandwidth) out of the engineered capacity limits for 127 the emergency services only. Or alternatively, it may involve 128 allowing the emergency related sessions to seize additional resources 129 beyond the engineered capacity limits applied to normal calls. 131 Note: Below, this document references several examples of IP 132 telephony and its use of "calls", which is one form of the term 133 "sessions" (Video over IP and Instant Messaging being other examples 134 that rely on session establishment). For the sake of simplicity, we 135 shall use the widely known term "call" for the remainder of this 136 document. 138 1.1. Related Work 140 [EMERG-IMP] is patterned after [ITU.I.225] and describes an example 141 of one type of prioritized network layer admission control procedure 142 that may be used for emergency services operating over an IP network 143 infrastructure. It discusses initial call set up, as well as 145 RSVP Extensions for Emergency Services October 2006 147 operations after call establishment through maintenance of a 148 continuing call model of the status of all calls. [EMERG-IMP] also 149 describes how these network layer admission control procedures can be 150 realized using the Resource reSerVation Protocol [RSVP] along with 151 its associated protocol suite and extensions, including those for 152 policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user 153 authentication and authorization ([RSVP-ID]) and for integrity and 154 authentication of RSVP messages ([RSVP-CRYPTO-1], [RSVP-CRYPTO-2]). 156 Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption 157 Priority Policy Element specified in [RSVP-PREEMP] can be used to 158 enforce the call preemption that may be needed by some emergency 159 services. 161 In contrast to [EMERG-IMP], this document specifies new RSVP 162 extensions to increase the probability of call completion without 163 preemption. Engineered capacity techniques in the form of bandwidth 164 allocation models are used to satisfy the "admission priority" 165 required by an RSVP capable ETS network. In particular this document 166 specifies two new RSVP Policy Elements allowing the admission 167 priority to be conveyed inside RSVP signaling messages so that RSVP 168 nodes can enforce selective bandwidth admission control decision 169 based on the call admission priority. Appendix A of this document 170 also provides three examples of a bandwidth allocation model, which 171 can be used by RSVP-routers to enforce such admission priority on 172 every link. 174 1.2. Terminology 176 This document assumes the terminology defined in [FW-POLICY]. For 177 convenience, the definition of a few key terms is repeated here: 179 - Policy Decision Point (PDP): The point where policy decisions are 180 made. 182 - Local Policy Decision Point (LPDP): PDP local to the network 183 element 185 - Policy Enforcement Point (PEP): The point where the policy 186 decisions are actually enforced. 188 - Policy Ignorant Node (PIN): A network element that does not 189 explicitly support policy control using the mechanisms defined in 190 [FW-POLICY]. 192 1.3. Changes from previous versions 194 RSVP Extensions for Emergency Services October 2006 196 Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-rsvp- 197 emergency-00 199 The most significant change is: 201 o Extended the Admission Priority field from 3 to 8 bits and 202 inverted the encoding order, in particular for better 203 alignment with NSIS Qspec. 205 Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp- 206 emergency-02 208 The most significant changes are: 210 o modified the Introduction to add additional clarity and to 211 place related work in a better context to the extensions 212 proposed in this draft 214 o Moved bandwidth allocation models to an appendix 216 o Allowed multiple Application-Level Resource Priority inside 217 ALRP Policy Element 219 o Added a 2nd appendix providing examples of RSVP extensions 220 usage 222 Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp- 223 emergency-01 225 The most significant changes were: 227 o adding a second RSVP Policy Element that contains the 228 application-level resource priority requirements (for example 229 as communicated in the SIP Resource-Priority Header) for 230 scenarios where priority calls transits through multiple 231 administrative domains. 233 o adding description of a third bandwidth allocation model 234 example: the Priority Bypass Model 236 o adding discussion on policies for mapping the various 237 bandwidth allocation model over the engineered capacity limits. 239 2. Overview of RSVP extensions and Operations 241 RSVP Extensions for Emergency Services October 2006 243 Let us consider the case where a call requiring ETS type service is 244 to be established, and more specifically that the preference to be 245 granted to this call is in terms of network layer "admission 246 priority" (as opposed to preference granted through preemption of 247 existing calls). By "admission priority" we mean allowing that 248 priority call to seize network layer resources from the engineered 249 capacity that have been set-aside and not made available to normal 250 calls, or alternatively by allowing that call to seize additional 251 resources beyond the engineered capacity limits applied to normal 252 calls. 254 As described in [EMERG-IMP], the session establishment can be 255 conditioned to resource-based and policy-based network layer 256 admission control achieved via RSVP signaling. In the case where the 257 session control protocol is SIP, the use of RSVP-based admission 258 control by SIP is specified in [SIP-RESOURCE]. 260 Devices involved in the session establishment are expected to be 261 aware of the application-level priority requirements of emergency 262 calls. Again considering the case where the session control protocol 263 is SIP, the SIP user agents can be made aware of the resource 264 priority requirements in the case of an emergency call using the 265 Resource-Priority Header mechanism specified in [SIP-PRIORITY]. The 266 end-devices involved in the upper-layer session establishment simply 267 need to copy the application-level resource priority requirements 268 (e.g. as communicated in SIP Resource-Priority Header) inside the new 269 RSVP Application-Level Resource-Priority Policy Element defined in 270 this document. 272 Conveying the application-level resource priority requirements inside 273 the RSVP message allows this application level requirement to be 274 mapped/remapped into a different RSVP "admission priority" at every 275 administrative domain boundary based on the policy applicable in that 276 domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs 277 at the periphery of the policy domain (e.g., in border routers), PDPs 278 would interpret the RSVP Application-Level Resource-Priority Policy 279 Element and map the requirement of the emergency session into an RSVP 280 "admission priority" level. Then, PDPs would convey this information 281 inside the new Admission Priority Policy Element defined in this 282 document. This way, the RSVP admission priority can be communicated 283 to downstream PEPs (ie RSVP Routers) of the same policy domain, which 284 have LPDPs but no controlling PDP. In turn, this means the necessary 285 RSVP Admission priority can be enforced at every RSVP hop, including 286 all the (many) hops which do not have any understanding of 287 Application-Level Resource-Priority semantics. 289 As an example of operation across multiple administrative domains, a 290 first domain might decide to provide network layer admission priority 291 to calls of a given Application Level Resource Priority and map it 293 RSVP Extensions for Emergency Services October 2006 295 into a high RSVP admission control priority inside the Admission 296 Priority Policy Element; while a second domain may decide to not 297 provide admission priority to calls of this same Application Level 298 Resource Priority and hence map it into a low RSVP admission control 299 priority. 301 As another example of operation across multiple administrative 302 domains, we can consider the case where the resource priority header 303 enumerates several namespaces, as explicitly allowed by [SIP- 304 PRIORITY], for support of scenarios where calls traverse multiple 305 administrative domains using different namespace. In that case, the 306 relevant namespace can be used at each domain boundary to map into an 307 RSVP Admission priority for that domain. It is not expected that the 308 RSVP Application-Level Resource-Priority Header Policy Element would 309 be taken into account at RSVP-hops within a given administrative 310 domain. It is expected to be used at administrative domain boundaries 311 only in order to set/reset the RSVP Admission Priority Policy Element. 313 The existence of pre-established inter-domain policy agreements or 314 Service Level Agreements may avoid the need to take real-time action 315 at administrative domain boundaries for mapping/remapping of 316 admission priorities. 318 Mapping/remapping by PDPs may also be applied to boundaries between 319 various signaling protocols, such as those advanced by the NSIS 320 working group. 322 As can be observed, the framework described above for 323 mapping/remapping application level resource priority requirements 324 into an RSVP admission priority can also be used together with [RSVP- 325 PREEMP] for mapping/remapping application level resource priority 326 requirements into an RSVP preemption priority (when preemption is 327 indeed needed). In that case, when processing the RSVP Application- 328 Level Resource-Priority Policy Element, the PDPs at boundaries 329 between administrative domains (or between various QoS signaling 330 protocols) can map it into an RSVP "preemption priority" information. 331 This Preemption priority information comprises a setup preemption 332 level and a defending preemption priority level. This preemption 333 priority information can then be encoded inside the Preemption 334 Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into 335 account at every RSVP-enabled network hop as discussed [EMERG-IMP]. 336 Appendix B provides examples of various hypothetical policies for 337 emergency call handling, some of them involving admission priority, 338 some of them involving both admission priority and preemption 339 priority. Appendix B also identifies how the Application-Level 340 Resource Priority need to be mapped into RSVP policy elements by the 341 PDPs to realize these policies. 343 RSVP Extensions for Emergency Services October 2006 345 2.1. Operations of Admission Priority 347 The RSVP Admission Priority policy element defined in this document 348 allows admission bandwidth to be allocated preferentially to an 349 authorized priority service. Multiple models of bandwidth allocation 350 MAY be used to that end. 352 A number of bandwidth allocation models have been defined in the IETF 353 for allocation of bandwidth across different classes of traffic 354 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 355 Those include the Maximum Allocation Model (MAM) defined in [DSTE- 356 MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These 357 same models MAY however be applied for allocation of bandwidth across 358 different levels of admission priority as defined in this document. 359 Appendix A provides an illustration of how these bandwidth allocation 360 models can be applied for such purposes and introduces an additional 361 bandwidth allocation model that we term the Priority Bypass Model 362 (PBM). It is important to note that the models described and 363 illustrated in Appendix A are only informative and do not represent a 364 recommended course of action. 366 3. New Policy Elements 368 The Framework document for policy-based admission control [FW-POLICY] 369 describes the various components that participate in policy decision 370 making (i.e., PDP, PEP and LPDP). 372 As described in section 2 of the present document, the Application- 373 Level Resource Priority Policy Element and the Admission Priority 374 Policy Element serve different roles in this framework: 376 - the Application-Level Resource Priority Policy Element conveys 377 application level information and is processed by PDPs 379 - the emphasis of Admission Priority Policy Element is to be 380 simple, stateless, and light-weight such that it can be 381 processed internally within a node's LPDP. It can then be 382 enforced internally within a node's PEP. It is set by PDPs 383 based on processing of the Application-Level Resource Priority 384 Policy Element. 386 [RSVP-POLICY] defines extensions for supporting generic policy based 387 admission control in RSVP. These extensions include the standard 388 format of POLICY_DATA objects and a description of RSVP handling of 389 policy events. 391 The POLICY_DATA object contains one or more of Policy Elements, each 392 representing a different (and perhaps orthogonal) policy. As an 394 RSVP Extensions for Emergency Services October 2006 396 example, [RSVP-PREEMP] specifies the Preemption Priority Policy 397 Element. 399 This document defines two new Policy Elements called: 400 - the Admission Priority Policy Element 401 - the Application-Level Resource Priority Policy Element 403 3.1. Admission Priority Policy Element 405 The format of the Admission Priority policy element is as follows: 407 +-------------+-------------+-------------+-------------+ 408 | Length | P-Type = ADMISSION_PRI | 409 +-------------+-------------+-------------+-------------+ 410 | Flags | M. Strategy | Error Code | Reserved | 411 +-------------+-------------+-------------+-------------+ 412 |Adm. Priority| Reserved | 413 +---------------------------+---------------------------+ 415 Length: 16 bits 416 Always 12. The overall length of the policy element, in bytes. 418 P-Type: 16 bits 419 ADMISSION_PRI = To be allocated by IANA 420 (see "IANA Considerations" section) 422 Flags: Reserved (MUST be set to zero on transmit and ignored on 423 receive) 425 Merge Strategy: 8 bit (only applicable to multicast flows) 426 1 Take priority of highest QoS 427 2 Take highest priority 428 3 Force Error on heterogeneous merge 430 Error code: 8 bits (only applicable to multicast flows) 431 0 NO_ERROR Value used for regular ADMISSION_PRI elements 432 2 HETEROGENEOUS This element encountered heterogeneous merge 434 Reserved: 8 bits 435 Always 0. 437 Adm. Priority (Admission Priority): 8 bits (unsigned) 438 The admission control priority of the flow, in terms of access 439 to network bandwidth in order to provide higher probability of 440 call completion to selected flows. Higher values represent 441 higher Priority. 443 Bandwidth allocation models such as those described in Appendix 445 RSVP Extensions for Emergency Services October 2006 447 A are to be used by the RSVP router to achieve such increased 448 probability of call completion. The admission priority value 449 effectively indicates which bandwidth constraint(s) of the 450 bandwidth constraint model in use is(are) applicable to 451 admission of this RSVP reservation. 453 Reserved: 16 bits 454 Always 0. 456 Note that the Admission Priority Policy Element does NOT indicate 457 that this RSVP reservation is to preempt any other RSVP reservation. 458 If a priority session justifies both admission priority and 459 preemption priority, the corresponding RSVP reservation needs to 460 carry both an Admission Priority Policy Element and a Preemption 461 Priority Policy Element. The Admission Priority and Preemption 462 Priority are handled by LPDPs and PEPs as orthogonal and independent 463 mechanisms. 465 3.1.1. 466 Admission Priority Merging Rules 468 This section discusses alternatives for dealing with RSVP admission 469 priority in case of merging of reservations. As merging is only 470 applicable to multicast, this section also only applies to multicast 471 sessions. 473 The rules for merging Admission Priority Policy Elements are the same 474 as those defined in [RSVP-PREEMP] for merging Preemption Priority 475 Policy Elements. In particular, the following merging strategies are 476 supported: 477 - Take priority of highest QoS 478 - Take highest priority 479 - Force Error on heterogeneous merge. 480 The only difference with [RSVP-PREEMP] is that this document does not 481 recommend any merge strategies for Admission Priority while [RSVP- 482 PREEMP] recommends the first of these merge strategies for Preemption 483 Priority. 485 Note that with the Admission Priority, "Take Highest Priority" 486 translates into "take the lowest numerical value", while with the 487 Preemption Priority it translates into "take the highest numerical 488 value". 490 3.2. Application-Level Resource Priority Policy Element 492 The format of the Application-Level Resource Priority policy element 493 is as follows: 495 +-------------+-------------+-------------+-------------+ 497 RSVP Extensions for Emergency Services October 2006 499 | Length | P-Type = APP_RESOURCE_PRI | 500 +-------------+-------------+-------------+-------------+ 501 // ALRP List // 502 +---------------------------+---------------------------+ 504 Length: The length of the policy element (including the Length and P- 505 Type) is in number of octets (MUST be a multiple of 4) and 506 indicates the end of the ALRP list. 508 P-Type: 16 bits 509 APP_RESOURCE_PRI = To be allocated by IANA 510 (see "IANA Considerations" section) 512 ARLP: 514 +---------------------------+---------------------------+ 515 | ALRP Namespace |ALRP Priority| Reserved | 516 +---------------------------+---------------------------+ 518 ALRP Namespace (Application-Level Resource Priority Namespace): 519 16 bits (unsigned) 520 Contains the namespace of the application-level resource 521 priority. This is encoded as a numerical value which 522 represents the position of the namespace in the "Resource- 523 Priority Namespace" IANA registry, starting with 0. Creation 524 of this registry has been requested to IANA in [SIP- 525 PRIORITY]. 526 For example, as "drsn", "dsn", "q735", "ets" and "wps" are 527 currently the first, second, third, fourth and fifth 528 namespaces defined in the "Resource-Priority Namespace" 529 registry, those are respectively encoded as value 0, 1, 2, 3 530 and 4. 532 ALRP Priority: (Application-Level Resource Priority Priority): 533 8 bits (unsigned) 534 Contains the priority value within the namespace of the 535 application-level resource priority. This is encoded as a 536 numerical value which represents the priority defined in the 537 "Resource-Priority Namespace" IANA registry for the 538 considered namespace, starting from 0 for the highest 539 priority and increasing as priority decreases. 540 For example, as "flash-override", "flash", "immediate", 541 "priority" and "routine" are the priorities in decreasing 542 order of priority registered for the "dsn" namespace, those 543 are respectively encoded as value 0, 1, 2, 3 and 4. As 544 another example, as "flash-override-override", "flash- 545 override", "flash", "immediate", "priority" and "routine" 546 are the priorities in decreasing order of priority 548 RSVP Extensions for Emergency Services October 2006 550 registered for the "drsn" namespace, those are respectively 551 encoded as value 0, 1, 2, 3, 4 and 5. 553 Reserved: 16 bits 554 Always 0. 556 3.2.1. 557 Application-Level Resource Priority Modifying and Merging Rules 559 When POLICY_DATA objects are protected by integrity, LPDPs should not 560 attempt to modify them. They MUST be forwarded as-is to ensure their 561 security envelope is not invalidated. 563 In case of multicast, when POLICY_DATA objects are not protected by 564 integrity, LPDPs MAY merge incoming Application-Level Resource 565 Priority elements to reduce their size and number. When they do merge 566 those, LPDPs MUST do so according to the following rule: 568 The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 569 all the ALRPs appearing in the ALRP List of an incoming 570 APP_RESOURCE_PR element. A given ALRP MUST NOT appear more than 571 once. In other words, the outgoing ALRP List is the reunion of 572 the incoming ARLP Lists that are merged. 574 As merging is only applicable to Multicast, this rule only applies to 575 Multicast sessions. 577 4. Security Considerations 579 The integrity of ADMISSION_PRI and APP_RESOURCE_PRI is guaranteed, as 580 any other policy element, by the encapsulation into a Policy Data 581 object [RSVP-POLICY]. The two optional security mechanisms discussed 582 in section 6 of [RSVP-POLICY] can be used to protect the 583 ADMISSION_PRI and APP_RESOURCE_PRI policy elements. 585 5. IANA Considerations 587 As specified in [POLICY-RSVP], Standard RSVP Policy Elements (P-type 588 values) are to be assigned by IANA as per "IETF Consensus" following 589 the policies outlined in [IANA-CONSIDERATIONS]. 591 IANA needs to allocate two P-Types from the Standard RSVP Policy 592 Element range: 593 - one P-Type to the Admission Priority Policy Element 594 - one P-Type to the Application-Level Resource Priority 595 Policy Element 597 RSVP Extensions for Emergency Services October 2006 599 6. Acknowledgments 601 We would like to thank An Nguyen for his encouragement to address 602 this topic and ongoing comments. Also, this document borrows heavily 603 from some of the work of S. Herzog on Preemption Priority Policy 604 Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input 605 into this document. 607 7. Normative References 609 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for 610 Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. 612 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 613 for Emergency Telecommunication Service (ETS)", RFC 3690, February 614 2004. 616 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 617 (RSVP)- Functional Specification", RFC 2205, September 1997. 619 [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A 620 Framework for Policy-based Admission Control", RFC 2753, January 2000. 622 [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC 623 2750, January 2000. 625 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 626 Element", RFC 3181, October 2001. 628 [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth 629 Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 630 4125, June 2005. 632 [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints 633 Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June 634 2005 636 [SIP-PRIORITY] H. Schulzrinne & J. Polk. Communications Resource 637 Priority for the Session Initiation Protocol (SIP), RFC4412, February 638 2006. 640 8. Informative References 642 [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency 643 Telecommunications Service for Real Time Services in the Internet 644 Protocol Suite", RFC 4542, May 2006. 646 RSVP Extensions for Emergency Services October 2006 648 [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, 649 Recommendation, I.255.3, July, 1990. 651 [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 652 Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, 653 October 2001. 655 [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 656 Cryptographic Authentication", RFC 2747, January 2000. 658 [RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic 659 Authentication -- Updated Message Type Value", RFC 3097, April 2001. 661 [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, 662 "Integration of Resource Management and Session Initiation Protocol 663 (SIP)", RFC 3312, October 2002. 665 Appendix A: Examples of Bandwidth Allocation Model for Admission 666 Priority 668 Sections A.1 and A.2 respectively illustrate how the Maximum 669 Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- 670 RDM] can be used for support of admission priority. Section A.3 671 illustrates how a simple "Priority Bypass Model" can also be used for 672 support of admission priority. 674 For simplicity, operations with only a single "priority" level 675 (beyond non-priority) are illustrated here; However, the reader will 676 appreciate that operations with multiple priority levels can easily 677 be supported with these models. 679 In all the charts below: 680 x represents a non-priority session 681 o represents a priority session 683 A.1 Admission Priority with Maximum Allocation Model (MAM) 685 This section illustrates operations of admission priority when a 686 Maximum Allocation Model (MAM) is used for bandwidth allocation 687 across non-priority traffic and priority traffic. A property of the 688 Maximum Allocation Model is that priority traffic can not use more 689 than the bandwidth made available to priority traffic (even if the 690 non-priority traffic is not using all of the bandwidth available for 691 it). 693 ----------------------- 695 RSVP Extensions for Emergency Services October 2006 697 ^ ^ ^ | | ^ 698 . . . | | . 699 Total . . . | | . Bandwidth 700 (1)(2)(3) | | . Available 701 Engi- . . . | | . for non-priority use 702 neered .or.or. | | . 703 . . . | | . 704 Capacity. . . | | . 705 v . . | | v 706 . . |--------------| --- 707 v . | | ^ 708 . | | . Bandwidth available for 709 v | | v priority use 710 ------------------------- 712 Chart 1. MAM Bandwidth Allocation 714 Chart 1 shows a link within a routed network conforming to this 715 document. On this link are two amounts of bandwidth available to two 716 types of traffic: non-priority and priority. 717 If the non-priority traffic load reaches the maximum bandwidth 718 available for non-priority, no additional non-priority sessions can 719 be accepted even if the bandwidth reserved for priority traffic is 720 not currently fully utilized. 722 With the Maximum Allocation Model, in the case where the priority 723 load reaches the maximum bandwidth reserved for priority calls, no 724 additional priority sessions can be accepted. 726 As illustrated in Chart 1, an operator may map the MAM model onto the 727 Engineered Capacity limits according to different policies. At one 728 extreme, where the proportion of priority traffic is reliably known 729 to be fairly small at all times and where there may be some safety 730 margin factored in the engineered capacity limits, the operator may 731 decide to configure the bandwidth available for non-priority use to 732 the full engineered capacity limits; effectively allowing the 733 priority traffic to ride within the safety margin of this engineered 734 capacity. This policy can be seen as an economically attractive 735 approach as all of the engineered capacity is made available to non- 736 priority calls. This policy illustrated as (1) in Chart 1. As an 737 example, if the engineered capacity limit on a given link is X, the 738 operator may configure the bandwidth available to non-priority 739 traffic to X, and the bandwidth available to priority traffic to 5% 740 of X. 742 At the other extreme, where the proportion of priority traffic may be 743 significant at times and the engineered capacity limits are very 744 tight, the operator may decide to configure the bandwidth available 745 to non-priority traffic and the bandwidth available to priority 747 RSVP Extensions for Emergency Services October 2006 749 traffic such that their sum is equal to the engineered capacity 750 limits. This guarantees that the total load across non-priority and 751 priority traffic is always below the engineered capacity and, in turn, 752 guarantees there will never be any QoS degradation. However, this 753 policy is less attractive economically as it prevents non-priority 754 calls from using the full engineered capacity, even when there is no 755 or little priority load, which is the majority of time. This policy 756 illustrated as (3) in Chart 1. As an example, if the engineered 757 capacity limit on a given link is X, the operator may configure the 758 bandwidth available to non-priority traffic to 95% of X, and the 759 bandwidth available to priority traffic to 5% of X. 761 Of course, an operator may also strike a balance anywhere in between 762 these two approaches. This policy illustrated as (2) in Chart 1. 764 Chart 2 shows some of the non-priority capacity of this link being 765 used. 767 ----------------------- 768 ^ ^ ^ | | ^ 769 . . . | | . 770 Total . . . | | . Bandwidth 771 . . . | | . Available 772 Engi- . . . | | . for non-priority use 773 neered .or.or. |xxxxxxxxxxxxxx| . 774 . . . |xxxxxxxxxxxxxx| . 775 Capacity. . . |xxxxxxxxxxxxxx| . 776 v . . |xxxxxxxxxxxxxx| v 777 . . |--------------| --- 778 v . | | ^ 779 . | | . Bandwidth available for 780 v | | v priority use 781 ------------------------- 782 Chart 2. Partial load of non-priority calls 784 Chart 3 shows the same amount of non-priority load being used at this 785 link, and a small amount of priority bandwidth being used. 787 ----------------------- 788 ^ ^ ^ | | ^ 789 . . . | | . 790 Total . . . | | . Bandwidth 791 . . . | | . Available 792 Engi- . . . | | . for non-priority use 793 neered .or.or. |xxxxxxxxxxxxxx| . 794 . . . |xxxxxxxxxxxxxx| . 795 Capacity. . . |xxxxxxxxxxxxxx| . 796 v . . |xxxxxxxxxxxxxx| v 798 RSVP Extensions for Emergency Services October 2006 800 . . |--------------| --- 801 v . | | ^ 802 . | | . Bandwidth available for 803 v |oooooooooooooo| v priority use 804 ------------------------- 806 Chart 3. Partial load of non-priority calls 807 & partial load of priority calls 809 Chart 4 shows the case where non-priority load equates or exceeds the 810 maximum bandwidth available to non-priority traffic. Note that 811 additional non-priority sessions would be rejected even if the 812 bandwidth reserved for priority sessions is not fully utilized. 814 ----------------------- 815 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 816 . . . |xxxxxxxxxxxxxx| . 817 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 818 . . . |xxxxxxxxxxxxxx| . Available 819 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 820 neered .or.or. |xxxxxxxxxxxxxx| . 821 . . . |xxxxxxxxxxxxxx| . 822 Capacity. . . |xxxxxxxxxxxxxx| . 823 v . . |xxxxxxxxxxxxxx| v 824 . . |--------------| --- 825 v . | | ^ 826 . | | . Bandwidth available for 827 v |oooooooooooooo| v priority use 828 ------------------------- 829 Chart 4. Full non-priority load 830 & partial load of priority calls 832 Chart 5 shows the case where the priority traffic equates or exceeds 833 the bandwidth reserved for such priority traffic. 835 In that case additional priority sessions could not be accepted. Note 836 that this does not mean that such calls are dropped altogether: they 837 may be handled by mechanisms, which are beyond the scope of this 838 particular document (such as establishment through preemption of 839 existing non-priority sessions, or such as queuing of new priority 840 session requests until capacity becomes available again for priority 841 traffic). 843 ----------------------- 844 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 845 . . . |xxxxxxxxxxxxxx| . 846 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 848 RSVP Extensions for Emergency Services October 2006 850 . . . |xxxxxxxxxxxxxx| . Available 851 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 852 neered .or.or. |xxxxxxxxxxxxxx| . 853 . . . |xxxxxxxxxxxxxx| . 854 Capacity. . . | | . 855 v . . | | v 856 . . |--------------| --- 857 v . |oooooooooooooo| ^ 858 . |oooooooooooooo| . Bandwidth available for 859 v |oooooooooooooo| v priority use 860 ------------------------- 862 Chart 5. Partial non-priority load & Full priority load 864 A.2 Admission Priority with Russian Dolls Model (RDM) 866 This section illustrates operations of admission priority when a 867 Russian Dolls Model (RDM) is used for bandwidth allocation across 868 non-priority traffic and priority traffic. A property of the Russian 869 Dolls Model is that priority traffic can use the bandwidth which is 870 not currently used by non-priority traffic. 872 As with the MAM model, an operator may map the RDM model onto the 873 Engineered Capacity limits according to different policies. The 874 operator may decide to configure the bandwidth available for non- 875 priority use to the full engineered capacity limits; As an example, 876 if the engineered capacity limit on a given link is X, the operator 877 may configure the bandwidth available to non-priority traffic to X, 878 and the bandwidth available to non-priority and priority traffic to 879 105% of X. 881 Alternatively, the operator may decide to configure the bandwidth 882 available to non-priority and priority traffic to the engineered 883 capacity limits; As an example, if the engineered capacity limit on a 884 given link is X, the operator may configure the bandwidth available 885 to non-priority traffic to 95% of X, and the bandwidth available to 886 non-priority and priority traffic to X. 888 Finally, the operator may decide to strike a balance in between. The 889 considerations presented for these policies in the previous section 890 in the MAM context are equally applicable to RDM. 892 Chart 6 shows the case where only some of the bandwidth available to 893 non-priority traffic is being used and a small amount of priority 894 traffic is in place. In that situation both new non-priority sessions 895 and new priority sessions would be accepted. 897 RSVP Extensions for Emergency Services October 2006 899 -------------------------------------- 900 |xxxxxxxxxxxxxx| . ^ 901 |xxxxxxxxxxxxxx| . Bandwidth . 902 |xxxxxxxxxxxxxx| . Available for . 903 |xxxxxxxxxxxxxx| . non-priority . 904 |xxxxxxxxxxxxxx| . use . 905 |xxxxxxxxxxxxxx| . . Bandwidth 906 | | . . available for 907 | | v . non-priority 908 |--------------| --- . and priority 909 | | . use 910 | | . 911 |oooooooooooooo| v 912 --------------------------------------- 914 Chart 6. Partial non-priority load & Partial Aggregate load 916 Chart 7 shows the case where all of the bandwidth available to non- 917 priority traffic is being used and a small amount of priority traffic 918 is in place. In that situation new priority sessions would be 919 accepted but new non-priority sessions would be rejected. 921 -------------------------------------- 922 |xxxxxxxxxxxxxx| . ^ 923 |xxxxxxxxxxxxxx| . Bandwidth . 924 |xxxxxxxxxxxxxx| . Available for . 925 |xxxxxxxxxxxxxx| . non-priority . 926 |xxxxxxxxxxxxxx| . use . 927 |xxxxxxxxxxxxxx| . . Bandwidth 928 |xxxxxxxxxxxxxx| . . available for 929 |xxxxxxxxxxxxxx| v . non-priority 930 |--------------| --- . and priority 931 | | . use 932 | | . 933 |oooooooooooooo| v 934 --------------------------------------- 936 Chart 7. Full non-priority load & Partial Aggregate load 938 Chart 8 shows the case where only some of the bandwidth available to 939 non-priority traffic is being used and a heavy load of priority 940 traffic is in place. In that situation both new non-priority sessions 941 and new priority sessions would be accepted. 942 Note that, as illustrated in Chart 7, priority calls use some of the 943 bandwidth currently not used by non-priority traffic. 945 -------------------------------------- 947 RSVP Extensions for Emergency Services October 2006 949 |xxxxxxxxxxxxxx| . ^ 950 |xxxxxxxxxxxxxx| . Bandwidth . 951 |xxxxxxxxxxxxxx| . Available for . 952 |xxxxxxxxxxxxxx| . non-priority . 953 |xxxxxxxxxxxxxx| . use . 954 | | . . Bandwidth 955 | | . . available for 956 |oooooooooooooo| v . non-priority 957 |--------------| --- . and priority 958 |oooooooooooooo| . use 959 |oooooooooooooo| . 960 |oooooooooooooo| v 961 --------------------------------------- 963 Chart 8. Partial non-priority load & Heavy Aggregate load 965 Chart 9 shows the case where all of the bandwidth available to non- 966 priority traffic is being used and all of the remaining available 967 bandwidth is used by priority traffic. In that situation new non- 968 priority sessions would be rejected. In that situation new priority 969 sessions could not be accepted right away. Those priority sessions 970 may be handled by mechanisms, which are beyond the scope of this 971 particular document (such as established through preemption of 972 existing non-priority sessions, or such as queuing of new priority 973 session requests until capacity becomes available again for priority 974 traffic). 976 -------------------------------------- 977 |xxxxxxxxxxxxxx| . ^ 978 |xxxxxxxxxxxxxx| . Bandwidth . 979 |xxxxxxxxxxxxxx| . Available for . 980 |xxxxxxxxxxxxxx| . non-priority . 981 |xxxxxxxxxxxxxx| . use . 982 |xxxxxxxxxxxxxx| . . Bandwidth 983 |xxxxxxxxxxxxxx| . . available for 984 |xxxxxxxxxxxxxx| v . non-priority 985 |--------------| --- . and priority 986 |oooooooooooooo| . use 987 |oooooooooooooo| . 988 |oooooooooooooo| v 989 --------------------------------------- 991 Chart 9. Full non-priority load & Full Aggregate load 993 A.3 Admission Priority with Priority Bypass Model (PBM) 995 RSVP Extensions for Emergency Services October 2006 997 This section illustrates operations of admission priority when a 998 simple Priority Bypass Model (PBM) is used for bandwidth allocation 999 across non-priority traffic and priority traffic. With the Priority 1000 Bypass Model, non-priority traffic is subject to resource based 1001 admission control while priority traffic simply bypasses the resource 1002 based admission control. In other words: 1003 - when a non-priority call arrives, this call is subject to 1004 bandwidth admission control and is accepted if the current total load 1005 (aggregate over non-priority and priority traffic) is below the 1006 engineered/allocated bandwidth. 1007 - when a priority call arrives, this call is admitted regardless 1008 of the current load. 1010 A property of this model is that a priority call is never rejected. 1012 The rationale for this simple scheme is that, in practice in some 1013 networks: 1014 - the volume of priority calls is very low for the vast majority 1015 of time, so it may not be economical to completely set aside 1016 bandwidth for priority calls and preclude the utilization of 1017 this bandwidth by normal calls in normal situations 1018 - even in emergency periods where priority calls are more heavily 1019 used, those always still represent a fairly small proportion of 1020 the overall load which can be absorbed within the safety margin 1021 of the engineered capacity limits. Thus, even if they are 1022 admitted beyond the engineered bandwidth threshold, they are 1023 unlikely to result in noticeable QoS degradation. 1025 As with the MAM and RDM model, an operator may map the Priority 1026 Bypass model onto the Engineered Capacity limits according to 1027 different policies. The operator may decide to configure the 1028 bandwidth limit for admission of non-priority traffic to the full 1029 engineered capacity limits; As an example, if the engineered capacity 1030 limit on a given link is X, the operator may configure the bandwidth 1031 limit for non-priority traffic to X. Alternatively, the operator may 1032 decide to configure the bandwidth limit for non-priority traffic to 1033 below the engineered capacity limits (so that the sum of the non- 1034 priority and priority traffic stays below the engineered capacity); 1035 As an example, if the engineered capacity limit on a given link is X, 1036 the operator may configure the bandwidth limit for non-priority 1037 traffic to 95% of X. Finally, the operator may decide to strike a 1038 balance in between. The considerations presented for these policies 1039 in the previous sections in the MAM and RDM contexts are equally 1040 applicable to the Priority Bypass Model. 1042 Chart 10 shows illustrates the bandwidth allocation with the Priority 1043 Bypass Model. 1045 ----------------------- 1047 RSVP Extensions for Emergency Services October 2006 1049 ^ ^ | | ^ 1050 . . | | . 1051 Total . . | | . Bandwidth Limit 1052 (1) (2) | | . (on non-priority + priority) 1053 Engi- . . | | . for admission 1054 neered . or . | | . of non-priority traffic 1055 . . | | . 1056 Capacity. . | | . 1057 v . | | v 1058 . |--------------| --- 1059 . | | 1060 v | | 1061 | | 1063 Chart 10. Priority Bypass Model Bandwidth Allocation 1065 Chart 11 shows some of the non-priority capacity of this link being 1066 used. In this situation, both new non-priority and new priority calls 1067 would be accepted. 1069 ----------------------- 1070 ^ ^ |xxxxxxxxxxxxxx| ^ 1071 . . |xxxxxxxxxxxxxx| . 1072 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1073 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1074 Engi- . . | | . for admission 1075 neered . or . | | . of non-priority traffic 1076 . . | | . 1077 Capacity. . | | . 1078 v . | | v 1079 . |--------------| --- 1080 . | | 1081 v | | 1082 | | 1084 Chart 11. Partial load of non-priority calls 1086 Chart 12 shows the same amount of non-priority load being used at 1087 this link, and a small amount of priority bandwidth being used. In 1088 this situation, both new non-priority and new priority calls would be 1089 accepted. 1091 ----------------------- 1092 ^ ^ |xxxxxxxxxxxxxx| ^ 1093 . . |xxxxxxxxxxxxxx| . 1094 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1095 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1096 Engi- . . |oooooooooooooo| . for admission 1098 RSVP Extensions for Emergency Services October 2006 1100 neered . or . | | . of non-priority traffic 1101 . . | | . 1102 Capacity. . | | . 1103 v . | | v 1104 . |--------------| --- 1105 . | | 1106 v | | 1107 | | 1109 Chart 12. Partial load of non-priority calls 1110 & partial load of priority calls 1112 Chart 13 shows the case where aggregate non-priority and priority 1113 load exceeds the bandwidth limit for admission of non-priority 1114 traffic. In this situation, any new non-priority call is rejected 1115 while any new priority call is admitted. 1117 ----------------------- 1118 ^ ^ |xxxxxxxxxxxxxx| ^ 1119 . . |xxxxxxxxxxxxxx| . 1120 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1121 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1122 Engi- . . |oooooooooooooo| . for admission 1123 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1124 . . |xxoxxxxxxoxxxx| . 1125 Capacity. . |oxxxooooxxxxoo| . 1126 v . |xxoxxxooxxxxxx| v 1127 . |--------------| --- 1128 . |oooooooooooooo| 1129 v | | 1130 | | 1132 Chart 13. Full non-priority load 1134 Appendix B: Example Usages of RSVP Extensions 1136 This section provides examples of how RSVP extensions defined in this 1137 document can be used (in conjunctions with other RSVP functionality 1138 and SIP functionality) to enforce different hypothetical policies for 1139 handling Emergency sessions in a given administrative domain. This 1140 Appendix does not provide additional specification. It is only 1141 included in this document for illustration purposes. The content of 1142 this appendix may be moved into a future applicability statement 1143 document. 1145 RSVP Extensions for Emergency Services October 2006 1147 We assume an environment where SIP is used for session control and 1148 RSVP is used for resource reservation. 1150 In a mild abuse of language, we refer here to "Call Queueing" as the 1151 set of "session" layer capabilities that may be implemented by SIP 1152 user agents to influence their treatment of SIP requests. This may 1153 include the ability to "queue" call requests when those can not be 1154 immediately honored (in some cases with the notion of "bumping", or 1155 "displacement", of less important call request from that queue). It 1156 may include additional mechanisms such as exemption from certain 1157 network management controls, and alternate routing. 1159 We only mention below the RSVP policy elements that are to be 1160 enforced by PEPs. It is assumed that these policy elements are set at 1161 administrative domain boundaries by PDPs. The Admission Priority and 1162 Preemption Priority RSVP policy elements are set by PDPs as a result 1163 of processing the Application Level Resource Priority Policy Element 1164 (which is carried in RSVP messages). 1166 If one wants to implement an emergency service purely based on Call 1167 Queueing, one can achieve this by signaling emergency calls: 1168 * using "Resource-Priority" Header in SIP 1169 * not using Admission-Priority Policy Element in RSVP 1170 * not using Preemption Policy Element in RSVP 1172 If one wants to implement an emergency service based on Call 1173 Queueing and on "prioritized access to network layer resources", one 1174 can achieve this by signaling emergency calls: 1175 * using "Resource-Priority" Header in SIP 1176 * using Admission-Priority Policy Element in RSVP 1177 * not using Preemption Policy Element in RSVP 1178 Emergency calls will not result in preemption of any session. 1179 Different bandwidth allocation models can be used to offer different 1180 "prioritized access to network resources". Just as examples, this 1181 includes strict setting aside of capacity for emergency sessions as 1182 well as simple bypass of admission limits for emergency sessions. 1184 If one wants to implement an emergency service based on Call Queueing, 1185 on "prioritized access to network layer resources", and ensures that 1186 (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 1187 non-emergency sessions are not affected by preemption, one can do 1188 that by signaling emergency calls: 1189 * using "Resource-Priority" Header in SIP 1190 * using Admission-Priority Policy Element in RSVP 1191 * using Preemption Policy Element in RSVP with: 1192 o setup (Emergency-1) > defending (Emergency-2) 1193 o setup (Emergency-2) <= defending (Emergency-1) 1194 o setup (Emergency-1) <= defending (Non-Emergency) 1195 o setup (Emergency-2) <= defending (Non-Emergency) 1197 RSVP Extensions for Emergency Services October 2006 1199 If one wants to implement an emergency service based on Call Queueing, 1200 on "prioritized access to network layer resources", and ensure that 1201 "emergency" sessions can preempt regular sessions, one could do that 1202 by signaling emergency calls: 1203 * using "Resource-Priority" Header in SIP 1204 * using Admission-Priority Policy Element in RSVP 1205 * using Preemption Policy Element in RSVP with: 1206 o setup (Emergency) > defending (Non-Emergency) 1207 o setup (Non-Emergency) <= defending (Emergency) 1209 If one wants to implement an emergency service based on Call Queueing, 1210 on "prioritized access to network layer resources", and ensure that 1211 "emergency" sessions can partially preempt regular sessions (ie 1212 reduce their reservation size), one could do that by signaling 1213 emergency calls: 1214 * using "Resource-Priority" Header in SIP 1215 * using Admission-Priority Policy Element in RSVP 1216 * using Preemption in Policy Element RSVP with: 1217 o setup (Emergency) > defending (Non-Emergency) 1218 o setup (Non-Emergency) <= defending (Emergency) 1219 * activate RFC4495 RSVP Bandwidth Reduction mechanisms 1221 Authors' Address 1223 Francois Le Faucheur 1224 Cisco Systems, Inc. 1225 Village d'Entreprise Green Side - Batiment T3 1226 400, Avenue de Roumanille 1227 06410 Biot Sophia-Antipolis 1228 France 1229 Email: flefauch@cisco.com 1231 James Polk 1232 Cisco Systems, Inc. 1233 2200 East President George Bush Turnpike 1234 Richardson, Texas 75082 1235 USA 1236 Email: jmpolk@cisco.com 1238 Ken Carlberg 1239 G11 1240 123a Versailles Circle 1241 Towson, MD. 21204 1243 RSVP Extensions for Emergency Services October 2006 1245 USA 1246 email: carlberg@g11.org.uk 1248 IPR Statements 1250 The IETF takes no position regarding the validity or scope of any 1251 Intellectual Property Rights or other rights that might be claimed to 1252 pertain to the implementation or use of the technology described in 1253 this document or the extent to which any license under such rights 1254 might or might not be available; nor does it represent that it has 1255 made any independent effort to identify any such rights. Information 1256 on the procedures with respect to rights in RFC documents can be 1257 found in BCP 78 and BCP 79. 1259 Copies of IPR disclosures made to the IETF Secretariat and any 1260 assurances of licenses to be made available, or the result of an 1261 attempt made to obtain a general license or permission for the use of 1262 such proprietary rights by implementers or users of this 1263 specification can be obtained from the IETF on-line IPR repository at 1264 http://www.ietf.org/ipr. 1266 The IETF invites any interested party to bring to its attention any 1267 copyrights, patents or patent applications, or other proprietary 1268 rights that may cover technology that may be required to implement 1269 this standard. 1270 Please address the information to the IETF at ietf-ipr@ietf.org. 1272 Disclaimer of Validity 1274 This document and the information contained herein are provided on an 1275 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1276 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1277 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1278 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1279 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1280 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1282 Copyright Notice 1284 Copyright (C) The Internet Society (2006). This document is subject 1285 to the rights, licenses and restrictions contained in BCP 78, and 1286 except as set forth therein, the authors retain all their rights.