idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-03.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 1287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1258. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1265. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1271. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 5 characters 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 (July 2007) is 6122 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXX' is mentioned on line 606, but not defined ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) == Outdated reference: A later version (-01) exists of draft-behringer-tsvwg-rsvp-security-groupkeying-00 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 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-03.txt 8 Expires: March 2008 July 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 2. Overview of RSVP extensions and Operations.....................5 67 2.1. Operations of Admission Priority..........................7 68 3. New Policy Elements............................................7 69 3.1. Admission Priority Policy Element.........................8 70 3.1.1. Admission Priority Merging Rules 9 71 3.2. Application-Level Resource Priority Policy Element.......10 72 3.2.1. Application-Level Resource Priority Modifying and 73 Merging Rules 11 74 3.3. Default Handling.........................................11 75 4. Security Considerations.......................................12 76 4.1. Use of RSVP Authentication between RSVP nighbors.........12 77 4.2. Use of INTEGRITY object within the POLICY_DATA object....12 78 5. IANA Considerations...........................................13 79 6. Acknowledgments...............................................14 80 7. Normative References..........................................14 81 8. Informative References........................................15 82 Appendix A: Examples of Bandwidth Allocation Model for Admission 83 Priority.........................................................16 84 A.1 Admission Priority with Maximum Allocation Model (MAM)......16 85 A.2 Admission Priority with Russian Dolls Model (RDM)...........20 86 A.3 Admission Priority with Priority Bypass Model (PrBM)........22 87 Appendix B: Example Usages of RSVP Extensions....................25 88 Authors' Address.................................................27 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 2. Overview of RSVP extensions and Operations 188 Let us consider the case where a call requiring ETS type service is 189 to be established, and more specifically that the preference to be 190 granted to this call is in terms of network layer "admission 191 priority" (as opposed to preference granted through preemption of 192 existing calls). By "admission priority" we mean allowing that 193 priority call to seize network layer resources from the engineered 194 capacity that have been set-aside and not made available to normal 195 calls, or alternatively by allowing that call to seize additional 196 resources beyond the engineered capacity limits applied to normal 197 calls. 199 As described in [EMERG-IMP], the session establishment can be 200 conditioned to resource-based and policy-based network layer 201 admission control achieved via RSVP signaling. In the case where the 202 session control protocol is SIP, the use of RSVP-based admission 203 control by SIP is specified in [SIP-RESOURCE]. 205 Devices involved in the session establishment are expected to be 206 aware of the application-level priority requirements of emergency 207 calls. Again considering the case where the session control protocol 208 is SIP, the SIP user agents can be made aware of the resource 209 priority requirements in the case of an emergency call using the 210 Resource-Priority Header mechanism specified in [SIP-PRIORITY]. The 211 end-devices involved in the upper-layer session establishment simply 212 need to copy the application-level resource priority requirements 213 (e.g. as communicated in SIP Resource-Priority Header) inside the new 214 RSVP Application-Level Resource-Priority Policy Element defined in 215 this document. 217 Conveying the application-level resource priority requirements inside 218 the RSVP message allows this application level requirement to be 219 mapped/remapped into a different RSVP "admission priority" at every 220 administrative domain boundary based on the policy applicable in that 221 domain. In a typical model (see [FW-POLICY]) where PDPs control PEPs 222 at the periphery of the policy domain (e.g., in border routers), PDPs 223 would interpret the RSVP Application-Level Resource-Priority Policy 224 Element and map the requirement of the emergency session into an RSVP 225 "admission priority" level. Then, PDPs would convey this information 226 inside the new Admission Priority Policy Element defined in this 227 document. This way, the RSVP admission priority can be communicated 228 to downstream PEPs (ie RSVP Routers) of the same policy domain, which 229 have LPDPs but no controlling PDP. In turn, this means the necessary 230 RSVP Admission priority can be enforced at every RSVP hop, including 231 all the (many) hops which do not have any understanding of 232 Application-Level Resource-Priority semantics. 234 As an example of operation across multiple administrative domains, a 235 first domain might decide to provide network layer admission priority 236 to calls of a given Application Level Resource Priority and map it 237 into a high RSVP admission control priority inside the Admission 238 Priority Policy Element; while a second domain may decide to not 239 provide admission priority to calls of this same Application Level 240 Resource Priority and hence map it into a low RSVP admission control 241 priority. 243 As another example of operation across multiple administrative 244 domains, we can consider the case where the resource priority header 245 enumerates several namespaces, as explicitly allowed by [SIP- 246 PRIORITY], for support of scenarios where calls traverse multiple 247 administrative domains using different namespace. In that case, the 248 relevant namespace can be used at each domain boundary to map into an 249 RSVP Admission priority for that domain. It is not expected that the 250 RSVP Application-Level Resource-Priority Header Policy Element would 251 be taken into account at RSVP-hops within a given administrative 252 domain. It is expected to be used at administrative domain boundaries 253 only in order to set/reset the RSVP Admission Priority Policy Element. 255 The existence of pre-established inter-domain policy agreements or 256 Service Level Agreements may avoid the need to take real-time action 257 at administrative domain boundaries for mapping/remapping of 258 admission priorities. 260 Mapping/remapping by PDPs may also be applied to boundaries between 261 various signaling protocols, such as those advanced by the NSIS 262 working group. 264 As can be observed, the framework described above for 265 mapping/remapping application level resource priority requirements 266 into an RSVP admission priority can also be used together with [RSVP- 267 PREEMP] for mapping/remapping application level resource priority 268 requirements into an RSVP preemption priority (when preemption is 269 indeed needed). In that case, when processing the RSVP Application- 270 Level Resource-Priority Policy Element, the PDPs at boundaries 271 between administrative domains (or between various QoS signaling 272 protocols) can map it into an RSVP "preemption priority" information. 273 This Preemption priority information comprises a setup preemption 274 level and a defending preemption priority level. This preemption 275 priority information can then be encoded inside the Preemption 276 Priority Policy Element of [RSVP-PREEMP] and thus, can be taken into 277 account at every RSVP-enabled network hop as discussed [EMERG-IMP]. 278 Appendix B provides examples of various hypothetical policies for 279 emergency call handling, some of them involving admission priority, 280 some of them involving both admission priority and preemption 281 priority. Appendix B also identifies how the Application-Level 282 Resource Priority need to be mapped into RSVP policy elements by the 283 PDPs to realize these policies. 285 2.1. Operations of Admission Priority 287 The RSVP Admission Priority policy element defined in this document 288 allows admission bandwidth to be allocated preferentially to an 289 authorized priority service. Multiple models of bandwidth allocation 290 MAY be used to that end. 292 A number of bandwidth allocation models have been defined in the IETF 293 for allocation of bandwidth across different classes of traffic 294 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 295 Those include the Maximum Allocation Model (MAM) defined in [DSTE- 296 MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These 297 same models MAY however be applied for allocation of bandwidth across 298 different levels of admission priority as defined in this document. 299 Appendix A provides an illustration of how these bandwidth allocation 300 models can be applied for such purposes and introduces an additional 301 bandwidth allocation model that we term the Priority Bypass Model 302 (PrBM). It is important to note that the models described and 303 illustrated in Appendix A are only informative and do not represent a 304 recommended course of action. 306 We can see in these examples, that the RSVP Admission Priority may 307 effectively influence the fundamental admission control decision of 308 RSVP (for example by determining which bandwidth pool is to be used 309 by RSVP for performing its fundamental bandwidth allocation). In that 310 sense, we observe that the policy control and admission control are 311 not separate logics but instead somewhat blended. 313 3. New Policy Elements 315 The Framework document for policy-based admission control [FW-POLICY] 316 describes the various components that participate in policy decision 317 making (i.e., PDP, PEP and LPDP). 319 As described in section 2 of the present document, the Application- 320 Level Resource Priority Policy Element and the Admission Priority 321 Policy Element serve different roles in this framework: 323 - the Application-Level Resource Priority Policy Element conveys 324 application level information and is processed by PDPs 326 - the emphasis of Admission Priority Policy Element is to be 327 simple, stateless, and light-weight such that it can be 328 processed internally within a node's LPDP. It can then be 329 enforced internally within a node's PEP. It is set by PDPs 330 based on processing of the Application-Level Resource Priority 331 Policy Element. 333 [RSVP-POLICY] defines extensions for supporting generic policy based 334 admission control in RSVP. These extensions include the standard 335 format of POLICY_DATA objects and a description of RSVP handling of 336 policy events. 338 The POLICY_DATA object contains one or more of Policy Elements, each 339 representing a different (and perhaps orthogonal) policy. As an 340 example, [RSVP-PREEMP] specifies the Preemption Priority Policy 341 Element. 343 This document defines two new Policy Elements called: 344 - the Admission Priority Policy Element 345 - the Application-Level Resource Priority Policy Element 347 3.1. Admission Priority Policy Element 349 The format of the Admission Priority policy element is as follows: 351 0 0 0 1 1 2 2 3 352 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 353 +-------------+-------------+-------------+-------------+ 354 | Length | P-Type = ADMISSION_PRI | 355 +-------------+-------------+-------------+-------------+ 356 | Flags | M. Strategy | Error Code | Reserved | 357 +-------------+-------------+-------------+-------------+ 358 | Reserved |Adm. Priority| 359 +---------------------------+---------------------------+ 361 Length: 16 bits 362 Always 12. The overall length of the policy element, in bytes. 364 P-Type: 16 bits 365 ADMISSION_PRI = To be allocated by IANA 366 (see "IANA Considerations" section) 368 Flags: Reserved (MUST be set to zero on transmit and ignored on 369 receive) 371 Merge Strategy: 8 bits (only applicable to multicast flows) 372 1 Take priority of highest QoS 373 2 Take highest priority 374 3 Force Error on heterogeneous merge 375 (See section 3.1.1) 377 Error code: 8 bits (only applicable to multicast flows) 378 0 NO_ERROR Value used for regular ADMISSION_PRI elements 379 2 HETEROGENEOUS This element encountered heterogeneous merge 381 Reserved: 8 bits 382 Always 0. 384 Reserved: 24 bits 385 Always 0. 387 Adm. Priority (Admission Priority): 8 bits (unsigned) 388 The admission control priority of the flow, in terms of access 389 to network bandwidth in order to provide higher probability of 390 call completion to selected flows. Higher values represent 391 higher Priority. 393 Bandwidth allocation models such as those described in Appendix 394 A are to be used by the RSVP router to achieve such increased 395 probability of call completion. The admission priority value 396 effectively indicates which bandwidth constraint(s) of the 397 bandwidth constraint model in use is(are) applicable to 398 admission of this RSVP reservation. 400 Note that the Admission Priority Policy Element does NOT indicate 401 that this RSVP reservation is to preempt any other RSVP reservation. 402 If a priority session justifies both admission priority and 403 preemption priority, the corresponding RSVP reservation needs to 404 carry both an Admission Priority Policy Element and a Preemption 405 Priority Policy Element. The Admission Priority and Preemption 406 Priority are handled by LPDPs and PEPs as separate mechanisms. They 407 can be used one without the other, or they can be used both in 408 combination. 410 3.1.1. Admission Priority Merging Rules 412 This section discusses alternatives for dealing with RSVP admission 413 priority in case of merging of reservations. As merging is only 414 applicable to multicast, this section also only applies to multicast 415 sessions. 417 The rules for merging Admission Priority Policy Elements are the same 418 as those defined in [RSVP-PREEMP] for merging Preemption Priority 419 Policy Elements. In particular, the following merging strategies are 420 supported: 421 - Take priority of highest QoS 422 - Take highest priority 423 - Force Error on heterogeneous merge. 425 The only difference with [RSVP-PREEMP] is that this document does not 426 recommend any merge strategies for Admission Priority while [RSVP- 427 PREEMP] recommends the first of these merge strategies for Preemption 428 Priority. 430 Note that with the Admission Priority (as is the case with the 431 Preemption Priority), "Take highest priority" translates into "take 432 the highest numerical value". 434 3.2. Application-Level Resource Priority Policy Element 436 The format of the Application-Level Resource Priority policy element 437 is as follows: 439 0 0 0 1 1 2 2 3 440 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 441 +-------------+-------------+-------------+-------------+ 442 | Length | P-Type = APP_RESOURCE_PRI | 443 +-------------+-------------+-------------+-------------+ 444 // ALRP List // 445 +---------------------------+---------------------------+ 447 Length: The length of the policy element (including the Length and P- 448 Type) is in number of octets (MUST be a multiple of 4) and 449 indicates the end of the ALRP list. 451 P-Type: 16 bits 452 APP_RESOURCE_PRI = To be allocated by IANA 453 (see "IANA Considerations" section) 455 ALRP: 457 0 0 0 1 1 2 2 3 458 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 459 +---------------------------+---------------------------+ 460 | ALRP Namespace | Reserved | ALRP Priority | 461 +---------------------------+---------------------------+ 463 ALRP Namespace (Application-Level Resource Priority Namespace): 464 16 bits (unsigned) 465 Contains a numerical value identifying the namespace of the 466 application-level resource priority. This value is encoded 467 as per the "Resource-Priority Namespace" IANA registry. (See 468 IANA Considerations section for the request to IANA to 469 extend the registry to include this numerical value). 471 ALRP Priority: (Application-Level Resource Priority Priority): 472 8 bits (unsigned) 473 Contains the priority value within the namespace of the 474 application-level resource priority. This is encoded as a 475 numerical value which represents the priority defined in the 476 "Resource-Priority Namespace" IANA registry for the 477 considered namespace, starting from 0 for the highest 478 priority and increasing as priority decreases. 479 For example, as "flash-override", "flash", "immediate", 480 "priority" and "routine" are the priorities in decreasing 481 order of priority registered for the "dsn" namespace, those 482 are respectively encoded as value 0, 1, 2, 3 and 4. As 483 another example, as "flash-override-override", "flash- 484 override", "flash", "immediate", "priority" and "routine" 485 are the priorities in decreasing order of priority 486 registered for the "drsn" namespace, those are respectively 487 encoded as value 0, 1, 2, 3, 4 and 5. 489 Reserved: 16 bits 490 Always 0. 492 3.2.1. Application-Level Resource Priority Modifying and Merging Rules 494 When POLICY_DATA objects are protected by integrity, LPDPs should not 495 attempt to modify them. They MUST be forwarded as-is to ensure their 496 security envelope is not invalidated. 498 In case of multicast, when POLICY_DATA objects are not protected by 499 integrity, LPDPs MAY merge incoming Application-Level Resource 500 Priority elements to reduce their size and number. When they do merge 501 those, LPDPs MUST do so according to the following rule: 503 The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 504 all the ALRPs appearing in the ALRP List of an incoming 505 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 506 once. In other words, the outgoing ALRP List is the union of the 507 incoming ALRP Lists that are merged. 509 As merging is only applicable to Multicast, this rule only applies to 510 Multicast sessions. 512 3.3. Default Handling 514 As specified in section 4.2 of [RSVP-POLICY], Policy Ignorant Nodes 515 (PINs) implement a default handling of POLICY_DATA objects ensuring 516 that those objects can traverse PIN nodes in transit from one PEP to 517 another. This applies to the situations where POLICY_DATA objects 518 contain the Admission Priority Policy Element and the ALRP Policy 519 Element specified in this document, so that those can traverse PIN 520 nodes. 522 Section 4.2 of [RSVP-POLICY] also defines a similar default behavior 523 for policy-capable nodes that do not recognized a particular Policy 524 Element. This applies to the Admission Priority Policy Element and 525 the ALRP Policy Element specified in this document, so that those can 526 traverse policy-capable nodes that do not support this document. 528 4. Security Considerations 530 The ADMISSION_PRI and APP_RESOURCE_PRI are Policy Elements that can 531 be signaled by RSVP through encapsulation in a Policy Data object as 532 defined in [RSVP-POLICY]. Therefore, like any other Policy Elements, 533 their integrity can be protected as discussed in section 6 of [RSVP- 534 POLICY] by two optional security mechanisms. The first mechanism 535 relies on RSVP Authentication as specified in [RSVP-CRYPTO-1] and 536 [RSVP-CRYPTO-2] to provide a chain of trust when all RSVP nodes are 537 policy capable. With this mechanism, the INTEGRITY object is carried 538 inside RSVP messages. The second mechanism relies on the INTEGRITY 539 object within the POLICY_DATA object to guarantee integrity between 540 RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. 542 4.1. Use of RSVP Authentication between RSVP nighbors 544 This mechanism can be used can be used between RSVP neighbors that 545 are policy capable. The RSVP neighbors use shared keys to compute the 546 cryptographic signature of the RSVP message. [RSVP-GROUPKEYING] 547 discusses key types, key provisioning methods as well as their 548 respective applicability. 550 4.2. Use of INTEGRITY object within the POLICY_DATA object 552 The INTEGRITY object within the POLICY_DATA object can be used to 553 guarantee integrity between non-neighboring RSVP PEPs. 555 Details for computation of the content of the INTEGRITY object can be 556 found in Appendix B of [RSVP-POLICY]. This states that the Policy 557 Decision Point (PDP), at its discretion, and based on destination 558 PEP/PDP or other criteria, selects an Authentication Key and the hash 559 algorithm to be used. Keys to be used between PDPs can be distributed 560 manually or via standard key management protocol for secure key 561 distribution. 563 Note that where non-RSVP hops may exist in between RSVP hops, as well 564 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 565 between PEPs, it may be difficult for the PDP to determine what is 566 the destination PDP for a POLICY_DATA object contained in some RSVP 567 messages (such as a Path message). This is because in those cases the 568 next PEP is not known at the time of forwarding the message. In this 569 situation, key shared across multiple PDPs may be used. This is 570 conceptually similar to the use of key shared across multiple RSVP 571 neighbors discussed in [RSVP-GROUPKEYING]. We observe also that this 572 issue may not exist in some deployment scenarios where a single (or 573 low number of) PDP is used to control all the PEPs of a region (such 574 as an administrative domain). In such scenarios, it may be easy for a 575 PDP to determine what is the next hop PDP, even when the next hop PEP 576 is not known, simply by determining what is the next region that will 577 be traversed (say based on the destination address). 579 5. IANA Considerations 581 As specified in [RSVP-POLICY], Standard RSVP Policy Elements (P-type 582 values) are to be assigned by IANA as per "IETF Consensus" following 583 the policies outlined in [IANA-CONSIDERATIONS]. 585 IANA needs to allocate two P-Types from the Standard RSVP Policy 586 Element range: 587 - one P-Type to the Admission Priority Policy Element 588 - one P-Type to the Application-Level Resource Priority 589 Policy Element 591 This document defines an ALRP Priority field in section 3.2 that 592 contains a numerical value identifying the namespace of the 593 application-level resource priority. The IANA already maintains the 594 Resource-Priority Namespaces registry (under the SIP Parameters) 595 listing all such namespace. However, that registry does not currently 596 allocate a numerical value to each namespace. Hence, this document 597 requests the IANA to extend the Resource-Priority Namespace registry 598 in the following ways: 599 - a new column should be added to the registry 600 - the title of the new column should be "Namespace numerical 601 Value *" 602 - in the Legend, add a line saying "Namespace numerical 603 Value = the unique numerical value identifying the 604 namespace" 605 - add a line at the bottom of the registry stating the 606 following "* : [RFCXXX] " where XXX is the RFC number of 607 the present document 608 - allocate an actual numerical value to each namespace in 609 the registry and state that value in the new "Namespace 610 numerical Value *" column. 611 A numerical value should be allocated immediately by IANA to all 612 existing namespace. Then, in the future, IANA should automatically 613 allocate a numerical value to any new namespace added to the registry. 615 [draft-ietf-nsis-qspec] also uses numerical values for Resource- 616 Priority Namespaces. The request IANA to create a new registry to 617 allocate numerical values to each namespace. We suggest that the 618 approach above be followed instead (i.e. extend the existing 619 registry) and that [draft-ietf-nsis-qspec] also makes use of the 620 values defined in the new "Namespace numerical Value *" column of the 621 extended existing Resource-Priority Namespace registry. In any case, 622 the IANA should only do one of the two approaches (an not both). 624 6. Acknowledgments 626 We would like to thank An Nguyen for his encouragement to address 627 this topic and ongoing comments. Also, this document borrows heavily 628 from some of the work of S. Herzog on Preemption Priority Policy 629 Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input 630 into this document. 632 7. Normative References 634 [IANA-CONSIDERATIONS] Alverstrand et al., "Guidelines for Writing an 635 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 637 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 638 (RSVP)- Functional Specification", RFC 2205, September 1997. 640 [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 641 Cryptographic Authentication", RFC 2747, January 2000. 643 [RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic 644 Authentication -- Updated Message Type Value", RFC 3097, April 2001. 646 [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC 647 2750, January 2000. 649 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 650 Element", RFC 3181, October 2001. 652 [SIP] Rosenberg et al., "SIP: Session Initiation Protocol", RFC3261, 653 June 2002 655 [SIP-PRIORITY] H. Schulzrinne & J. Polk. "Communications Resource 656 Priority for the Session Initiation Protocol (SIP)", RFC4412, 657 February 2006. 659 8. Informative References 661 [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth 662 Constraints Model for Diffserv-aware MPLS Traffic Engineering", RFC 663 4125, June 2005. 665 [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints 666 Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June 667 2005 669 [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency 670 Telecommunications Service for Real Time Services in the Internet 671 Protocol Suite", RFC 4542, May 2006. 673 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for 674 Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. 676 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 677 for Emergency Telecommunication Service (ETS)", RFC 3690, February 678 2004. 680 [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 681 for Policy-based Admission Control", RFC 2753, January 2000. 683 [ITU.I.225] ITU, "Multi-Level Precedence and Preemption Service, ITU, 684 Recommendation, I.255.3, July, 1990. 686 [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 687 Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, 688 October 2001. 690 [RSVP-GROUPKEYING] Behringer, M., Le Faucheur, F., "A Framework for 691 RSVP Security using Dynamic Group Keying", draft-behringer-tsvwg- 692 rsvp-security-groupkeying-00.txt, work in progress. 694 [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, 695 "Integration of Resource Management and Session Initiation Protocol 696 (SIP)", RFC 3312, October 2002. 698 Appendix A: Examples of Bandwidth Allocation Model for Admission 699 Priority 701 Sections A.1 and A.2 respectively illustrate how the Maximum 702 Allocation Model [DSTE-MAM] and the Russian Dolls Model (RDM) [DSTE- 703 RDM] can be used for support of admission priority. Section A.3 704 illustrates how a simple "Priority Bypass Model" can also be used for 705 support of admission priority. 707 For simplicity, operations with only a single "priority" level 708 (beyond non-priority) are illustrated here; However, the reader will 709 appreciate that operations with multiple priority levels can easily 710 be supported with these models. 712 In all the charts below: 713 x represents a non-priority session 714 o represents a priority session 716 A.1 Admission Priority with Maximum Allocation Model (MAM) 718 This section illustrates operations of admission priority when a 719 Maximum Allocation Model (MAM) is used for bandwidth allocation 720 across non-priority traffic and priority traffic. A property of the 721 Maximum Allocation Model is that priority traffic can not use more 722 than the bandwidth made available to priority traffic (even if the 723 non-priority traffic is not using all of the bandwidth available for 724 it). 726 ----------------------- 727 ^ ^ ^ | | ^ 728 . . . | | . 729 Total . . . | | . Bandwidth 730 (1)(2)(3) | | . Available 731 Engi- . . . | | . for non-priority use 732 neered .or.or. | | . 733 . . . | | . 734 Capacity. . . | | . 735 v . . | | v 736 . . |--------------| --- 737 v . | | ^ 738 . | | . Bandwidth available for 739 v | | v priority use 740 ------------------------- 742 Chart 1. MAM Bandwidth Allocation 744 Chart 1 shows a link within a routed network conforming to this 745 document. On this link are two amounts of bandwidth available to two 746 types of traffic: non-priority and priority. 747 If the non-priority traffic load reaches the maximum bandwidth 748 available for non-priority, no additional non-priority sessions can 749 be accepted even if the bandwidth reserved for priority traffic is 750 not currently fully utilized. 752 With the Maximum Allocation Model, in the case where the priority 753 load reaches the maximum bandwidth reserved for priority calls, no 754 additional priority sessions can be accepted. 756 As illustrated in Chart 1, an operator may map the MAM model onto the 757 Engineered Capacity limits according to different policies. At one 758 extreme, where the proportion of priority traffic is reliably known 759 to be fairly small at all times and where there may be some safety 760 margin factored in the engineered capacity limits, the operator may 761 decide to configure the bandwidth available for non-priority use to 762 the full engineered capacity limits; effectively allowing the 763 priority traffic to ride within the safety margin of this engineered 764 capacity. This policy can be seen as an economically attractive 765 approach as all of the engineered capacity is made available to non- 766 priority calls. This policy illustrated as (1) in Chart 1. As an 767 example, if the engineered capacity limit on a given link is X, the 768 operator may configure the bandwidth available to non-priority 769 traffic to X, and the bandwidth available to priority traffic to 5% 770 of X. 772 At the other extreme, where the proportion of priority traffic may be 773 significant at times and the engineered capacity limits are very 774 tight, the operator may decide to configure the bandwidth available 775 to non-priority traffic and the bandwidth available to priority 776 traffic such that their sum is equal to the engineered capacity 777 limits. This guarantees that the total load across non-priority and 778 priority traffic is always below the engineered capacity and, in turn, 779 guarantees there will never be any QoS degradation. However, this 780 policy is less attractive economically as it prevents non-priority 781 calls from using the full engineered capacity, even when there is no 782 or little priority load, which is the majority of time. This policy 783 illustrated as (3) in Chart 1. As an example, if the engineered 784 capacity limit on a given link is X, the operator may configure the 785 bandwidth available to non-priority traffic to 95% of X, and the 786 bandwidth available to priority traffic to 5% of X. 788 Of course, an operator may also strike a balance anywhere in between 789 these two approaches. This policy illustrated as (2) in Chart 1. 791 Chart 2 shows some of the non-priority capacity of this link being 792 used. 794 ----------------------- 795 ^ ^ ^ | | ^ 796 . . . | | . 797 Total . . . | | . Bandwidth 798 . . . | | . Available 799 Engi- . . . | | . for non-priority use 800 neered .or.or. |xxxxxxxxxxxxxx| . 801 . . . |xxxxxxxxxxxxxx| . 802 Capacity. . . |xxxxxxxxxxxxxx| . 803 v . . |xxxxxxxxxxxxxx| v 804 . . |--------------| --- 805 v . | | ^ 806 . | | . Bandwidth available for 807 v | | v priority use 808 ------------------------- 809 Chart 2. Partial load of non-priority calls 811 Chart 3 shows the same amount of non-priority load being used at this 812 link, and a small amount of priority bandwidth being used. 814 ----------------------- 815 ^ ^ ^ | | ^ 816 . . . | | . 817 Total . . . | | . Bandwidth 818 . . . | | . Available 819 Engi- . . . | | . for non-priority use 820 neered .or.or. |xxxxxxxxxxxxxx| . 821 . . . |xxxxxxxxxxxxxx| . 822 Capacity. . . |xxxxxxxxxxxxxx| . 823 v . . |xxxxxxxxxxxxxx| v 824 . . |--------------| --- 825 v . | | ^ 826 . | | . Bandwidth available for 827 v |oooooooooooooo| v priority use 828 ------------------------- 830 Chart 3. Partial load of non-priority calls 831 & partial load of priority calls 833 Chart 4 shows the case where non-priority load equates or exceeds the 834 maximum bandwidth available to non-priority traffic. Note that 835 additional non-priority sessions would be rejected even if the 836 bandwidth reserved for priority sessions is not fully utilized. 838 ----------------------- 839 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 840 . . . |xxxxxxxxxxxxxx| . 841 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 842 . . . |xxxxxxxxxxxxxx| . Available 843 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 844 neered .or.or. |xxxxxxxxxxxxxx| . 845 . . . |xxxxxxxxxxxxxx| . 846 Capacity. . . |xxxxxxxxxxxxxx| . 847 v . . |xxxxxxxxxxxxxx| v 848 . . |--------------| --- 849 v . | | ^ 850 . | | . Bandwidth available for 851 v |oooooooooooooo| v priority use 852 ------------------------- 853 Chart 4. Full non-priority load 854 & partial load of priority calls 856 Chart 5 shows the case where the priority traffic equates or exceeds 857 the bandwidth reserved for such priority traffic. 859 In that case additional priority sessions could not be accepted. Note 860 that this does not mean that such calls are dropped altogether: they 861 may be handled by mechanisms, which are beyond the scope of this 862 particular document (such as establishment through preemption of 863 existing non-priority sessions, or such as queuing of new priority 864 session requests until capacity becomes available again for priority 865 traffic). 867 ----------------------- 868 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 869 . . . |xxxxxxxxxxxxxx| . 870 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 871 . . . |xxxxxxxxxxxxxx| . Available 872 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 873 neered .or.or. |xxxxxxxxxxxxxx| . 874 . . . |xxxxxxxxxxxxxx| . 875 Capacity. . . | | . 876 v . . | | v 877 . . |--------------| --- 878 v . |oooooooooooooo| ^ 879 . |oooooooooooooo| . Bandwidth available for 880 v |oooooooooooooo| v priority use 881 ------------------------- 883 Chart 5. Partial non-priority load & Full priority load 885 A.2 Admission Priority with Russian Dolls Model (RDM) 887 This section illustrates operations of admission priority when a 888 Russian Dolls Model (RDM) is used for bandwidth allocation across 889 non-priority traffic and priority traffic. A property of the Russian 890 Dolls Model is that priority traffic can use the bandwidth which is 891 not currently used by non-priority traffic. 893 As with the MAM model, an operator may map the RDM model onto the 894 Engineered Capacity limits according to different policies. The 895 operator may decide to configure the bandwidth available for non- 896 priority use to the full engineered capacity limits; As an example, 897 if the engineered capacity limit on a given link is X, the operator 898 may configure the bandwidth available to non-priority traffic to X, 899 and the bandwidth available to non-priority and priority traffic to 900 105% of X. 902 Alternatively, the operator may decide to configure the bandwidth 903 available to non-priority and priority traffic to the engineered 904 capacity limits; As an example, if the engineered capacity limit on a 905 given link is X, the operator may configure the bandwidth available 906 to non-priority traffic to 95% of X, and the bandwidth available to 907 non-priority and priority traffic to X. 909 Finally, the operator may decide to strike a balance in between. The 910 considerations presented for these policies in the previous section 911 in the MAM context are equally applicable to RDM. 913 Chart 6 shows the case where only some of the bandwidth available to 914 non-priority traffic is being used and a small amount of priority 915 traffic is in place. In that situation both new non-priority sessions 916 and new priority sessions would be accepted. 918 -------------------------------------- 919 |xxxxxxxxxxxxxx| . ^ 920 |xxxxxxxxxxxxxx| . Bandwidth . 921 |xxxxxxxxxxxxxx| . Available for . 922 |xxxxxxxxxxxxxx| . non-priority . 923 |xxxxxxxxxxxxxx| . use . 924 |xxxxxxxxxxxxxx| . . Bandwidth 925 | | . . available for 926 | | v . non-priority 927 |--------------| --- . and priority 928 | | . use 929 | | . 930 |oooooooooooooo| v 931 --------------------------------------- 933 Chart 6. Partial non-priority load & Partial Aggregate load 935 Chart 7 shows the case where all of the bandwidth available to non- 936 priority traffic is being used and a small amount of priority traffic 937 is in place. In that situation new priority sessions would be 938 accepted but new non-priority sessions would be rejected. 940 -------------------------------------- 941 |xxxxxxxxxxxxxx| . ^ 942 |xxxxxxxxxxxxxx| . Bandwidth . 943 |xxxxxxxxxxxxxx| . Available for . 944 |xxxxxxxxxxxxxx| . non-priority . 945 |xxxxxxxxxxxxxx| . use . 946 |xxxxxxxxxxxxxx| . . Bandwidth 947 |xxxxxxxxxxxxxx| . . available for 948 |xxxxxxxxxxxxxx| v . non-priority 949 |--------------| --- . and priority 950 | | . use 951 | | . 952 |oooooooooooooo| v 953 --------------------------------------- 955 Chart 7. Full non-priority load & Partial Aggregate load 957 Chart 8 shows the case where only some of the bandwidth available to 958 non-priority traffic is being used and a heavy load of priority 959 traffic is in place. In that situation both new non-priority sessions 960 and new priority sessions would be accepted. 961 Note that, as illustrated in Chart 7, priority calls use some of the 962 bandwidth currently not used by non-priority traffic. 964 -------------------------------------- 965 |xxxxxxxxxxxxxx| . ^ 966 |xxxxxxxxxxxxxx| . Bandwidth . 967 |xxxxxxxxxxxxxx| . Available for . 968 |xxxxxxxxxxxxxx| . non-priority . 969 |xxxxxxxxxxxxxx| . use . 970 | | . . Bandwidth 971 | | . . available for 972 |oooooooooooooo| v . non-priority 973 |--------------| --- . and priority 974 |oooooooooooooo| . use 975 |oooooooooooooo| . 976 |oooooooooooooo| v 977 --------------------------------------- 979 Chart 8. Partial non-priority load & Heavy Aggregate load 981 Chart 9 shows the case where all of the bandwidth available to non- 982 priority traffic is being used and all of the remaining available 983 bandwidth is used by priority traffic. In that situation new non- 984 priority sessions would be rejected. In that situation new priority 985 sessions could not be accepted right away. Those priority sessions 986 may be handled by mechanisms, which are beyond the scope of this 987 particular document (such as established through preemption of 988 existing non-priority sessions, or such as queuing of new priority 989 session requests until capacity becomes available again for priority 990 traffic). 992 -------------------------------------- 993 |xxxxxxxxxxxxxx| . ^ 994 |xxxxxxxxxxxxxx| . Bandwidth . 995 |xxxxxxxxxxxxxx| . Available for . 996 |xxxxxxxxxxxxxx| . non-priority . 997 |xxxxxxxxxxxxxx| . use . 998 |xxxxxxxxxxxxxx| . . Bandwidth 999 |xxxxxxxxxxxxxx| . . available for 1000 |xxxxxxxxxxxxxx| v . non-priority 1001 |--------------| --- . and priority 1002 |oooooooooooooo| . use 1003 |oooooooooooooo| . 1004 |oooooooooooooo| v 1005 --------------------------------------- 1007 Chart 9. Full non-priority load & Full Aggregate load 1009 A.3 Admission Priority with Priority Bypass Model (PrBM) 1011 This section illustrates operations of admission priority when a 1012 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1013 across non-priority traffic and priority traffic. With the Priority 1014 Bypass Model, non-priority traffic is subject to resource based 1015 admission control while priority traffic simply bypasses the resource 1016 based admission control. In other words: 1017 - when a non-priority call arrives, this call is subject to 1018 bandwidth admission control and is accepted if the current total load 1019 (aggregate over non-priority and priority traffic) is below the 1020 engineered/allocated bandwidth. 1021 - when a priority call arrives, this call is admitted regardless 1022 of the current load. 1024 A property of this model is that a priority call is never rejected. 1026 The rationale for this simple scheme is that, in practice in some 1027 networks: 1028 - the volume of priority calls is very low for the vast majority 1029 of time, so it may not be economical to completely set aside 1030 bandwidth for priority calls and preclude the utilization of 1031 this bandwidth by normal calls in normal situations 1032 - even in emergency periods where priority calls are more heavily 1033 used, those always still represent a fairly small proportion of 1034 the overall load which can be absorbed within the safety margin 1035 of the engineered capacity limits. Thus, even if they are 1036 admitted beyond the engineered bandwidth threshold, they are 1037 unlikely to result in noticeable QoS degradation. 1039 As with the MAM and RDM model, an operator may map the Priority 1040 Bypass model onto the Engineered Capacity limits according to 1041 different policies. The operator may decide to configure the 1042 bandwidth limit for admission of non-priority traffic to the full 1043 engineered capacity limits; As an example, if the engineered capacity 1044 limit on a given link is X, the operator may configure the bandwidth 1045 limit for non-priority traffic to X. Alternatively, the operator may 1046 decide to configure the bandwidth limit for non-priority traffic to 1047 below the engineered capacity limits (so that the sum of the non- 1048 priority and priority traffic stays below the engineered capacity); 1049 As an example, if the engineered capacity limit on a given link is X, 1050 the operator may configure the bandwidth limit for non-priority 1051 traffic to 95% of X. Finally, the operator may decide to strike a 1052 balance in between. The considerations presented for these policies 1053 in the previous sections in the MAM and RDM contexts are equally 1054 applicable to the Priority Bypass Model. 1056 Chart 10 shows illustrates the bandwidth allocation with the Priority 1057 Bypass Model. 1059 ----------------------- 1060 ^ ^ | | ^ 1061 . . | | . 1062 Total . . | | . Bandwidth Limit 1063 (1) (2) | | . (on non-priority + priority) 1064 Engi- . . | | . for admission 1065 neered . or . | | . of non-priority traffic 1066 . . | | . 1067 Capacity. . | | . 1068 v . | | v 1069 . |--------------| --- 1070 . | | 1071 v | | 1072 | | 1074 Chart 10. Priority Bypass Model Bandwidth Allocation 1076 Chart 11 shows some of the non-priority capacity of this link being 1077 used. In this situation, both new non-priority and new priority calls 1078 would be accepted. 1080 ----------------------- 1081 ^ ^ |xxxxxxxxxxxxxx| ^ 1082 . . |xxxxxxxxxxxxxx| . 1083 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1084 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1085 Engi- . . | | . for admission 1086 neered . or . | | . of non-priority traffic 1087 . . | | . 1088 Capacity. . | | . 1089 v . | | v 1090 . |--------------| --- 1091 . | | 1092 v | | 1093 | | 1095 Chart 11. Partial load of non-priority calls 1097 Chart 12 shows the same amount of non-priority load being used at 1098 this link, and a small amount of priority bandwidth being used. In 1099 this situation, both new non-priority and new priority calls would be 1100 accepted. 1102 ----------------------- 1103 ^ ^ |xxxxxxxxxxxxxx| ^ 1104 . . |xxxxxxxxxxxxxx| . 1105 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1106 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1107 Engi- . . |oooooooooooooo| . for admission 1108 neered . or . | | . of non-priority traffic 1109 . . | | . 1110 Capacity. . | | . 1111 v . | | v 1112 . |--------------| --- 1113 . | | 1114 v | | 1115 | | 1117 Chart 12. Partial load of non-priority calls 1118 & partial load of priority calls 1120 Chart 13 shows the case where aggregate non-priority and priority 1121 load exceeds the bandwidth limit for admission of non-priority 1122 traffic. In this situation, any new non-priority call is rejected 1123 while any new priority call is admitted. 1125 ----------------------- 1126 ^ ^ |xxxxxxxxxxxxxx| ^ 1127 . . |xxxxxxxxxxxxxx| . 1128 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1129 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1130 Engi- . . |oooooooooooooo| . for admission 1131 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1132 . . |xxoxxxxxxoxxxx| . 1133 Capacity. . |oxxxooooxxxxoo| . 1134 v . |xxoxxxooxxxxxx| v 1135 . |--------------| --- 1136 . |oooooooooooooo| 1137 v | | 1138 | | 1140 Chart 13. Full non-priority load 1142 Appendix B: Example Usages of RSVP Extensions 1144 This section provides examples of how RSVP extensions defined in this 1145 document can be used (in conjunctions with other RSVP functionality 1146 and SIP functionality) to enforce different hypothetical policies for 1147 handling Emergency sessions in a given administrative domain. This 1148 Appendix does not provide additional specification. It is only 1149 included in this document for illustration purposes. The content of 1150 this appendix may be moved into a future applicability statement 1151 document. 1153 We assume an environment where SIP is used for session control and 1154 RSVP is used for resource reservation. 1156 In a mild abuse of language, we refer here to "Call Queueing" as the 1157 set of "session" layer capabilities that may be implemented by SIP 1158 user agents to influence their treatment of SIP requests. This may 1159 include the ability to "queue" call requests when those can not be 1160 immediately honored (in some cases with the notion of "bumping", or 1161 "displacement", of less important call request from that queue). It 1162 may include additional mechanisms such as exemption from certain 1163 network management controls, and alternate routing. 1165 We only mention below the RSVP policy elements that are to be 1166 enforced by PEPs. It is assumed that these policy elements are set at 1167 administrative domain boundaries by PDPs. The Admission Priority and 1168 Preemption Priority RSVP policy elements are set by PDPs as a result 1169 of processing the Application Level Resource Priority Policy Element 1170 (which is carried in RSVP messages). 1172 If one wants to implement an emergency service purely based on Call 1173 Queueing, one can achieve this by signaling emergency calls: 1174 * using "Resource-Priority" Header in SIP 1175 * not using Admission-Priority Policy Element in RSVP 1176 * not using Preemption Policy Element in RSVP 1178 If one wants to implement an emergency service based on Call 1179 Queueing and on "prioritized access to network layer resources", one 1180 can achieve this by signaling emergency calls: 1181 * using "Resource-Priority" Header in SIP 1182 * using Admission-Priority Policy Element in RSVP 1183 * not using Preemption Policy Element in RSVP 1184 Emergency calls will not result in preemption of any session. 1185 Different bandwidth allocation models can be used to offer different 1186 "prioritized access to network resources". Just as examples, this 1187 includes strict setting aside of capacity for emergency sessions as 1188 well as simple bypass of admission limits for emergency sessions. 1190 If one wants to implement an emergency service based on Call Queueing, 1191 on "prioritized access to network layer resources", and ensures that 1192 (say) "Emergency-1" sessions can preempt "Emergency-2" sessions, but 1193 non-emergency sessions are not affected by preemption, one can do 1194 that by signaling emergency calls: 1195 * using "Resource-Priority" Header in SIP 1196 * using Admission-Priority Policy Element in RSVP 1197 * using Preemption Policy Element in RSVP with: 1198 o setup (Emergency-1) > defending (Emergency-2) 1199 o setup (Emergency-2) <= defending (Emergency-1) 1200 o setup (Emergency-1) <= defending (Non-Emergency) 1201 o setup (Emergency-2) <= defending (Non-Emergency) 1203 If one wants to implement an emergency service based on Call Queueing, 1204 on "prioritized access to network layer resources", and ensure that 1205 "emergency" sessions can preempt regular sessions, one could do that 1206 by signaling emergency calls: 1207 * using "Resource-Priority" Header in SIP 1208 * using Admission-Priority Policy Element in RSVP 1209 * using Preemption Policy Element in RSVP with: 1210 o setup (Emergency) > defending (Non-Emergency) 1211 o setup (Non-Emergency) <= defending (Emergency) 1213 If one wants to implement an emergency service based on Call Queueing, 1214 on "prioritized access to network layer resources", and ensure that 1215 "emergency" sessions can partially preempt regular sessions (ie 1216 reduce their reservation size), one could do that by signaling 1217 emergency calls: 1218 * using "Resource-Priority" Header in SIP 1219 * using Admission-Priority Policy Element in RSVP 1220 * using Preemption in Policy Element RSVP with: 1221 o setup (Emergency) > defending (Non-Emergency) 1222 o setup (Non-Emergency) <= defending (Emergency) 1223 * activate RFC4495 RSVP Bandwidth Reduction mechanisms 1225 Authors' Address 1227 Francois Le Faucheur 1228 Cisco Systems, Inc. 1229 Village d'Entreprise Green Side - Batiment T3 1230 400, Avenue de Roumanille 1231 06410 Biot Sophia-Antipolis 1232 France 1233 Email: flefauch@cisco.com 1235 James Polk 1236 Cisco Systems, Inc. 1237 2200 East President George Bush Turnpike 1238 Richardson, Texas 75082 1239 USA 1240 Email: jmpolk@cisco.com 1242 Ken Carlberg 1243 G11 1244 123a Versailles Circle 1245 Towson, MD. 21204 1246 USA 1247 email: carlberg@g11.org.uk 1249 Intellectual Property 1251 The IETF takes no position regarding the validity or scope of any 1252 Intellectual Property Rights or other rights that might be claimed to 1253 pertain to the implementation or use of the technology described in 1254 this document or the extent to which any license under such rights 1255 might or might not be available; nor does it represent that it has 1256 made any independent effort to identify any such rights. Information 1257 on the procedures with respect to rights in RFC documents can be 1258 found in BCP 78 and BCP 79. 1260 Copies of IPR disclosures made to the IETF Secretariat and any 1261 assurances of licenses to be made available, or the result of an 1262 attempt made to obtain a general license or permission for the use of 1263 such proprietary rights by implementers or users of this 1264 specification can be obtained from the IETF on-line IPR repository at 1265 http://www.ietf.org/ipr. 1267 The IETF invites any interested party to bring to its attention any 1268 copyrights, patents or patent applications, or other proprietary 1269 rights that may cover technology that may be required to implement 1270 this standard. Please address the information to the IETF at ietf- 1271 ipr@ietf.org. 1273 Full Copyright Statement 1275 Copyright (C) The IETF Trust (2007). 1277 This document is subject to the rights, licenses and restrictions 1278 contained in BCP 78, and except as set forth therein, the authors 1279 retain all their rights. 1281 This document and the information contained herein are provided on an 1282 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1283 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1284 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1285 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1286 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.