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