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