idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1407. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1376. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1383. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1389. ** 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 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 11 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([KEYWORDS]), 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 314 has weird spacing: '...riority and h...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 2007) is 6310 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) ** Downref: Normative reference to an Experimental RFC: RFC 4125 (ref. 'DSTE-MAM') ** Downref: Normative reference to an Experimental RFC: RFC 4127 (ref. 'DSTE-RDM') ** 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') ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 RSVP Extensions for Emergency Services January 2007 3 Internet Draft Francois Le Faucheur 4 James Polk 5 Cisco Systems, Inc. 7 Ken Carlberg 8 G11 9 draft-ietf-tsvwg-emergency-rsvp-01.txt 10 Expires: July 2007 January 2007 12 Resource ReSerVation Protovol (RSVP) Extensions for Emergency 13 Services 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 An Emergency Telecommunications Service (ETS) requires the ability to 40 provide an elevated probability of session establishment to an 41 authorized user in times of network congestion (typically, during a 42 crisis). When supported over the Internet Protocol suite, this may be 43 facilitated through a network layer admission control solution, which 44 supports prioritized access to resources (e.g., bandwidth). These 45 resources may be explicitly set aside for emergency services, or they 46 may be shared with other sessions. 48 RSVP Extensions for Emergency Services January 2007 50 This document specifies RSVP extensions that can be used to support 51 such an admission priority capability at the network layer. Note that 52 these extensions represent one possible solution component in 53 satisfying ETS requirements. Other solution components, or other 54 solutions, are outside the scope of this document. 56 Copyright Notice 57 Copyright (C) The Internet Society (2007). 59 Specification of Requirements 61 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 62 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 63 "OPTIONAL" in this document are to be interpreted as described in 64 [KEYWORDS] and indicate requirement levels for compliant 65 implementations. 67 Table of Contents 69 1. Introduction...................................................3 70 1.1. Related Technical Documents................................3 71 1.2. Terminology................................................4 72 1.3. Changes from previous versions.............................5 73 2. Overview of RSVP extensions and Operations.....................6 74 2.1. Operations of Admission Priority..........................8 75 3. New Policy Elements............................................8 76 3.1. Admission Priority Policy Element.........................9 77 3.1.1. Admission Priority Merging Rules 10 78 3.2. Application-Level Resource Priority Policy Element.......11 79 3.2.1. Application-Level Resource Priority Modifying and 80 Merging Rules 12 81 4. Security Considerations.......................................12 82 4.1. Use of RSVP Authentication...............................13 83 4.2. Use of INTEGRITY object within the POLICY_DATA object....14 84 5. IANA Considerations...........................................14 85 6. Acknowledgments...............................................15 86 7. Normative References..........................................15 87 8. Informative References........................................16 88 Appendix A: Examples of Bandwidth Allocation Model for Admission 89 Priority.........................................................16 90 A.1 Admission Priority with Maximum Allocation Model (MAM)......17 91 A.2 Admission Priority with Russian Dolls Model (RDM)...........20 92 A.3 Admission Priority with Priority Bypass Model (PBM).........23 93 Appendix B: Example Usages of RSVP Extensions....................26 94 Authors' Address.................................................27 96 RSVP Extensions for Emergency Services January 2007 98 1. Introduction 100 [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency 101 Telecommunications Service (ETS), which is an umbrella term 102 identifying those networks and specific services used to support 103 emergency communications. An underlying goal of these documents is to 104 present requirements that elevate the probability of session 105 establishment from an authorized user in times of network congestion 106 (presumably because of a crisis condition). In some extreme cases, 107 the requirement for this probability may reach 100%, but that is a 108 topic subject to policy and most likely local regulation (the latter 109 being outside the scope of this document). 111 Solutions to meet this requirement for elevated session establishment 112 probability may involve session layer capabilities prioritizing 113 access to resources controlled by the session control function. As an 114 example, entities involved in session control (such as SIP user 115 agents, when the Session Initiation Protocol, SIP [SIP], is the 116 session control protocol in use) can influence their treatment of 117 session establishment requests (such as SIP requests). This may 118 include the ability to "queue" call requests when those can not be 119 immediately honored (in some cases with the notion of "bumping", or 120 "displacement", of less important call request from that queue). It 121 may include additional mechanisms such as exemption from certain 122 network management controls, and alternate routing. 124 Solutions to meet the requirement for elevated session establishment 125 probability may also take advantage of network layer admission 126 control mechanisms supporting admission priority. Networks usually 127 have engineered capacity limits that characterize the maximum load 128 that can be handled (say, on any given link) for a class of traffic 129 while satisfying the quality of service requirements of that traffic 130 class. Admission priority may involve setting aside some network 131 resources (e.g. bandwidth) out of the engineered capacity limits for 132 the emergency services only. Or alternatively, it may involve 133 allowing the emergency related sessions to seize additional resources 134 beyond the engineered capacity limits applied to normal calls. 136 Note: Below, this document references several examples of IP 137 telephony and its use of "calls", which is one form of the term 138 "sessions" (Video over IP and Instant Messaging being other examples 139 that rely on session establishment). For the sake of simplicity, we 140 shall use the widely known term "call" for the remainder of this 141 document. 143 1.1. Related Technical Documents 145 RSVP Extensions for Emergency Services January 2007 147 [EMERG-IMP] is patterned after [ITU.I.225] and describes an example 148 of one type of prioritized network layer admission control procedure 149 that may be used for emergency services operating over an IP network 150 infrastructure. It discusses initial call set up, as well as 151 operations after call establishment through maintenance of a 152 continuing call model of the status of all calls. [EMERG-IMP] also 153 describes how these network layer admission control procedures can be 154 realized using the Resource reSerVation Protocol [RSVP] along with 155 its associated protocol suite and extensions, including those for 156 policy based admission control ([FW-POLICY], [RSVP-POLICY]), for user 157 authentication and authorization ([RSVP-ID]) and for integrity and 158 authentication of RSVP messages ([RSVP-CRYPTO-1], [RSVP-CRYPTO-2]). 160 Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption 161 Priority Policy Element specified in [RSVP-PREEMP] can be used to 162 enforce the call preemption that may be needed by some emergency 163 services. 165 In contrast to [EMERG-IMP], this document specifies new RSVP 166 extensions to increase the probability of call completion without 167 preemption. Engineered capacity techniques in the form of bandwidth 168 allocation models are used to satisfy the "admission priority" 169 required by an RSVP capable ETS network. In particular this document 170 specifies two new RSVP Policy Elements allowing the admission 171 priority to be conveyed inside RSVP signaling messages so that RSVP 172 nodes can enforce selective bandwidth admission control decision 173 based on the call admission priority. Appendix A of this document 174 also provides three examples of a bandwidth allocation model, which 175 can be used by RSVP-routers to enforce such admission priority on 176 every link. 178 1.2. Terminology 180 This document assumes the terminology defined in [FW-POLICY]. For 181 convenience, the definition of a few key terms is repeated here: 183 - Policy Decision Point (PDP): The point where policy decisions are 184 made. 186 - Local Policy Decision Point (LPDP): PDP local to the network 187 element 189 - Policy Enforcement Point (PEP): The point where the policy 190 decisions are actually enforced. 192 - Policy Ignorant Node (PIN): A network element that does not 193 explicitly support policy control using the mechanisms defined in 194 [FW-POLICY]. 196 RSVP Extensions for Emergency Services January 2007 198 1.3. Changes from previous versions 199 [Note to RFC Editor: This section is to be removed before 200 publication] 202 Changes from ietf-tsvwg-emergency-rsvp-00 to ietf-tsvwg- 203 emergency-rsvp-01 205 The most significant changes are: 207 o editorial change (correction in description of 208 "Take highest priority" in section 3.1.1). 210 o expanded Security Considerations section 212 Changes from lefaucheur-rsvp-emergency-01 to ietf-tsvwg-rsvp- 213 emergency-00 215 The most significant change is: 217 o Extended the Admission Priority field from 3 to 8 bits and 218 inverted the encoding order, in particular for better 219 alignment with NSIS Qspec. 221 Changes from lefaucheur-rsvp-emergency-01 to lefaucheur-rsvp- 222 emergency-02 224 The most significant changes are: 226 o modified the Introduction to add additional clarity and to 227 place related work in a better context to the extensions 228 proposed in this draft 230 o Moved bandwidth allocation models to an appendix 232 o Allowed multiple Application-Level Resource Priority inside 233 ALRP Policy Element 235 o Added a 2nd appendix providing examples of RSVP extensions 236 usage 238 Changes from lefaucheur-rsvp-emergency-00 to lefaucheur-rsvp- 239 emergency-01 241 The most significant changes were: 243 RSVP Extensions for Emergency Services January 2007 245 o adding a second RSVP Policy Element that contains the 246 application-level resource priority requirements (for example 247 as communicated in the SIP Resource-Priority Header) for 248 scenarios where priority calls transits through multiple 249 administrative domains. 251 o adding description of a third bandwidth allocation model 252 example: the Priority Bypass Model 254 o adding discussion on policies for mapping the various 255 bandwidth allocation model over the engineered capacity limits. 257 2. Overview of RSVP extensions and Operations 259 Let us consider the case where a call requiring ETS type service is 260 to be established, and more specifically that the preference to be 261 granted to this call is in terms of network layer "admission 262 priority" (as opposed to preference granted through preemption of 263 existing calls). By "admission priority" we mean allowing that 264 priority call to seize network layer resources from the engineered 265 capacity that have been set-aside and not made available to normal 266 calls, or alternatively by allowing that call to seize additional 267 resources beyond the engineered capacity limits applied to normal 268 calls. 270 As described in [EMERG-IMP], the session establishment can be 271 conditioned to resource-based and policy-based network layer 272 admission control achieved via RSVP signaling. In the case where the 273 session control protocol is SIP, the use of RSVP-based admission 274 control by SIP is specified in [SIP-RESOURCE]. 276 Devices involved in the session establishment are expected to be 277 aware of the application-level priority requirements of emergency 278 calls. Again considering the case where the session control protocol 279 is SIP, the SIP user agents can be made aware of the resource 280 priority requirements in the case of an emergency call using the 281 Resource-Priority Header mechanism specified in [SIP-PRIORITY]. The 282 end-devices involved in the upper-layer session establishment simply 283 need to copy the application-level resource priority requirements 284 (e.g. as communicated in SIP Resource-Priority Header) inside the new 285 RSVP Application-Level Resource-Priority Policy Element defined in 286 this document. 288 Conveying the application-level resource priority requirements inside 289 the RSVP message allows this application level requirement to be 290 mapped/remapped into a different RSVP "admission priority" at every 291 administrative domain boundary based on the policy applicable in that 293 RSVP Extensions for Emergency Services January 2007 295 domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs 296 at the periphery of the policy domain (e.g., in border routers), PDPs 297 would interpret the RSVP Application-Level Resource-Priority Policy 298 Element and map the requirement of the emergency session into an RSVP 299 "admission priority" level. Then, PDPs would convey this information 300 inside the new Admission Priority Policy Element defined in this 301 document. This way, the RSVP admission priority can be communicated 302 to downstream PEPs (ie RSVP Routers) of the same policy domain, which 303 have LPDPs but no controlling PDP. In turn, this means the necessary 304 RSVP Admission priority can be enforced at every RSVP hop, including 305 all the (many) hops which do not have any understanding of 306 Application-Level Resource-Priority semantics. 308 As an example of operation across multiple administrative domains, a 309 first domain might decide to provide network layer admission priority 310 to calls of a given Application Level Resource Priority and map it 311 into a high RSVP admission control priority inside the Admission 312 Priority Policy Element; while a second domain may decide to not 313 provide admission priority to calls of this same Application Level 314 Resource Priority and hence map it into a low RSVP admission control 315 priority. 317 As another example of operation across multiple administrative 318 domains, we can consider the case where the resource priority header 319 enumerates several namespaces, as explicitly allowed by [SIP- 320 PRIORITY], for support of scenarios where calls traverse multiple 321 administrative domains using different namespace. In that case, the 322 relevant namespace can be used at each domain boundary to map into an 323 RSVP Admission priority for that domain. It is not expected that the 324 RSVP Application-Level Resource-Priority Header Policy Element would 325 be taken into account at RSVP-hops within a given administrative 326 domain. It is expected to be used at administrative domain boundaries 327 only in order to set/reset the RSVP Admission Priority Policy Element. 329 The existence of pre-established inter-domain policy agreements or 330 Service Level Agreements may avoid the need to take real-time action 331 at administrative domain boundaries for mapping/remapping of 332 admission priorities. 334 Mapping/remapping by PDPs may also be applied to boundaries between 335 various signaling protocols, such as those advanced by the NSIS 336 working group. 338 As can be observed, the framework described above for 339 mapping/remapping application level resource priority requirements 340 into an RSVP admission priority can also be used together with [RSVP- 341 PREEMP] for mapping/remapping application level resource priority 342 requirements into an RSVP preemption priority (when preemption is 343 indeed needed). In that case, when processing the RSVP Application- 345 RSVP Extensions for Emergency Services January 2007 347 Level Resource-Priority Policy Element, the PDPs at boundaries 348 between administrative domains (or between various QoS signaling 349 protocols) can map it into an RSVP "preemption priority" information. 350 This Preemption priority information comprises a setup preemption 351 level and a defending preemption priority level. This preemption 352 priority information can then be encoded inside the Preemption 353 Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into 354 account at every RSVP-enabled network hop as discussed [EMERG-IMP]. 355 Appendix B provides examples of various hypothetical policies for 356 emergency call handling, some of them involving admission priority, 357 some of them involving both admission priority and preemption 358 priority. Appendix B also identifies how the Application-Level 359 Resource Priority need to be mapped into RSVP policy elements by the 360 PDPs to realize these policies. 362 2.1. Operations of Admission Priority 364 The RSVP Admission Priority policy element defined in this document 365 allows admission bandwidth to be allocated preferentially to an 366 authorized priority service. Multiple models of bandwidth allocation 367 MAY be used to that end. 369 A number of bandwidth allocation models have been defined in the IETF 370 for allocation of bandwidth across different classes of traffic 371 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 372 Those include the Maximum Allocation Model (MAM) defined in [DSTE- 373 MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These 374 same models MAY however be applied for allocation of bandwidth across 375 different levels of admission priority as defined in this document. 376 Appendix A provides an illustration of how these bandwidth allocation 377 models can be applied for such purposes and introduces an additional 378 bandwidth allocation model that we term the Priority Bypass Model 379 (PBM). It is important to note that the models described and 380 illustrated in Appendix A are only informative and do not represent a 381 recommended course of action. 383 3. New Policy Elements 385 The Framework document for policy-based admission control [FW-POLICY] 386 describes the various components that participate in policy decision 387 making (i.e., PDP, PEP and LPDP). 389 As described in section 2 of the present document, the Application- 390 Level Resource Priority Policy Element and the Admission Priority 391 Policy Element serve different roles in this framework: 393 - the Application-Level Resource Priority Policy Element conveys 394 application level information and is processed by PDPs 396 RSVP Extensions for Emergency Services January 2007 398 - the emphasis of Admission Priority Policy Element is to be 399 simple, stateless, and light-weight such that it can be 400 processed internally within a node's LPDP. It can then be 401 enforced internally within a node's PEP. It is set by PDPs 402 based on processing of the Application-Level Resource Priority 403 Policy Element. 405 [RSVP-POLICY] defines extensions for supporting generic policy based 406 admission control in RSVP. These extensions include the standard 407 format of POLICY_DATA objects and a description of RSVP handling of 408 policy events. 410 The POLICY_DATA object contains one or more of Policy Elements, each 411 representing a different (and perhaps orthogonal) policy. As an 412 example, [RSVP-PREEMP] specifies the Preemption Priority Policy 413 Element. 415 This document defines two new Policy Elements called: 416 - the Admission Priority Policy Element 417 - the Application-Level Resource Priority Policy Element 419 3.1. Admission Priority Policy Element 421 The format of the Admission Priority policy element is as follows: 423 +-------------+-------------+-------------+-------------+ 424 | Length | P-Type = ADMISSION_PRI | 425 +-------------+-------------+-------------+-------------+ 426 | Flags | M. Strategy | Error Code | Reserved | 427 +-------------+-------------+-------------+-------------+ 428 |Adm. Priority| Reserved | 429 +---------------------------+---------------------------+ 431 Length: 16 bits 432 Always 12. The overall length of the policy element, in bytes. 434 P-Type: 16 bits 435 ADMISSION_PRI = To be allocated by IANA 436 (see "IANA Considerations" section) 438 Flags: Reserved (MUST be set to zero on transmit and ignored on 439 receive) 441 Merge Strategy: 8 bit (only applicable to multicast flows) 442 1 Take priority of highest QoS 443 2 Take highest priority 445 RSVP Extensions for Emergency Services January 2007 447 3 Force Error on heterogeneous merge 449 Error code: 8 bits (only applicable to multicast flows) 450 0 NO_ERROR Value used for regular ADMISSION_PRI elements 451 2 HETEROGENEOUS This element encountered heterogeneous merge 453 Reserved: 8 bits 454 Always 0. 456 Adm. Priority (Admission Priority): 8 bits (unsigned) 457 The admission control priority of the flow, in terms of access 458 to network bandwidth in order to provide higher probability of 459 call completion to selected flows. Higher values represent 460 higher Priority. 462 Bandwidth allocation models such as those described in Appendix 463 A are to be used by the RSVP router to achieve such increased 464 probability of call completion. The admission priority value 465 effectively indicates which bandwidth constraint(s) of the 466 bandwidth constraint model in use is(are) applicable to 467 admission of this RSVP reservation. 469 Reserved: 16 bits 470 Always 0. 472 Note that the Admission Priority Policy Element does NOT indicate 473 that this RSVP reservation is to preempt any other RSVP reservation. 474 If a priority session justifies both admission priority and 475 preemption priority, the corresponding RSVP reservation needs to 476 carry both an Admission Priority Policy Element and a Preemption 477 Priority Policy Element. The Admission Priority and Preemption 478 Priority are handled by LPDPs and PEPs as orthogonal and independent 479 mechanisms. 481 3.1.1. 482 Admission Priority Merging Rules 484 This section discusses alternatives for dealing with RSVP admission 485 priority in case of merging of reservations. As merging is only 486 applicable to multicast, this section also only applies to multicast 487 sessions. 489 The rules for merging Admission Priority Policy Elements are the same 490 as those defined in [RSVP-PREEMP] for merging Preemption Priority 491 Policy Elements. In particular, the following merging strategies are 492 supported: 493 - Take priority of highest QoS 494 - Take highest priority 495 - Force Error on heterogeneous merge. 497 RSVP Extensions for Emergency Services January 2007 499 The only difference with [RSVP-PREEMP] is that this document does not 500 recommend any merge strategies for Admission Priority while [RSVP- 501 PREEMP] recommends the first of these merge strategies for Preemption 502 Priority. 504 Note that with the Admission Priority (as is the case with the 505 Preemption Priority), "Take highest priority" translates into "take 506 the highest numerical value". 508 3.2. Application-Level Resource Priority Policy Element 510 The format of the Application-Level Resource Priority policy element 511 is as follows: 513 +-------------+-------------+-------------+-------------+ 514 | Length | P-Type = APP_RESOURCE_PRI | 515 +-------------+-------------+-------------+-------------+ 516 // ALRP List // 517 +---------------------------+---------------------------+ 519 Length: The length of the policy element (including the Length and P- 520 Type) is in number of octets (MUST be a multiple of 4) and 521 indicates the end of the ALRP list. 523 P-Type: 16 bits 524 APP_RESOURCE_PRI = To be allocated by IANA 525 (see "IANA Considerations" section) 527 ARLP: 529 +---------------------------+---------------------------+ 530 | ALRP Namespace |ALRP Priority| Reserved | 531 +---------------------------+---------------------------+ 533 ALRP Namespace (Application-Level Resource Priority Namespace): 534 16 bits (unsigned) 535 Contains the namespace of the application-level resource 536 priority. This is encoded as a numerical value which 537 represents the position of the namespace in the "Resource- 538 Priority Namespace" IANA registry, starting with 0. Creation 539 of this registry has been requested to IANA in [SIP- 540 PRIORITY]. 541 For example, as "drsn", "dsn", "q735", "ets" and "wps" are 542 currently the first, second, third, fourth and fifth 543 namespaces defined in the "Resource-Priority Namespace" 544 registry, those are respectively encoded as value 0, 1, 2, 3 545 and 4. 547 RSVP Extensions for Emergency Services January 2007 549 ALRP Priority: (Application-Level Resource Priority Priority): 550 8 bits (unsigned) 551 Contains the priority value within the namespace of the 552 application-level resource priority. This is encoded as a 553 numerical value which represents the priority defined in the 554 "Resource-Priority Namespace" IANA registry for the 555 considered namespace, starting from 0 for the highest 556 priority and increasing as priority decreases. 557 For example, as "flash-override", "flash", "immediate", 558 "priority" and "routine" are the priorities in decreasing 559 order of priority registered for the "dsn" namespace, those 560 are respectively encoded as value 0, 1, 2, 3 and 4. As 561 another example, as "flash-override-override", "flash- 562 override", "flash", "immediate", "priority" and "routine" 563 are the priorities in decreasing order of priority 564 registered for the "drsn" namespace, those are respectively 565 encoded as value 0, 1, 2, 3, 4 and 5. 567 Reserved: 16 bits 568 Always 0. 570 3.2.1. 571 Application-Level Resource Priority Modifying and Merging Rules 573 When POLICY_DATA objects are protected by integrity, LPDPs should not 574 attempt to modify them. They MUST be forwarded as-is to ensure their 575 security envelope is not invalidated. 577 In case of multicast, when POLICY_DATA objects are not protected by 578 integrity, LPDPs MAY merge incoming Application-Level Resource 579 Priority elements to reduce their size and number. When they do merge 580 those, LPDPs MUST do so according to the following rule: 582 The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 583 all the ALRPs appearing in the ALRP List of an incoming 584 APP_RESOURCE_PR element. A given ALRP MUST NOT appear more than 585 once. In other words, the outgoing ALRP List is the reunion of 586 the incoming ARLP Lists that are merged. 588 As merging is only applicable to Multicast, this rule only applies to 589 Multicast sessions. 591 4. Security Considerations 593 The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can 594 be signaled by RSVP through encapsulation in a Policy Data object as 595 defined in [RSVP-POLICY]. Therefore, like any other Policy Elements, 596 their integrity can be protected as discussed in section 6 of [RSVP- 598 RSVP Extensions for Emergency Services January 2007 600 POLICY] by two optional security mechanisms. The first mechanism 601 relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and 602 [RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are 603 policy capable. The second mechanism relies on the INTEGRITY object 604 within the POLICY_DATA object to guarantee integrity between RSVP 605 Policy Enforcement Points (PEPs) that are not RSVP neighbors. 607 4.1. Use of RSVP Authentication 609 [RSVP-CRYPTO-1] discusses several approaches for distribution of keys 610 to be used for RSVP Authentication. First, the RSVP Authentication 611 shared keys can be distributed manually. This is the base option and 612 its support is mandated for any implementation. However, in some 613 environments, this approach may become a burden if keys frequently 614 change over time. Alternatively, a standard key management protocol 615 for secure key distribution can be used. However, existing key 616 distribution protocols may not be appropriate in all environments 617 because of the complexity or operational burden they involve. Finally, 618 [RSVP-CRYPTO-1] specifies how Kerberos [KERBEROS] may be used to 619 generate the RSVP Authentication keys. Kerberos allows for the use of 620 trusted third party keying relationships between security principals 621 (RSVP sender and receivers) where the Kerberos key distribution 622 center (KDC) establishes an ephemeral session key to be shared 623 between RSVP sender and receivers. 625 The use of RSVP Authentication in parts of the network where there 626 may be one or more IP hops in between two RSVP neighbors raises an 627 additional challenge. This is because, with some RSVP messages such 628 as a Path message, an RSVP router does not know the RSVP next hop for 629 that message at the time of forwarding it. In fact, part of the role 630 of a Path message is precisely to discover the RSVP next hop (and to 631 dynamically re-discover it when it changes, say because of a routing 632 change). Hence, the RSVP router may not know which security 633 association to use when forwarding such a message. 634 In that situation, one approach is to share the same RSVP 635 Authentication shared key across all the RSVP routers of a part of 636 the network where there may be RSVP neighbors with IP hops in between. 637 For example, all the RSVP routers of an administrative domain could 638 share the same RSVP Authentication key, while different per-neighbor 639 keys could be used between any RSVP router pair straddling the 640 boundary between two administrative domains that have agreed to use 641 RSVP signaling. 643 When the same RSVP Authentication shared key is to be shared among 644 multiple RSVP neighbors, manual key distribution may be used. For 645 situations where RSVP is being used for multicast flows, it might 646 also be possible, in the future, to adapt a multicast key management 647 method (e.g. from IETF Multicast Security Working Group) for key 648 distribution with such multicast RSVP usage. For situations where 650 RSVP Extensions for Emergency Services January 2007 652 RSVP is being used for unicast flows within a single administrative 653 domain, the Kerberos technique described in Section 7 of [RSVP- 654 CRYPTO-1] might be considered. For situations where RSVP is being 655 used for unicast flows across domain boundaries, it is not currently 656 clear how one might provide automated key management. Specification 657 of a specific automated key management technique is outside the scope 658 of this document. Operators should consider these key management 659 issues when contemplating deployment of this specification. 661 4.2. Use of INTEGRITY object within the POLICY_DATA object 663 The INTEGRITY object within the POLICY_DATA object can be used to 664 guarantee integrity between non-neighboring RSVP PEPs. 666 Details for computation of the content of the INTEGRITY object can be 667 found in Appendix B of [RSVP-POLICY]. This states that the Policy 668 Decision Point (PDP), at its discretion, and based on destination 669 PEP/PDP or other criteria, selects an Authentication Key and the hash 670 algorithm to be used. Keys to be used between PDPs can be distributed 671 manually or via standard key management protocol for secure key 672 distribution. 674 Note that where non-RSVP hops may exist in between RSVP hops, as well 675 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 676 between PEPs, it may be difficult for the PDP to determine what is 677 the destination PDP for a POLICY_DATA object contained in some RSVP 678 messages (such as a Path message). This is because in those cases the 679 next PEP is not known at the time of forwarding the message. This 680 issue is similar to the one discussed in section 4.1, except it now 681 applies to PDP neighbors instead of RSVP neighbors. Hence similar 682 approaches could be used, such as the use of a key shared across 683 multiple PDPs. We observe that this issue may not exist in some 684 deployment scenarios where a single (or low number of) PDP is used to 685 control all the PEPs of a region (such as an administrative domain). 686 In such scenarios, it may be easy for a PDP to determine what is the 687 next hop PDP, even when the next hop PEP is not known, simply by 688 determining what is the next region that will be traversed (say based 689 on the destination address). 691 5. IANA Considerations 693 As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type 694 values) are to be assigned by IANA as per "IETF Consensus" following 695 the policies outlined in [IANA-CONSIDERATIONS]. 697 IANA needs to allocate two P-Types from the Standard RSVP Policy 698 Element range: 699 - one P-Type to the Admission Priority Policy Element 701 RSVP Extensions for Emergency Services January 2007 703 - one P-Type to the Application-Level Resource Priority 704 Policy Element 706 6. Acknowledgments 708 We would like to thank An Nguyen for his encouragement to address 709 this topic and ongoing comments. Also, this document borrows heavily 710 from some of the work of S. Herzog on Preemption Priority Policy 711 Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input 712 into this document. 714 7. Normative References 716 [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth 717 Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 718 4125, June 2005. 720 [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints 721 Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June 722 2005 724 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for 725 Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. 727 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 728 for Emergency Telecommunication Service (ETS)", RFC 3690, February 729 2004. 731 [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 732 for Policy-based Admission Control", RFC 2753, January 2000. 734 [IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an 735 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 737 [KEYWORDS] "Key words for use in RFCs to Indicate Requirement Levels", 738 Bradner, RFC2119, BCP14 740 [KERBEROS] Neuman et al., "The Kerberos Network Authentication 741 Service (V5)", RFC 4120, July 2005. 743 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 744 (RSVP)- Functional Specification", RFC 2205, September 1997. 746 [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 747 Cryptographic Authentication", RFC 2747, January 2000. 749 RSVP Extensions for Emergency Services January 2007 751 [RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic 752 Authentication -- Updated Message Type Value", RFC 3097, April 2001. 754 [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC 755 2750, January 2000. 757 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 758 Element", RFC 3181, October 2001. 760 [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261, 761 June 2002 763 [SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource 764 Priority for the Session Initiation Protocol (SIP)", RFC4412, 765 February 2006. 767 8. Informative References 769 [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency 770 Telecommunications Service for Real Time Services in the Internet 771 Protocol Suite", RFC 4542, May 2006. 773 [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, 774 Recommendation, I.255.3, July, 1990. 776 [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 777 Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, 778 October 2001. 780 [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, 781 "Integration of Resource Management and Session Initiation Protocol 782 (SIP)", RFC 3312, October 2002. 784 Appendix A: Examples of Bandwidth Allocation Model for Admission 785 Priority 787 Sections A.1 and A.2 respectively illustrate how the Maximum 788 Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- 789 RDM] can be used for support of admission priority. Section A.3 790 illustrates how a simple "Priority Bypass Model" can also be used for 791 support of admission priority. 793 For simplicity, operations with only a single "priority" level 794 (beyond non-priority) are illustrated here; However, the reader will 795 appreciate that operations with multiple priority levels can easily 796 be supported with these models. 798 RSVP Extensions for Emergency Services January 2007 800 In all the charts below: 801 x represents a non-priority session 802 o represents a priority session 804 A.1 Admission Priority with Maximum Allocation Model (MAM) 806 This section illustrates operations of admission priority when a 807 Maximum Allocation Model (MAM) is used for bandwidth allocation 808 across non-priority traffic and priority traffic. A property of the 809 Maximum Allocation Model is that priority traffic can not use more 810 than the bandwidth made available to priority traffic (even if the 811 non-priority traffic is not using all of the bandwidth available for 812 it). 814 ----------------------- 815 ^ ^ ^ | | ^ 816 . . . | | . 817 Total . . . | | . Bandwidth 818 (1)(2)(3) | | . Available 819 Engi- . . . | | . for non-priority use 820 neered .or.or. | | . 821 . . . | | . 822 Capacity. . . | | . 823 v . . | | v 824 . . |--------------| --- 825 v . | | ^ 826 . | | . Bandwidth available for 827 v | | v priority use 828 ------------------------- 830 Chart 1. MAM Bandwidth Allocation 832 Chart 1 shows a link within a routed network conforming to this 833 document. On this link are two amounts of bandwidth available to two 834 types of traffic: non-priority and priority. 835 If the non-priority traffic load reaches the maximum bandwidth 836 available for non-priority, no additional non-priority sessions can 837 be accepted even if the bandwidth reserved for priority traffic is 838 not currently fully utilized. 840 With the Maximum Allocation Model, in the case where the priority 841 load reaches the maximum bandwidth reserved for priority calls, no 842 additional priority sessions can be accepted. 844 As illustrated in Chart 1, an operator may map the MAM model onto the 845 Engineered Capacity limits according to different policies. At one 846 extreme, where the proportion of priority traffic is reliably known 848 RSVP Extensions for Emergency Services January 2007 850 to be fairly small at all times and where there may be some safety 851 margin factored in the engineered capacity limits, the operator may 852 decide to configure the bandwidth available for non-priority use to 853 the full engineered capacity limits; effectively allowing the 854 priority traffic to ride within the safety margin of this engineered 855 capacity. This policy can be seen as an economically attractive 856 approach as all of the engineered capacity is made available to non- 857 priority calls. This policy illustrated as (1) in Chart 1. As an 858 example, if the engineered capacity limit on a given link is X, the 859 operator may configure the bandwidth available to non-priority 860 traffic to X, and the bandwidth available to priority traffic to 5% 861 of X. 863 At the other extreme, where the proportion of priority traffic may be 864 significant at times and the engineered capacity limits are very 865 tight, the operator may decide to configure the bandwidth available 866 to non-priority traffic and the bandwidth available to priority 867 traffic such that their sum is equal to the engineered capacity 868 limits. This guarantees that the total load across non-priority and 869 priority traffic is always below the engineered capacity and, in turn, 870 guarantees there will never be any QoS degradation. However, this 871 policy is less attractive economically as it prevents non-priority 872 calls from using the full engineered capacity, even when there is no 873 or little priority load, which is the majority of time. This policy 874 illustrated as (3) in Chart 1. As an example, if the engineered 875 capacity limit on a given link is X, the operator may configure the 876 bandwidth available to non-priority traffic to 95% of X, and the 877 bandwidth available to priority traffic to 5% of X. 879 Of course, an operator may also strike a balance anywhere in between 880 these two approaches. This policy illustrated as (2) in Chart 1. 882 Chart 2 shows some of the non-priority capacity of this link being 883 used. 885 ----------------------- 886 ^ ^ ^ | | ^ 887 . . . | | . 888 Total . . . | | . Bandwidth 889 . . . | | . Available 890 Engi- . . . | | . for non-priority use 891 neered .or.or. |xxxxxxxxxxxxxx| . 892 . . . |xxxxxxxxxxxxxx| . 893 Capacity. . . |xxxxxxxxxxxxxx| . 894 v . . |xxxxxxxxxxxxxx| v 895 . . |--------------| --- 896 v . | | ^ 897 . | | . Bandwidth available for 898 v | | v priority use 900 RSVP Extensions for Emergency Services January 2007 902 ------------------------- 903 Chart 2. Partial load of non-priority calls 905 Chart 3 shows the same amount of non-priority load being used at this 906 link, and a small amount of priority bandwidth being used. 908 ----------------------- 909 ^ ^ ^ | | ^ 910 . . . | | . 911 Total . . . | | . Bandwidth 912 . . . | | . Available 913 Engi- . . . | | . for non-priority use 914 neered .or.or. |xxxxxxxxxxxxxx| . 915 . . . |xxxxxxxxxxxxxx| . 916 Capacity. . . |xxxxxxxxxxxxxx| . 917 v . . |xxxxxxxxxxxxxx| v 918 . . |--------------| --- 919 v . | | ^ 920 . | | . Bandwidth available for 921 v |oooooooooooooo| v priority use 922 ------------------------- 924 Chart 3. Partial load of non-priority calls 925 & partial load of priority calls 927 Chart 4 shows the case where non-priority load equates or exceeds the 928 maximum bandwidth available to non-priority traffic. Note that 929 additional non-priority sessions would be rejected even if the 930 bandwidth reserved for priority sessions is not fully utilized. 932 ----------------------- 933 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 934 . . . |xxxxxxxxxxxxxx| . 935 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 936 . . . |xxxxxxxxxxxxxx| . Available 937 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 938 neered .or.or. |xxxxxxxxxxxxxx| . 939 . . . |xxxxxxxxxxxxxx| . 940 Capacity. . . |xxxxxxxxxxxxxx| . 941 v . . |xxxxxxxxxxxxxx| v 942 . . |--------------| --- 943 v . | | ^ 944 . | | . Bandwidth available for 945 v |oooooooooooooo| v priority use 946 ------------------------- 947 Chart 4. Full non-priority load 948 & partial load of priority calls 950 RSVP Extensions for Emergency Services January 2007 952 Chart 5 shows the case where the priority traffic equates or exceeds 953 the bandwidth reserved for such priority traffic. 955 In that case additional priority sessions could not be accepted. Note 956 that this does not mean that such calls are dropped altogether: they 957 may be handled by mechanisms, which are beyond the scope of this 958 particular document (such as establishment through preemption of 959 existing non-priority sessions, or such as queuing of new priority 960 session requests until capacity becomes available again for priority 961 traffic). 963 ----------------------- 964 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 965 . . . |xxxxxxxxxxxxxx| . 966 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 967 . . . |xxxxxxxxxxxxxx| . Available 968 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 969 neered .or.or. |xxxxxxxxxxxxxx| . 970 . . . |xxxxxxxxxxxxxx| . 971 Capacity. . . | | . 972 v . . | | v 973 . . |--------------| --- 974 v . |oooooooooooooo| ^ 975 . |oooooooooooooo| . Bandwidth available for 976 v |oooooooooooooo| v priority use 977 ------------------------- 979 Chart 5. Partial non-priority load & Full priority load 981 A.2 Admission Priority with Russian Dolls Model (RDM) 983 This section illustrates operations of admission priority when a 984 Russian Dolls Model (RDM) is used for bandwidth allocation across 985 non-priority traffic and priority traffic. A property of the Russian 986 Dolls Model is that priority traffic can use the bandwidth which is 987 not currently used by non-priority traffic. 989 As with the MAM model, an operator may map the RDM model onto the 990 Engineered Capacity limits according to different policies. The 991 operator may decide to configure the bandwidth available for non- 992 priority use to the full engineered capacity limits; As an example, 993 if the engineered capacity limit on a given link is X, the operator 994 may configure the bandwidth available to non-priority traffic to X, 995 and the bandwidth available to non-priority and priority traffic to 996 105% of X. 998 RSVP Extensions for Emergency Services January 2007 1000 Alternatively, the operator may decide to configure the bandwidth 1001 available to non-priority and priority traffic to the engineered 1002 capacity limits; As an example, if the engineered capacity limit on a 1003 given link is X, the operator may configure the bandwidth available 1004 to non-priority traffic to 95% of X, and the bandwidth available to 1005 non-priority and priority traffic to X. 1007 Finally, the operator may decide to strike a balance in between. The 1008 considerations presented for these policies in the previous section 1009 in the MAM context are equally applicable to RDM. 1011 Chart 6 shows the case where only some of the bandwidth available to 1012 non-priority traffic is being used and a small amount of priority 1013 traffic is in place. In that situation both new non-priority sessions 1014 and new priority sessions would be accepted. 1016 -------------------------------------- 1017 |xxxxxxxxxxxxxx| . ^ 1018 |xxxxxxxxxxxxxx| . Bandwidth . 1019 |xxxxxxxxxxxxxx| . Available for . 1020 |xxxxxxxxxxxxxx| . non-priority . 1021 |xxxxxxxxxxxxxx| . use . 1022 |xxxxxxxxxxxxxx| . . Bandwidth 1023 | | . . available for 1024 | | v . non-priority 1025 |--------------| --- . and priority 1026 | | . use 1027 | | . 1028 |oooooooooooooo| v 1029 --------------------------------------- 1031 Chart 6. Partial non-priority load & Partial Aggregate load 1033 Chart 7 shows the case where all of the bandwidth available to non- 1034 priority traffic is being used and a small amount of priority traffic 1035 is in place. In that situation new priority sessions would be 1036 accepted but new non-priority sessions would be rejected. 1038 -------------------------------------- 1039 |xxxxxxxxxxxxxx| . ^ 1040 |xxxxxxxxxxxxxx| . Bandwidth . 1041 |xxxxxxxxxxxxxx| . Available for . 1042 |xxxxxxxxxxxxxx| . non-priority . 1043 |xxxxxxxxxxxxxx| . use . 1044 |xxxxxxxxxxxxxx| . . Bandwidth 1045 |xxxxxxxxxxxxxx| . . available for 1046 |xxxxxxxxxxxxxx| v . non-priority 1048 RSVP Extensions for Emergency Services January 2007 1050 |--------------| --- . and priority 1051 | | . use 1052 | | . 1053 |oooooooooooooo| v 1054 --------------------------------------- 1056 Chart 7. Full non-priority load & Partial Aggregate load 1058 Chart 8 shows the case where only some of the bandwidth available to 1059 non-priority traffic is being used and a heavy load of priority 1060 traffic is in place. In that situation both new non-priority sessions 1061 and new priority sessions would be accepted. 1062 Note that, as illustrated in Chart 7, priority calls use some of the 1063 bandwidth currently not used by non-priority traffic. 1065 -------------------------------------- 1066 |xxxxxxxxxxxxxx| . ^ 1067 |xxxxxxxxxxxxxx| . Bandwidth . 1068 |xxxxxxxxxxxxxx| . Available for . 1069 |xxxxxxxxxxxxxx| . non-priority . 1070 |xxxxxxxxxxxxxx| . use . 1071 | | . . Bandwidth 1072 | | . . available for 1073 |oooooooooooooo| v . non-priority 1074 |--------------| --- . and priority 1075 |oooooooooooooo| . use 1076 |oooooooooooooo| . 1077 |oooooooooooooo| v 1078 --------------------------------------- 1080 Chart 8. Partial non-priority load & Heavy Aggregate load 1082 Chart 9 shows the case where all of the bandwidth available to non- 1083 priority traffic is being used and all of the remaining available 1084 bandwidth is used by priority traffic. In that situation new non- 1085 priority sessions would be rejected. In that situation new priority 1086 sessions could not be accepted right away. Those priority sessions 1087 may be handled by mechanisms, which are beyond the scope of this 1088 particular document (such as established through preemption of 1089 existing non-priority sessions, or such as queuing of new priority 1090 session requests until capacity becomes available again for priority 1091 traffic). 1093 -------------------------------------- 1094 |xxxxxxxxxxxxxx| . ^ 1095 |xxxxxxxxxxxxxx| . Bandwidth . 1096 |xxxxxxxxxxxxxx| . Available for . 1098 RSVP Extensions for Emergency Services January 2007 1100 |xxxxxxxxxxxxxx| . non-priority . 1101 |xxxxxxxxxxxxxx| . use . 1102 |xxxxxxxxxxxxxx| . . Bandwidth 1103 |xxxxxxxxxxxxxx| . . available for 1104 |xxxxxxxxxxxxxx| v . non-priority 1105 |--------------| --- . and priority 1106 |oooooooooooooo| . use 1107 |oooooooooooooo| . 1108 |oooooooooooooo| v 1109 --------------------------------------- 1111 Chart 9. Full non-priority load & Full Aggregate load 1113 A.3 Admission Priority with Priority Bypass Model (PBM) 1115 This section illustrates operations of admission priority when a 1116 simple Priority Bypass Model (PBM) is used for bandwidth allocation 1117 across non-priority traffic and priority traffic. With the Priority 1118 Bypass Model, non-priority traffic is subject to resource based 1119 admission control while priority traffic simply bypasses the resource 1120 based admission control. In other words: 1121 - when a non-priority call arrives, this call is subject to 1122 bandwidth admission control and is accepted if the current total load 1123 (aggregate over non-priority and priority traffic) is below the 1124 engineered/allocated bandwidth. 1125 - when a priority call arrives, this call is admitted regardless 1126 of the current load. 1128 A property of this model is that a priority call is never rejected. 1130 The rationale for this simple scheme is that, in practice in some 1131 networks: 1132 - the volume of priority calls is very low for the vast majority 1133 of time, so it may not be economical to completely set aside 1134 bandwidth for priority calls and preclude the utilization of 1135 this bandwidth by normal calls in normal situations 1136 - even in emergency periods where priority calls are more heavily 1137 used, those always still represent a fairly small proportion of 1138 the overall load which can be absorbed within the safety margin 1139 of the engineered capacity limits. Thus, even if they are 1140 admitted beyond the engineered bandwidth threshold, they are 1141 unlikely to result in noticeable QoS degradation. 1143 As with the MAM and RDM model, an operator may map the Priority 1144 Bypass model onto the Engineered Capacity limits according to 1145 different policies. The operator may decide to configure the 1146 bandwidth limit for admission of non-priority traffic to the full 1148 RSVP Extensions for Emergency Services January 2007 1150 engineered capacity limits; As an example, if the engineered capacity 1151 limit on a given link is X, the operator may configure the bandwidth 1152 limit for non-priority traffic to X. Alternatively, the operator may 1153 decide to configure the bandwidth limit for non-priority traffic to 1154 below the engineered capacity limits (so that the sum of the non- 1155 priority and priority traffic stays below the engineered capacity); 1156 As an example, if the engineered capacity limit on a given link is X, 1157 the operator may configure the bandwidth limit for non-priority 1158 traffic to 95% of X. Finally, the operator may decide to strike a 1159 balance in between. The considerations presented for these policies 1160 in the previous sections in the MAM and RDM contexts are equally 1161 applicable to the Priority Bypass Model. 1163 Chart 10 shows illustrates the bandwidth allocation with the Priority 1164 Bypass Model. 1166 ----------------------- 1167 ^ ^ | | ^ 1168 . . | | . 1169 Total . . | | . Bandwidth Limit 1170 (1) (2) | | . (on non-priority + priority) 1171 Engi- . . | | . for admission 1172 neered . or . | | . of non-priority traffic 1173 . . | | . 1174 Capacity. . | | . 1175 v . | | v 1176 . |--------------| --- 1177 . | | 1178 v | | 1179 | | 1181 Chart 10. Priority Bypass Model Bandwidth Allocation 1183 Chart 11 shows some of the non-priority capacity of this link being 1184 used. In this situation, both new non-priority and new priority calls 1185 would be accepted. 1187 ----------------------- 1188 ^ ^ |xxxxxxxxxxxxxx| ^ 1189 . . |xxxxxxxxxxxxxx| . 1190 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1191 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1192 Engi- . . | | . for admission 1193 neered . or . | | . of non-priority traffic 1194 . . | | . 1195 Capacity. . | | . 1196 v . | | v 1197 . |--------------| --- 1198 . | | 1200 RSVP Extensions for Emergency Services January 2007 1202 v | | 1203 | | 1205 Chart 11. Partial load of non-priority calls 1207 Chart 12 shows the same amount of non-priority load being used at 1208 this link, and a small amount of priority bandwidth being used. In 1209 this situation, both new non-priority and new priority calls would be 1210 accepted. 1212 ----------------------- 1213 ^ ^ |xxxxxxxxxxxxxx| ^ 1214 . . |xxxxxxxxxxxxxx| . 1215 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1216 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1217 Engi- . . |oooooooooooooo| . for admission 1218 neered . or . | | . of non-priority traffic 1219 . . | | . 1220 Capacity. . | | . 1221 v . | | v 1222 . |--------------| --- 1223 . | | 1224 v | | 1225 | | 1227 Chart 12. Partial load of non-priority calls 1228 & partial load of priority calls 1230 Chart 13 shows the case where aggregate non-priority and priority 1231 load exceeds the bandwidth limit for admission of non-priority 1232 traffic. In this situation, any new non-priority call is rejected 1233 while any new priority call is admitted. 1235 ----------------------- 1236 ^ ^ |xxxxxxxxxxxxxx| ^ 1237 . . |xxxxxxxxxxxxxx| . 1238 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1239 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1240 Engi- . . |oooooooooooooo| . for admission 1241 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1242 . . |xxoxxxxxxoxxxx| . 1243 Capacity. . |oxxxooooxxxxoo| . 1244 v . |xxoxxxooxxxxxx| v 1245 . |--------------| --- 1246 . |oooooooooooooo| 1247 v | | 1248 | | 1250 RSVP Extensions for Emergency Services January 2007 1252 Chart 13. Full non-priority load 1254 Appendix B: Example Usages of RSVP Extensions 1256 This section provides examples of how RSVP extensions defined in this 1257 document can be used (in conjunctions with other RSVP functionality 1258 and SIP functionality) to enforce different hypothetical policies for 1259 handling Emergency sessions in a given administrative domain. This 1260 Appendix does not provide additional specification. It is only 1261 included in this document for illustration purposes. The content of 1262 this appendix may be moved into a future applicability statement 1263 document. 1265 We assume an environment where SIP is used for session control and 1266 RSVP is used for resource reservation. 1268 In a mild abuse of language, we refer here to "Call Queueing" as the 1269 set of "session" layer capabilities that may be implemented by SIP 1270 user agents to influence their treatment of SIP requests. This may 1271 include the ability to "queue" call requests when those can not be 1272 immediately honored (in some cases with the notion of "bumping", or 1273 "displacement", of less important call request from that queue). It 1274 may include additional mechanisms such as exemption from certain 1275 network management controls, and alternate routing. 1277 We only mention below the RSVP policy elements that are to be 1278 enforced by PEPs. It is assumed that these policy elements are set at 1279 administrative domain boundaries by PDPs. The Admission Priority and 1280 Preemption Priority RSVP policy elements are set by PDPs as a result 1281 of processing the Application Level Resource Priority Policy Element 1282 (which is carried in RSVP messages). 1284 If one wants to implement an emergency service purely based on Call 1285 Queueing, one can achieve this by signaling emergency calls: 1286 * using "Resource-Priority" Header in SIP 1287 * not using Admission-Priority Policy Element in RSVP 1288 * not using Preemption Policy Element in RSVP 1290 If one wants to implement an emergency service based on Call 1291 Queueing and on "prioritized access to network layer resources", one 1292 can achieve this by signaling emergency calls: 1293 * using "Resource-Priority" Header in SIP 1294 * using Admission-Priority Policy Element in RSVP 1295 * not using Preemption Policy Element in RSVP 1296 Emergency calls will not result in preemption of any session. 1298 RSVP Extensions for Emergency Services January 2007 1300 Different bandwidth allocation models can be used to offer different 1301 "prioritized access to network resources". Just as examples, this 1302 includes strict setting aside of capacity for emergency sessions as 1303 well as simple bypass of admission limits for emergency sessions. 1305 If one wants to implement an emergency service based on Call Queueing, 1306 on "prioritized access to network layer resources", and ensures that 1307 (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 1308 non-emergency sessions are not affected by preemption, one can do 1309 that by signaling emergency calls: 1310 * using "Resource-Priority" Header in SIP 1311 * using Admission-Priority Policy Element in RSVP 1312 * using Preemption Policy Element in RSVP with: 1313 o setup (Emergency-1) > defending (Emergency-2) 1314 o setup (Emergency-2) <= defending (Emergency-1) 1315 o setup (Emergency-1) <= defending (Non-Emergency) 1316 o setup (Emergency-2) <= defending (Non-Emergency) 1318 If one wants to implement an emergency service based on Call Queueing, 1319 on "prioritized access to network layer resources", and ensure that 1320 "emergency" sessions can preempt regular sessions, one could do that 1321 by signaling emergency calls: 1322 * using "Resource-Priority" Header in SIP 1323 * using Admission-Priority Policy Element in RSVP 1324 * using Preemption Policy Element in RSVP with: 1325 o setup (Emergency) > defending (Non-Emergency) 1326 o setup (Non-Emergency) <= defending (Emergency) 1328 If one wants to implement an emergency service based on Call Queueing, 1329 on "prioritized access to network layer resources", and ensure that 1330 "emergency" sessions can partially preempt regular sessions (ie 1331 reduce their reservation size), one could do that by signaling 1332 emergency calls: 1333 * using "Resource-Priority" Header in SIP 1334 * using Admission-Priority Policy Element in RSVP 1335 * using Preemption in Policy Element RSVP with: 1336 o setup (Emergency) > defending (Non-Emergency) 1337 o setup (Non-Emergency) <= defending (Emergency) 1338 * activate RFC4495 RSVP Bandwidth Reduction mechanisms 1340 Authors' Address 1342 Francois Le Faucheur 1343 Cisco Systems, Inc. 1344 Village d'Entreprise Green Side - Batiment T3 1345 400, Avenue de Roumanille 1347 RSVP Extensions for Emergency Services January 2007 1349 06410 Biot Sophia-Antipolis 1350 France 1351 Email: flefauch@cisco.com 1353 James Polk 1354 Cisco Systems, Inc. 1355 2200 East President George Bush Turnpike 1356 Richardson, Texas 75082 1357 USA 1358 Email: jmpolk@cisco.com 1360 Ken Carlberg 1361 G11 1362 123a Versailles Circle 1363 Towson, MD. 21204 1364 USA 1365 email: carlberg@g11.org.uk 1367 Intellectual Property 1369 The IETF takes no position regarding the validity or scope of any 1370 Intellectual Property Rights or other rights that might be claimed to 1371 pertain to the implementation or use of the technology described in 1372 this document or the extent to which any license under such rights 1373 might or might not be available; nor does it represent that it has 1374 made any independent effort to identify any such rights. Information 1375 on the procedures with respect to rights in RFC documents can be 1376 found in BCP 78 and BCP 79. 1378 Copies of IPR disclosures made to the IETF Secretariat and any 1379 assurances of licenses to be made available, or the result of an 1380 attempt made to obtain a general license or permission for the use of 1381 such proprietary rights by implementers or users of this 1382 specification can be obtained from the IETF on-line IPR repository at 1383 http://www.ietf.org/ipr. 1385 The IETF invites any interested party to bring to its attention any 1386 copyrights, patents or patent applications, or other proprietary 1387 rights that may cover technology that may be required to implement 1388 this standard. Please address the information to the IETF at ietf- 1389 ipr@ietf.org. 1391 Full Copyright Statement 1393 RSVP Extensions for Emergency Services January 2007 1395 Copyright (C) The Internet Society (2007). 1397 This document is subject to the rights, licenses and restrictions 1398 contained in BCP 78, and except as set forth therein, the authors 1399 retain all their rights. 1401 This document and the information contained herein are provided on an 1402 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1403 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1404 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1405 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1406 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1407 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.