idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors 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 (February 9, 2009) is 5556 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: 'ITU.I.225' is mentioned on line 241, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 859, but not defined ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-15) exists of draft-ietf-dime-diameter-qos-07 == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-09 == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-07 == Outdated reference: A later version (-24) exists of draft-ietf-nsis-qspec-21 == Outdated reference: A later version (-09) exists of draft-ietf-sipping-sbc-funcs-08 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-rsvp-l3vpn-01 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-02 Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG F. Le Faucheur 3 Internet-Draft J. Polk 4 Intended status: Standards Track Cisco 5 Expires: August 13, 2009 K. Carlberg 6 G11 7 February 9, 2009 9 Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services 10 draft-ietf-tsvwg-emergency-rsvp-10.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 13, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. 47 Abstract 49 An Emergency Telecommunications Service (ETS) requires the ability to 50 provide an elevated probability of session establishment to an 51 authorized user in times of network congestion (typically, during a 52 crisis). When supported over the Internet Protocol suite, this may 53 be facilitated through a network layer admission control solution, 54 which supports prioritized access to resources (e.g., bandwidth). 55 These resources may be explicitly set aside for emergency services, 56 or they may be shared with other sessions. 58 This document specifies extensions to the Resource reSerVation 59 Protocol (RSVP) that can be used to support such an admission 60 priority capability at the network layer. Note that these extensions 61 represent one possible solution component in satisfying ETS 62 requirements. Other solution components, or other solutions, are 63 outside the scope of this document. 65 The mechanisms defined in this document are applicable to controlled 66 environments formed by either a single administrative domain or a set 67 of administrative domains that closely coordinate their network 68 policy and network design. The mechanisms defined in this document 69 can be used for a session whose path spans over such a controlled 70 environment in order to elevate the session establishment probability 71 through the controlled environment (thereby elevating the end to end 72 session establishment probability). 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 1.1. Related Technical Documents . . . . . . . . . . . . . . . 6 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 79 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 8 80 3. Overview of RSVP extensions and Operations . . . . . . . . . . 8 81 3.1. Operations of Admission Priority . . . . . . . . . . . . . 10 82 4. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 10 83 4.1. Admission Priority Policy Element . . . . . . . . . . . . 11 84 4.1.1. Admission Priority Merging Rules . . . . . . . . . . . 13 85 4.2. Application-Level Resource Priority Policy Element . . . . 13 86 4.2.1. Application-Level Resource Priority Modifying and 87 Merging Rules . . . . . . . . . . . . . . . . . . . . 15 88 4.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 15 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 17 91 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 17 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 20 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 97 Appendix A. Examples of Bandwidth Allocation Model for 98 Admission Priority . . . . . . . . . . . . . . . . . 23 99 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 24 100 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 28 101 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 31 102 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 34 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 105 1. Introduction 107 [RFC3689] and [RFC3690] detail requirements for an Emergency 108 Telecommunications Service (ETS), which is an umbrella term 109 identifying those networks and specific services used to support 110 emergency communications. An underlying goal of these documents is 111 to present requirements that elevate the probability of session 112 establishment from an authorized user in times of network congestion 113 (presumably because of a crisis condition). In some extreme cases, 114 the requirement for this probability may reach 100%, but that is a 115 topic subject to policy and most likely local regulation (the latter 116 being outside the scope of this document). 118 Solutions to meet this requirement for elevated session establishment 119 probability may involve session layer capabilities prioritizing 120 access to resources controlled by the session control function. As 121 an example, entities involved in session control (such as SIP user 122 agents, when the Session Initiation Protocol (SIP) [RFC3261], is the 123 session control protocol in use) can influence their treatment of 124 session establishment requests (such as SIP requests). This may 125 include the ability to "queue" session establishment requests when 126 those can not be immediately honored (in some cases with the notion 127 of "bumping", or "displacement", of less important session 128 establishment requests from that queue). It may include additional 129 mechanisms such as exemption from certain network management 130 controls, and alternate routing. 132 Solutions to meet the requirement for elevated session establishment 133 probability may also take advantage of network layer admission 134 control mechanisms supporting admission priority. Networks usually 135 have engineered capacity limits that characterize the maximum load 136 that can be handled (say, on any given link) for a class of traffic 137 while satisfying the quality of service requirements of that traffic 138 class. Admission priority may involve setting aside some network 139 resources (e.g. bandwidth) out of the engineered capacity limits for 140 the emergency services only. Or alternatively, it may involve 141 allowing the emergency related sessions to seize additional resources 142 beyond the engineered capacity limits applied to normal sessions. 143 This document specifies the necessary extensions to support such 144 admission priority when network layer admission control is performed 145 using the Resource reSerVation Protocol (RSVP) ([RFC2205]). 147 The mechanisms defined in this document are applicable to controlled 148 environments formed by either a single administrative domain or a set 149 of administrative domains that closely coordinate their network 150 policy and network design. The mechanisms defined in this document 151 can be used for a session whose path spans over such a controlled 152 environment in order to elevate the session establishment probability 153 through the controlled environment (thereby elevating the end to end 154 session establishment probability). Let us consider the end to end 155 environment illustrated in Figure 1 that comprises three separate 156 administrative domains, each with 2 endpoints and each with Session 157 Border Controller (SBC) elements ([I-D.ietf-sipping-sbc-funcs]) 158 handling session handover at the domain boundaries. 160 +----------+ +----------+ +----------+ 161 |Endpoint 1| |Endpoint 3| |Endpoint 5| 162 +----------+ +----------+ +----------+ 163 | | | 164 | | | 165 +----+ +----+ +----+ 166 |SBC | |SBC | |SBC | 167 ,| |--. ,-| |-. ,| |-. 168 ,' +----+ `. ,' +----+ ` . ,' +----+ \ 169 / ISP \ / ISP \ / ISP `. 170 / Domain +----+ +----+ Domain +----+ +----+ Domain \ 171 ( A |+----+ |+----+ B |+----+ |+----+ C ) 172 \(Controlled)||SBC |--||SBC |(Controlled)||SBC |--||SBC |(Controlled)/ 173 \ +| | +| | +| | +| | / 174 `. +----+ +----+ +----+ +----+ .' 175 '+----+--' `. +----+ .' '--+----+--' 176 | | '--| |--' | | 177 |SBC | |SBC | |SBC | 178 +----+ +----+ +----+ 179 | | | 180 | | | 181 +----------+ +----------+ +----------+ 182 |Endpoint 2| |Endpoint 4| |Endpoint 6| 183 +----------+ +----------+ +----------+ 185 Figure 1: Example End to End Environment 187 Each domain is operating as a separate controlled environment and may 188 deploy a given combination of network mechanisms and network policies 189 within the given domain. For example, ISP Domain A , ISP Domain B 190 and ISP Domain C may each deploy a different Differentiated Services 191 ([RFC2475]) policy in-between their own SBCs. As another example, 192 ISP Domain B may elect to deploy MPLS Traffic Engineering ([RFC2702]) 193 within its domain while ISP Domain A and C may not. Similarly, each 194 domain administrator can make its own decision about whether to 195 deploy network layer admission control within his domain. If one 196 domain elects to do so, this can be achieved using RSVP signaling 197 between the ingress and egress SBC elements of that domain (i.e., 198 RSVP signaling operates edge-to-edge and not end-to-end). With this 199 approach, network layer admission control may be deployed in one 200 domain regardless of whether it is deployed in the other domains on 201 the end to end path of sessions. Also, deploying network layer 202 admission control within one domain does not require any 203 collaboration or even pre-agreement with other domains since it 204 operates transparently from other domains (the only externally 205 visible impact might be on quality of service offered to the sessions 206 that transit through that domain). The mechanisms defined in this 207 document are applicable within a controlled environment that elects 208 to deploy network layer admission control using RSVP and handles 209 emergency communications. For example, ISP domain A and ISP domain C 210 may elect to use RSVP and the extensions defined in this document 211 within their respective domain while ISP domain B may not deploy 212 network layer admission control within his domain. In that case, a 213 session between Endpoint 1 and Endpoint 6 would benefit from network 214 layer admission control and resource reservation through domain A 215 network and domain C network. If that session is an emergency 216 session, the extensions defined in this document increase the 217 probability of admission of that particular session through domain A 218 and domain C, thereby increasing the end-to-end session establishment 219 probability. 221 As another example, all three domains shown in Figure 1 may elect to 222 deploy RSVP admission control and the extensions defined in this 223 document within their own domain. This would ensure that emergency 224 sessions are protected by resource reservation and elevated session 225 establishment probability through every domain on the end to end 226 path. But even in that case, RSVP signaling and the extensions 227 defined in this document need not operate end-to-end; rather they are 228 expected to operate edge-to-edge within each domain only (with RSVP 229 being terminated by the egress SBC on the egress edge of one domain 230 and regenerated by the ingress SBC on the ingress edge of the next 231 domain). 233 IP telephony "calls" are one form of "sessions" that can benefit from 234 the elevated session establishment probability discussed in this 235 document. Video over IP and Instant Messaging are other examples. 236 For the sake of generality, we use the term "session" throughout this 237 document to refer to any type of session. 239 1.1. Related Technical Documents 241 [RFC4542] is patterned after [ITU.I.225] and describes an example of 242 one type of prioritized network layer admission control procedure 243 that may be used for emergency services operating over an IP network 244 infrastructure. It discusses initial session set up, as well as 245 operations after session establishment through maintenance of a 246 continuing call model of the status of all sessions. [RFC4542] also 247 describes how these network layer admission control procedures can be 248 realized using the Resource reSerVation Protocol [RFC2205] along with 249 its associated protocol suite and extensions, including those for 250 policy based admission control ([RFC2753], [RFC2750]), for user 251 authentication and authorization ([RFC3182]) and for integrity and 252 authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter 253 QoS Application ([I-D.ietf-dime-diameter-qos]) allows network 254 elements to interact with Diameter servers when allocating QoS 255 resources in the network and thus, is also a possible method for 256 authentication and authorization of RSVP reservations in the context 257 of emergency services. 259 [RFC4542] describes how the RSVP Signaled Preemption Priority Policy 260 Element specified in [RFC3181] can be used to enforce the session 261 preemption that may be needed by some emergency services. In 262 contrast to [RFC4542], this document specifies new RSVP extensions to 263 increase the probability of session establishment without preemption. 264 Engineered capacity techniques in the form of bandwidth allocation 265 models are used to satisfy the "admission priority" required by an 266 RSVP capable ETS network. In particular this document specifies two 267 new RSVP Policy Elements allowing the admission priority to be 268 conveyed inside RSVP signaling messages so that RSVP nodes can 269 enforce selective bandwidth admission control decision based on the 270 session admission priority. Appendix A of this document also 271 provides examples of bandwidth allocation models which can be used by 272 RSVP-routers to enforce such admission priority on every link. 274 1.2. Terminology 276 This document assumes the terminology defined in [RFC2753]. For 277 convenience, the definition of a few key terms is repeated here: 279 o Policy Decision Point (PDP): The point where policy decisions are 280 made. 282 o Local Policy Decision Point (LPDP): PDP local to the network 283 element. 285 o Policy Enforcement Point (PEP): The point where the policy 286 decisions are actually enforced. 288 o Policy Ignorant Node (PIN): A network element that does not 289 explicitly support policy control using the mechanisms defined in 290 [RFC2753]. 292 2. Requirements Language 294 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 295 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 296 document are to be interpreted as described in RFC 2119 [RFC2119]. 298 3. Overview of RSVP extensions and Operations 300 Let us consider the case where a session requiring ETS type service 301 is to be established, and more specifically that the preference to be 302 granted to this session is in terms of network layer "admission 303 priority" (as opposed to preference granted through preemption of 304 existing sessions). By "admission priority" we mean allowing that 305 priority session to seize network layer resources from the engineered 306 capacity that have been set-aside and not made available to normal 307 sessions, or alternatively by allowing that session to seize 308 additional resources beyond the engineered capacity limits applied to 309 normal sessions. 311 As described in [RFC4542], the session establishment can be 312 conditioned to resource-based and policy-based network layer 313 admission control achieved via RSVP signaling. In the case where the 314 session control protocol is SIP, the use of RSVP-based admission 315 control by SIP is specified in [RFC3312]. 317 Devices involved in the session establishment are expected to be 318 aware of the application-level priority requirements of emergency 319 sessions. Again considering the case where the session control 320 protocol is SIP, the SIP user agents can be made aware of the 321 resource priority requirements in the case of an emergency session 322 using the Resource-Priority Header mechanism specified in [RFC4412]. 323 The end-devices involved in the upper-layer session establishment 324 simply need to copy the application-level resource priority 325 requirements (e.g. as communicated in SIP Resource-Priority Header) 326 inside the new RSVP Application-Level Resource-Priority Policy 327 Element defined in this document. 329 Conveying the application-level resource priority requirements inside 330 the RSVP message allows this application level requirement to be 331 mapped/remapped into a different RSVP "admission priority" at every 332 administrative domain boundary based on the policy applicable in that 333 domain. In a typical model (see [RFC2753]) where PDPs control PEPs 334 at the periphery of the policy domain (e.g., in border routers), PDPs 335 would interpret the RSVP Application-Level Resource-Priority Policy 336 Element and map the requirement of the emergency session into an RSVP 337 "admission priority" level. Then, PDPs would convey this information 338 inside the new Admission Priority Policy Element defined in this 339 document. This way, the RSVP admission priority can be communicated 340 to downstream PEPs (i.e. RSVP Routers) of the same policy domain, 341 which have LPDPs but no controlling PDP. In turn, this means the 342 necessary RSVP Admission priority can be enforced at every RSVP hop, 343 including all the (many) hops which do not have any understanding of 344 Application-Level Resource-Priority semantics. 346 As an example of operation across multiple administrative domains, a 347 first domain might decide to provide network layer admission priority 348 to sessions of a given Application Level Resource Priority and map it 349 into a high RSVP admission control priority inside the Admission 350 Priority Policy Element; while a second domain may decide to not 351 provide admission priority to sessions of this same Application Level 352 Resource Priority and hence map it into a low RSVP admission control 353 priority. 355 As another example of operation across multiple administrative 356 domains, we can consider the case where the resource priority header 357 enumerates several namespaces, as explicitly allowed by [RFC4412], 358 for support of scenarios where sessions traverse multiple 359 administrative domains using different namespace. In that case, the 360 relevant namespace can be used at each domain boundary to map into an 361 RSVP Admission priority for that domain. It is not expected that the 362 RSVP Application-Level Resource-Priority Header Policy Element would 363 be taken into account at RSVP-hops within a given administrative 364 domain. It is expected to be used at administrative domain 365 boundaries only in order to set/reset the RSVP Admission Priority 366 Policy Element. 368 The existence of pre-established inter-domain policy agreements or 369 Service Level Agreements may avoid the need to take real-time action 370 at administrative domain boundaries for mapping/remapping of 371 admission priorities. 373 Mapping/remapping by PDPs may also be applied to boundaries between 374 various signaling protocols, such as those advanced by the NSIS 375 working group. 377 As can be observed, the framework described above for mapping/ 378 remapping application level resource priority requirements into an 379 RSVP admission priority can also be used together with [RFC3181] for 380 mapping/remapping application level resource priority requirements 381 into an RSVP preemption priority (when preemption is indeed needed). 382 In that case, when processing the RSVP Application-Level Resource- 383 Priority Policy Element, the PDPs at boundaries between 384 administrative domains (or between various QoS signaling protocols) 385 can map it into an RSVP "preemption priority" information. This 386 Preemption priority information comprises a setup preemption level 387 and a defending preemption priority level. This preemption priority 388 information can then be encoded inside the Preemption Priority Policy 389 Element of [RFC3181] and thus, can be taken into account at every 390 RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides 391 examples of various hypothetical policies for emergency session 392 handling, some of them involving admission priority, some of them 393 involving both admission priority and preemption priority. Appendix 394 B also identifies how the Application-Level Resource Priority need to 395 be mapped into RSVP policy elements by the PDPs to realize these 396 policies. 398 3.1. Operations of Admission Priority 400 The RSVP Admission Priority policy element defined in this document 401 allows admission bandwidth to be allocated preferentially to an 402 authorized priority service. Multiple models of bandwidth allocation 403 MAY be used to that end. 405 A number of bandwidth allocation models have been defined in the IETF 406 for allocation of bandwidth across different classes of traffic 407 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 408 Those include the Maximum Allocation Model (MAM) defined in 409 [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and 410 the Maximum Allocation model with Reservation (MAR) defined in 411 [RFC4126]. These same models MAY however be applied for allocation 412 of bandwidth across different levels of admission priority as defined 413 in this document. Appendix A provides an illustration of how these 414 bandwidth allocation models can be applied for such purposes and 415 introduces an additional bandwidth allocation model that we term the 416 Priority Bypass Model (PrBM). It is important to note that the 417 models described and illustrated in Appendix A are only informative 418 and do not represent a recommended course of action. 420 We can see in these examples, that the RSVP Admission Priority may 421 effectively influence the fundamental admission control decision of 422 RSVP (for example by determining which bandwidth pool is to be used 423 by RSVP for performing its fundamental bandwidth allocation). In 424 that sense, we observe that the policy control and admission control 425 are not separate logics but instead somewhat blended. 427 4. New Policy Elements 429 The Framework document for policy-based admission control [RFC2753] 430 describes the various components that participate in policy decision 431 making (i.e., PDP, PEP and LPDP). 433 As described in section 2 of the present document, the Application- 434 Level Resource Priority Policy Element and the Admission Priority 435 Policy Element serve different roles in this framework: 437 o the Application-Level Resource Priority Policy Element conveys 438 application level information and is processed by PDPs 440 o the emphasis of Admission Priority Policy Element is to be simple, 441 stateless, and light-weight such that it can be processed 442 internally within a node's LPDP. It can then be enforced 443 internally within a node's PEP. It is set by PDPs based on 444 processing of the Application-Level Resource Priority Policy 445 Element. 447 [RFC2750] defines extensions for supporting generic policy based 448 admission control in RSVP. These extensions include the standard 449 format of POLICY_DATA objects and a description of RSVP handling of 450 policy events. 452 The POLICY_DATA object contains one or more of Policy Elements, each 453 representing a different (and perhaps orthogonal) policy. As an 454 example, [RFC3181] specifies the Preemption Priority Policy Element. 455 This document defines two new Policy Elements called: 457 o the Admission Priority Policy Element 459 o the Application-Level Resource Priority Policy Element 461 4.1. Admission Priority Policy Element 463 The format of the Admission Priority policy element is as shown in 464 Figure 2: 466 0 0 0 1 1 2 2 3 467 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 468 +-------------+-------------+-------------+-------------+ 469 | Length | P-Type = ADMISSION_PRI | 470 +-------------+-------------+-------------+-------------+ 471 | Flags | M. Strategy | Error Code | Reserved | 472 +-------------+-------------+-------------+-------------+ 473 | Reserved |Adm. Priority| 474 +---------------------------+---------------------------+ 476 Figure 2: Admission Priority Policy Element 478 where: 480 o Length: 16 bits 482 * Always 12. The overall length of the policy element, in bytes. 484 o P-Type: 16 bits 486 * ADMISSION_PRI = To be allocated by IANA (see "IANA 487 Considerations" section) 489 o Flags: Reserved 491 * SHALL be set to zero on transmit and SHALL be ignored on 492 reception 494 o Merge Strategy: 8 bits (only applicable to multicast flows) 496 * values are defined by corresponding registry maintained by IANA 497 (see "IANA Considerations" section) 499 o Error code: 8 bits (only applicable to multicast flows) 501 * values are defined by corresponding registry maintained by IANA 502 (see "IANA Considerations" section) 504 o Reserved: 8 bits 506 * SHALL be set to zero on transmit and SHALL be ignored on 507 reception 509 o Reserved: 24 bits 511 * SHALL be set to zero on transmit and SHALL be ignored on 512 reception 514 o Adm. Priority (Admission Priority): 8 bits (unsigned) 516 * The admission control priority of the flow, in terms of access 517 to network bandwidth in order to provide higher probability of 518 session completion to selected flows. Higher values represent 519 higher Priority. A given Admission Priority is encoded in this 520 information element using the same value as when encoded in the 521 "Admission Priority" field of the "Admission Priority" 522 parameter defined in [I-D.ietf-nsis-qspec], or in the 523 "Admission Priority" parameter defined in 524 [I-D.ietf-dime-qos-parameters]. In other words, a given value 525 inside the Admission Priority information element defined in 526 the present document, inside the [I-D.ietf-nsis-qspec] 527 Admission Priority field or inside the 529 [I-D.ietf-dime-qos-parameters] Admission Priority parameter, 530 refers to the same admission priority. Bandwidth allocation 531 models such as those described in Appendix A are to be used by 532 the RSVP router to achieve such increased probability of 533 session establishment. The admission priority value 534 effectively indicates which bandwidth constraint(s) of the 535 bandwidth constraint model in use is(are) applicable to 536 admission of this RSVP reservation. 538 Note that the Admission Priority Policy Element does NOT indicate 539 that this RSVP reservation is to preempt any other RSVP reservation. 540 If a priority session justifies both admission priority and 541 preemption priority, the corresponding RSVP reservation needs to 542 carry both an Admission Priority Policy Element and a Preemption 543 Priority Policy Element. The Admission Priority and Preemption 544 Priority are handled by LPDPs and PEPs as separate mechanisms. They 545 can be used one without the other, or they can be used both in 546 combination. 548 4.1.1. Admission Priority Merging Rules 550 This section discusses alternatives for dealing with RSVP admission 551 priority in case of merging of reservations. As merging is only 552 applicable to multicast, this section also only applies to multicast 553 sessions. 555 The rules for merging Admission Priority Policy Elements are defined 556 by the value encoded inside the Merge Strategy field in accordance 557 with the corresponding IANA registry. The merge strategies (and 558 associated values) defined by the present document are the same as 559 those defined in [RFC3181] for merging Preemption Priority Policy 560 Elements (see "IANA Considerations" section). 562 The only difference with [RFC3181] is that this document does not 563 recommend any merge strategies for Admission Priority, while 564 [RFC3181] recommends the first of these merge strategies for 565 Preemption Priority. Note that with the Admission Priority (as is 566 the case with the Preemption Priority), "Take highest priority" 567 translates into "take the highest numerical value". 569 4.2. Application-Level Resource Priority Policy Element 571 The format of the Application-Level Resource Priority policy element 572 is as shown in Figure 3: 574 0 0 0 1 1 2 2 3 575 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 576 +-------------+-------------+-------------+-------------+ 577 | Length | P-Type = APP_RESOURCE_PRI | 578 +-------------+-------------+-------------+-------------+ 579 // ALRP List // 580 +---------------------------+---------------------------+ 582 Figure 3: Application-Level Resource Priority Policy Element 584 where: 586 o Length: 588 * The length of the policy element (including the Length and 589 P-Type) is in number of octets (MUST be a multiple of 4) and 590 indicates the end of the ALRP list. 592 o P-Type: 16 bits 594 * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA 595 Considerations" section) 597 o ALRP List: 599 * List of ALRP where each ALRP is encoded as shown in Figure 4. 601 ALRP: 602 0 0 0 1 1 2 2 3 603 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 604 +---------------------------+-------------+-------------+ 605 | ALRP Namespace | Reserved |ALRP Priority| 606 +---------------------------+---------------------------+ 608 Figure 4: Application-Level Resource Priority 610 where: 612 o ALRP Namespace (Application-Level Resource Priority Namespace): 16 613 bits (unsigned) 615 * Contains a numerical value identifying the namespace of the 616 application-level resource priority. This value is encoded as 617 per the "Resource-Priority Namespaces" IANA registry. (See 618 IANA Considerations section for the request to IANA to extend 619 the registry to include this numerical value). 621 o Reserved: 8 bits 623 * SHALL be set to zero on transmit and SHALL be ignored on 624 reception. 626 o ALRP Priority: (Application-Level Resource Priority Priority): 8 627 bits (unsigned) 629 * Contains the priority value within the namespace of the 630 application-level resource priority. This value is encoded as 631 per the "Resource-Priority Priority-Value" IANA registry. (See 632 IANA Considerations section for the request to IANA to extend 633 the registry to include this numerical value). 635 4.2.1. Application-Level Resource Priority Modifying and Merging Rules 637 When POLICY_DATA objects are protected by integrity, LPDPs should not 638 attempt to modify them. They MUST be forwarded as-is to ensure their 639 security envelope is not invalidated. 641 In case of multicast, when POLICY_DATA objects are not protected by 642 integrity, LPDPs MAY merge incoming Application-Level Resource 643 Priority elements to reduce their size and number. When they do 644 merge those, LPDPs MUST do so according to the following rule: 646 o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 647 all the ALRPs appearing in the ALRP List of an incoming 648 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 649 once. In other words, the outgoing ALRP List is the union of the 650 incoming ALRP Lists that are merged. 652 As merging is only applicable to Multicast, this rule only applies to 653 Multicast sessions. 655 4.3. Default Handling 657 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 658 (PINs) implement a default handling of POLICY_DATA objects ensuring 659 that those objects can traverse PIN nodes in transit from one PEP to 660 another. This applies to the situations where POLICY_DATA objects 661 contain the Admission Priority Policy Element and the ALRP Policy 662 Element specified in this document, so that those can traverse PIN 663 nodes. 665 Section 4.2 of [RFC2750] also defines a similar default behavior for 666 policy-capable nodes that do not recognized a particular Policy 667 Element. This applies to the Admission Priority Policy Element and 668 the ALRP Policy Element specified in this document, so that those can 669 traverse policy-capable nodes that do not support this document. 671 5. Security Considerations 673 As this document defines extensions to RSVP, the security 674 considerations of RSVP apply. Those are discussed in [RFC2205], 675 [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 677 A subset of RSVP messages are signaled with the Router Alert Option 678 (RAO)([RFC2113],[RFC2711]). However, some network administrators 679 activate mechanisms at the edge of their administrative domain to 680 protect against potential Denial Of Service (DOS) attacks associated 681 with RAO. This may include hiding of the RAO to downstream interior 682 routers in the domain (as recommended by default over an MPLS network 683 in [I-D.dasmith-mpls-ip-options]) or complete blocking of packets 684 received with RAO at the administrative boundary. As the mechanisms 685 defined in this document rely on RSVP, their usage assume that such 686 protection against RAO packets are not activated in a way that 687 prevents RSVP processing on relevant interfaces or routers of the 688 controlled environments electing to deploy these mechanisms. 689 Nonetheless, it is recommended that protection mechanisms be 690 activated against potential DOS attacks through RAO even when RAO 691 message are processed. This may include rate limiting of incoming 692 RAO packets (e.g. at interface and/or router level). This may also 693 include deploying an RSVP architecture whereby interior routers are 694 not exposed to any RSVP messages associated with end to end 695 reservations (such as the architecture defined in 696 [I-D.ietf-tsvwg-rsvp-l3vpn]). We observe that the risks and security 697 measures associated with processing of RAO messages at an 698 administrative domain edge are fundamentally similar to those 699 involved with other forms of control plane interactions allowed at 700 administrative domain edges, such as routing or multicast routing 701 interactions allowed between a customer and his Internet Service 702 Provider, MPLS VPN ( [RFC4364] Service Provider , [RFC4659]) or MPLS 703 MVPN ([I-D.ietf-l3vpn-2547bis-mcast]) Service Provider. 705 The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in 706 this document are signaled by RSVP through encapsulation in a Policy 707 Data object as defined in [RFC2750]. Therefore, like any other 708 Policy Elements, their integrity can be protected as discussed in 709 section 6 of [RFC2750] by two optional security mechanisms. The 710 first mechanism relies on RSVP Authentication as specified in 711 [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP 712 nodes are policy capable. With this mechanism, the INTEGRITY object 713 is carried inside RSVP messages. The second mechanism relies on the 714 INTEGRITY object within the POLICY_DATA object to guarantee integrity 715 between RSVP Policy Enforcement Points (PEPs) that are not RSVP 716 neighbors. 718 5.1. Use of RSVP Authentication between RSVP neighbors 720 This mechanism can be used between RSVP neighbors that are policy 721 capable. The RSVP neighbors use shared keys to compute the 722 cryptographic signature of the RSVP message. 723 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key 724 provisioning methods as well as their respective applicability. 726 5.2. Use of INTEGRITY object within the POLICY_DATA object 728 The INTEGRITY object within the POLICY_DATA object can be used to 729 guarantee integrity between non-neighboring RSVP PEPs. 731 Details for computation of the content of the INTEGRITY object can be 732 found in Appendix B of [RFC2750]. This states that the Policy 733 Decision Point (PDP), at its discretion, and based on destination 734 PEP/PDP or other criteria, selects an Authentication Key and the hash 735 algorithm to be used. Keys to be used between PDPs can be 736 distributed manually or via standard key management protocol for 737 secure key distribution. 739 Note that where non-RSVP hops may exist in between RSVP hops, as well 740 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 741 between PEPs, it may be difficult for the PDP to determine what is 742 the destination PDP for a POLICY_DATA object contained in some RSVP 743 messages (such as a Path message). This is because in those cases 744 the next PEP is not known at the time of forwarding the message. In 745 this situation, key shared across multiple PDPs may be used. This is 746 conceptually similar to the use of key shared across multiple RSVP 747 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 748 We observe also that this issue may not exist in some deployment 749 scenarios where a single (or low number of) PDP is used to control 750 all the PEPs of a region (such as an administrative domain). In such 751 scenarios, it may be easy for a PDP to determine what is the next hop 752 PDP, even when the next hop PEP is not known, simply by determining 753 what is the next region that will be traversed (say based on the 754 destination address). 756 6. IANA Considerations 758 As specified in [RFC2750], Standard RSVP Policy Elements (P-type 759 values) are to be assigned by IANA as per "IETF Consensus" policy 760 following the policies outlined in [RFC2434] (this policy is now 761 called "IETF Review" as per [RFC5226]) . 763 IANA needs to allocate two P-Types from the Standard RSVP Policy 764 Element range: 766 o one P-Type to the Admission Priority Policy Element 768 o one P-Type to the Application-Level Resource Priority Policy 769 Element. 771 In section 3.1, the present document defines a Merge Strategy field 772 inside the Admission Priority policy element. IANA needs to create a 773 registry for this field and allocate the following values: 775 o 1: Take priority of highest QoS 777 o 2: Take highest priority 779 o 3: Force Error on heterogeneous merge 781 Following the policies outlined in [RFC5226], numbers in the range 782 4-127 are allocated according to the "IETF Review" policy, numbers in 783 the range 128-240 as "First Come First Served" and numbers between 784 241-255 are reserved for "Private Use". Value 0 is Reserved (for 785 consistency with [RFC3181] Merge Strategy values). 787 In section 3.1, the present document defines an Error Code field 788 inside the Admission Priority policy element. IANA needs to create a 789 registry for this field and allocate the following values: 791 o 0: NO_ERROR Value used for regular ADMISSION_PRI elements 793 o 2: HETEROGENEOUS This element encountered heterogeneous merge 795 Following the policies outlined in [RFC5226], numbers in the range 796 3-127 are allocated according to the "IETF Review" policy, numbers in 797 the range 128-240 as "First Come First Served" and numbers between 798 241-255 are reserved for "Private Use". Value 1 is Reserved (for 799 consistency with [RFC3181] Error Code values). 801 The present document defines an ALRP Namespace field in section 3.2 802 that contains a numerical value identifying the namespace of the 803 application-level resource priority. The IANA already maintains the 804 Resource-Priority Namespaces registry (under the SIP Parameters) 805 listing all such namespace. However, that registry does not 806 currently allocate a numerical value to each namespace. Hence, this 807 document requests the IANA to extend the Resource-Priority Namespace 808 registry in the following ways: 810 o a new column should be added to the registry 812 o the title of the new column should be "Namespace Numerical Value 813 *" 815 o in the Legend, add a line saying "Namespace Numerical Value = the 816 unique numerical value identifying the namespace" 818 o add a line at the bottom of the registry stating the following "* 819 : [RFCXXX] " where XXX is the RFC number of the present document 821 o allocate an actual numerical value to each namespace in the 822 registry and state that value in the new "Namespace numerical 823 Value *" column. 825 A numerical value should be allocated immediately by IANA to all 826 existing namespace. Then, in the future, IANA should automatically 827 allocate a numerical value to any new namespace added to the 828 registry. 830 The present document defines an ALRP Priority field in section 3.2 831 that contains a numerical value identifying the actual application- 832 level resource priority within the application-level resource 833 priority namespace. The IANA already maintains the Resource-Priority 834 Priority-values registry (under the SIP Parameters) listing all such 835 priorities. However, that registry does not currently allocate a 836 numerical value to each priority-value. Hence, this document 837 requests the IANA to extend the Resource-Priority Priority-Values 838 registry in the following ways: 840 o for each namespace, the registry should be structured with two 841 columns 843 o the title of the first column should read "Priority Values (least 844 to greatest)" 846 o the first column should list all the values currently defined in 847 the registry (e.g. for the drsn namespace: "routine", "priority", 848 "immediate", "flash", "flash-override", "flash-override-override" 849 for the drsn namespace) 851 o the title of the second column should read "Priority Numerical 852 Value *" 854 o At the bottom of the registry, add a "Legend" with a line saying 855 "Priority Numerical Value = the unique numerical value identifying 856 the priority within a namespace" 858 o add a line at the bottom of the registry stating the following "* 859 : [RFCXXX] " where XXX is the RFC number of the present document 861 o allocate an actual numerical value to each and state that value in 862 the new "Priority Numerical Value *" column. 864 A numerical value should be allocated immediately by IANA to all 865 existing priority. Then, in the future, IANA should automatically 866 allocate a numerical value to any new namespace added to the 867 registry. The numerical value must be unique within each namespace. 868 For the initial allocation, within each namespace, values should be 869 allocated in decreasing order ending with 0 (so that the greatest 870 priority is always allocated value 0). For example, in the drsn 871 namespace, "routine" would be allocated numerical value 5 and "flash- 872 override-override" would be allocated numerical value 0. 874 7. Acknowledgments 876 We would like to thank An Nguyen for his encouragement to address 877 this topic and ongoing comments. Also, this document borrows heavily 878 from some of the work of S. Herzog on Preemption Priority Policy 879 Element [RFC3181]. Dave Oran and Janet Gunn provided useful input 880 into this document. Thanks to Magnus Westerlund, Cullen Jennings and 881 Ross Callon for helping clarify applicability of the mechanisms 882 defined in this document. 884 8. References 886 8.1. Normative References 888 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 889 February 1997. 891 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 892 Requirement Levels", BCP 14, RFC 2119, March 1997. 894 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 895 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 896 Functional Specification", RFC 2205, September 1997. 898 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 899 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 900 October 1998. 902 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 903 RFC 2711, October 1999. 905 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 906 Authentication", RFC 2747, January 2000. 908 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 909 RFC 2750, January 2000. 911 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 912 Authentication -- Updated Message Type Value", RFC 3097, 913 April 2001. 915 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 916 RFC 3181, October 2001. 918 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 919 A., Peterson, J., Sparks, R., Handley, M., and E. 920 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 921 June 2002. 923 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 924 Priority for the Session Initiation Protocol (SIP)", 925 RFC 4412, February 2006. 927 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 928 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 929 May 2008. 931 8.2. Informative References 933 [I-D.dasmith-mpls-ip-options] 934 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 935 "Requirements for Label Edge Router Forwarding of IPv4 936 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 937 progress), October 2008. 939 [I-D.ietf-dime-diameter-qos] 940 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 941 and G. Zorn, "Diameter Quality of Service Application", 942 draft-ietf-dime-diameter-qos-07 (work in progress), 943 December 2008. 945 [I-D.ietf-dime-qos-parameters] 946 Korhonen, J., Tschofenig, H., and E. Davies, "Quality of 947 Service Parameters for Usage with Diameter", 948 draft-ietf-dime-qos-parameters-09 (work in progress), 949 January 2009. 951 [I-D.ietf-l3vpn-2547bis-mcast] 952 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 953 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 954 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work 955 in progress), July 2008. 957 [I-D.ietf-nsis-qspec] 958 Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC 959 Template", draft-ietf-nsis-qspec-21 (work in progress), 960 November 2008. 962 [I-D.ietf-sipping-sbc-funcs] 963 Hautakorpi, J., Camarillo, G., Penfield, B., Hawrylyshen, 964 A., and M. Bhatia, "Requirements from SIP (Session 965 Initiation Protocol) Session Border Control Deployments", 966 draft-ietf-sipping-sbc-funcs-08 (work in progress), 967 January 2009. 969 [I-D.ietf-tsvwg-rsvp-l3vpn] 970 Davie, B., Faucheur, F., and A. Narayanan, "Support for 971 RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-01 972 (work in progress), November 2008. 974 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 975 Behringer, M. and F. Faucheur, "Applicability of Keying 976 Methods for RSVP Security", 977 draft-ietf-tsvwg-rsvp-security-groupkeying-02 (work in 978 progress), November 2008. 980 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 981 and W. Weiss, "An Architecture for Differentiated 982 Services", RFC 2475, December 1998. 984 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 985 McManus, "Requirements for Traffic Engineering Over MPLS", 986 RFC 2702, September 1999. 988 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 989 for Policy-based Admission Control", RFC 2753, 990 January 2000. 992 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 993 Herzog, S., and R. Hess, "Identity Representation for 994 RSVP", RFC 3182, October 2001. 996 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 997 "Integration of Resource Management and Session Initiation 998 Protocol (SIP)", RFC 3312, October 2002. 1000 [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for 1001 Emergency Telecommunication Service (ETS)", RFC 3689, 1002 February 2004. 1004 [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 1005 for Emergency Telecommunication Service (ETS)", RFC 3690, 1006 February 2004. 1008 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 1009 Constraints Model for Diffserv-aware MPLS Traffic 1010 Engineering", RFC 4125, June 2005. 1012 [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth 1013 Constraints Model for Diffserv-aware MPLS Traffic 1014 Engineering & Performance Comparisons", RFC 4126, 1015 June 2005. 1017 [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints 1018 Model for Diffserv-aware MPLS Traffic Engineering", 1019 RFC 4127, June 2005. 1021 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 1022 Properties", RFC 4230, December 2005. 1024 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 1025 Networks (VPNs)", RFC 4364, February 2006. 1027 [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency 1028 Telecommunications Service (ETS) for Real-Time Services in 1029 the Internet Protocol Suite", RFC 4542, May 2006. 1031 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 1032 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 1033 IPv6 VPN", RFC 4659, September 2006. 1035 Appendix A. Examples of Bandwidth Allocation Model for Admission 1036 Priority 1038 Sections A.1 and A.2 respectively illustrate how the Maximum 1039 Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) 1040 ([RFC4127]) can be used for support of admission priority. The 1041 Maximum Allocation model with Reservation (MAR) ([RFC4126]) could 1042 also be used in a similar manner for support of admission priority. 1043 Section A.3 illustrates how a simple "Priority Bypass Model" can also 1044 be used for support of admission priority. 1046 For simplicity, operations with only a single "priority" level 1047 (beyond non-priority) are illustrated here; However, the reader will 1048 appreciate that operations with multiple priority levels can easily 1049 be supported with these models. 1051 In all the figures below: 1053 x represents a non-priority session 1055 o represents a priority session 1057 A.1. Admission Priority with Maximum Allocation Model (MAM) 1059 This section illustrates operations of admission priority when a 1060 Maximum Allocation Model (MAM) is used for bandwidth allocation 1061 across non-priority traffic and priority traffic. A property of the 1062 Maximum Allocation Model is that priority traffic can not use more 1063 than the bandwidth made available to priority traffic (even if the 1064 non-priority traffic is not using all of the bandwidth available for 1065 it). 1067 ----------------------- 1068 ^ ^ ^ | | ^ 1069 . . . | | . 1070 Total . . . | | . Bandwidth 1071 (1)(2)(3) | | . Available 1072 Engi- . . . | | . for non-priority use 1073 neered .or.or. | | . 1074 . . . | | . 1075 Capacity. . . | | . 1076 v . . | | v 1077 . . |--------------| --- 1078 v . | | ^ 1079 . | | . Bandwidth available for 1080 v | | v priority use 1081 ------------------------- 1083 Figure 5: MAM Bandwidth Allocation 1085 Figure 5 shows a link within a routed network conforming to this 1086 document. On this link are two amounts of bandwidth available to two 1087 types of traffic: non-priority and priority. 1089 If the non-priority traffic load reaches the maximum bandwidth 1090 available for non-priority, no additional non-priority sessions can 1091 be accepted even if the bandwidth reserved for priority traffic is 1092 not currently fully utilized. 1094 With the Maximum Allocation Model, in the case where the priority 1095 load reaches the maximum bandwidth reserved for priority sessions, no 1096 additional priority sessions can be accepted. 1098 As illustrated in Figure 5, an operator may map the MAM model onto 1099 the Engineered Capacity limits according to different policies. At 1100 one extreme, where the proportion of priority traffic is reliably 1101 known to be fairly small at all times and where there may be some 1102 safety margin factored in the engineered capacity limits, the 1103 operator may decide to configure the bandwidth available for non- 1104 priority use to the full engineered capacity limits; effectively 1105 allowing the priority traffic to ride within the safety margin of 1106 this engineered capacity. This policy can be seen as an economically 1107 attractive approach as all of the engineered capacity is made 1108 available to non-priority sessions. This policy is illustrated as 1109 (1) in Figure 5. As an example, if the engineered capacity limit on 1110 a given link is X, the operator may configure the bandwidth available 1111 to non-priority traffic to X, and the bandwidth available to priority 1112 traffic to 5% of X. At the other extreme, where the proportion of 1113 priority traffic may be significant at times and the engineered 1114 capacity limits are very tight, the operator may decide to configure 1115 the bandwidth available to non-priority traffic and the bandwidth 1116 available to priority traffic such that their sum is equal to the 1117 engineered capacity limits. This guarantees that the total load 1118 across non-priority and priority traffic is always below the 1119 engineered capacity and, in turn, guarantees there will never be any 1120 QoS degradation. However, this policy is less attractive 1121 economically as it prevents non-priority sessions from using the full 1122 engineered capacity, even when there is no or little priority load, 1123 which is the majority of time. This policy is illustrated as (3) in 1124 Figure 5. As an example, if the engineered capacity limit on a given 1125 link is X, the operator may configure the bandwidth available to non- 1126 priority traffic to 95% of X, and the bandwidth available to priority 1127 traffic to 5% of X. Of course, an operator may also strike a balance 1128 anywhere in between these two approaches. This policy is illustrated 1129 as (2) in Figure 5. 1131 Figure 6 shows some of the non-priority capacity of this link being 1132 used. 1134 ----------------------- 1135 ^ ^ ^ | | ^ 1136 . . . | | . 1137 Total . . . | | . Bandwidth 1138 . . . | | . Available 1139 Engi- . . . | | . for non-priority use 1140 neered .or.or. |xxxxxxxxxxxxxx| . 1141 . . . |xxxxxxxxxxxxxx| . 1142 Capacity. . . |xxxxxxxxxxxxxx| . 1143 v . . |xxxxxxxxxxxxxx| v 1144 . . |--------------| --- 1145 v . | | ^ 1146 . | | . Bandwidth available for 1147 v | | v priority use 1148 ------------------------- 1150 Figure 6: Partial load of non-priority calls 1152 Figure 7 shows the same amount of non-priority load being used at 1153 this link, and a small amount of priority bandwidth being used. 1155 ----------------------- 1156 ^ ^ ^ | | ^ 1157 . . . | | . 1158 Total . . . | | . Bandwidth 1159 . . . | | . Available 1160 Engi- . . . | | . for non-priority use 1161 neered .or.or. |xxxxxxxxxxxxxx| . 1162 . . . |xxxxxxxxxxxxxx| . 1163 Capacity. . . |xxxxxxxxxxxxxx| . 1164 v . . |xxxxxxxxxxxxxx| v 1165 . . |--------------| --- 1166 v . | | ^ 1167 . | | . Bandwidth available for 1168 v |oooooooooooooo| v priority use 1169 ------------------------- 1171 Figure 7: Partial load of non-priority calls & partial load of 1172 priority calls Calls 1174 Figure 8 shows the case where non-priority load equates or exceeds 1175 the maximum bandwidth available to non-priority traffic. Note that 1176 additional non-priority sessions would be rejected even if the 1177 bandwidth reserved for priority sessions is not fully utilized. 1179 ----------------------- 1180 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1181 . . . |xxxxxxxxxxxxxx| . 1182 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1183 . . . |xxxxxxxxxxxxxx| . Available 1184 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1185 neered .or.or. |xxxxxxxxxxxxxx| . 1186 . . . |xxxxxxxxxxxxxx| . 1187 Capacity. . . |xxxxxxxxxxxxxx| . 1188 v . . |xxxxxxxxxxxxxx| v 1189 . . |--------------| --- 1190 v . | | ^ 1191 . | | . Bandwidth available for 1192 v |oooooooooooooo| v priority use 1193 ------------------------- 1195 Figure 8: Full non-priority load & partial load of priority calls 1197 Figure 9 shows the case where the priority traffic equates or exceeds 1198 the bandwidth reserved for such priority traffic. 1200 In that case additional priority sessions could not be accepted. 1201 Note that this does not mean that such sessions are dropped 1202 altogether: they may be handled by mechanisms, which are beyond the 1203 scope of this particular document (such as establishment through 1204 preemption of existing non-priority sessions, or such as queuing of 1205 new priority session requests until capacity becomes available again 1206 for priority traffic). 1208 ----------------------- 1209 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1210 . . . |xxxxxxxxxxxxxx| . 1211 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1212 . . . |xxxxxxxxxxxxxx| . Available 1213 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1214 neered .or.or. |xxxxxxxxxxxxxx| . 1215 . . . |xxxxxxxxxxxxxx| . 1216 Capacity. . . | | . 1217 v . . | | v 1218 . . |--------------| --- 1219 v . |oooooooooooooo| ^ 1220 . |oooooooooooooo| . Bandwidth available for 1221 v |oooooooooooooo| v priority use 1222 ------------------------- 1224 Figure 9: Partial non-priority load & Full priority load 1226 A.2. Admission Priority with Russian Dolls Model (RDM) 1228 This section illustrates operations of admission priority when a 1229 Russian Dolls Model (RDM) is used for bandwidth allocation across 1230 non-priority traffic and priority traffic. A property of the Russian 1231 Dolls Model is that priority traffic can use the bandwidth which is 1232 not currently used by non-priority traffic. 1234 As with the MAM model, an operator may map the RDM model onto the 1235 Engineered Capacity limits according to different policies. The 1236 operator may decide to configure the bandwidth available for non- 1237 priority use to the full engineered capacity limits; As an example, 1238 if the engineered capacity limit on a given link is X, the operator 1239 may configure the bandwidth available to non-priority traffic to X, 1240 and the bandwidth available to non-priority and priority traffic to 1241 105% of X. 1243 Alternatively, the operator may decide to configure the bandwidth 1244 available to non-priority and priority traffic to the engineered 1245 capacity limits; As an example, if the engineered capacity limit on a 1246 given link is X, the operator may configure the bandwidth available 1247 to non-priority traffic to 95% of X, and the bandwidth available to 1248 non-priority and priority traffic to X. 1250 Finally, the operator may decide to strike a balance in between. The 1251 considerations presented for these policies in the previous section 1252 in the MAM context are equally applicable to RDM. 1254 Figure 10 shows the case where only some of the bandwidth available 1255 to non-priority traffic is being used and a small amount of priority 1256 traffic is in place. In that situation both new non-priority 1257 sessions and new priority sessions would be accepted. 1259 -------------------------------------- 1260 |xxxxxxxxxxxxxx| . ^ 1261 |xxxxxxxxxxxxxx| . Bandwidth . 1262 |xxxxxxxxxxxxxx| . Available for . 1263 |xxxxxxxxxxxxxx| . non-priority . 1264 |xxxxxxxxxxxxxx| . use . 1265 |xxxxxxxxxxxxxx| . . Bandwidth 1266 | | . . available for 1267 | | v . non-priority 1268 |--------------| --- . and priority 1269 | | . use 1270 | | . 1271 |oooooooooooooo| v 1272 --------------------------------------- 1274 Figure 10: Partial non-priority load & Partial Aggregate load 1276 Figure 11 shows the case where all of the bandwidth available to non- 1277 priority traffic is being used and a small amount of priority traffic 1278 is in place. In that situation new priority sessions would be 1279 accepted but new non-priority sessions would be rejected. 1281 -------------------------------------- 1282 |xxxxxxxxxxxxxx| . ^ 1283 |xxxxxxxxxxxxxx| . Bandwidth . 1284 |xxxxxxxxxxxxxx| . Available for . 1285 |xxxxxxxxxxxxxx| . non-priority . 1286 |xxxxxxxxxxxxxx| . use . 1287 |xxxxxxxxxxxxxx| . . Bandwidth 1288 |xxxxxxxxxxxxxx| . . available for 1289 |xxxxxxxxxxxxxx| v . non-priority 1290 |--------------| --- . and priority 1291 | | . use 1292 | | . 1293 |oooooooooooooo| v 1294 --------------------------------------- 1296 Figure 11: Full non-priority load & Partial Aggregate load 1298 Figure 12 shows the case where only some of the bandwidth available 1299 to non-priority traffic is being used and a heavy load of priority 1300 traffic is in place. In that situation both new non-priority 1301 sessions and new priority sessions would be accepted. Note that, as 1302 illustrated in Figure 11, priority sessions use some of the bandwidth 1303 currently not used by non-priority traffic. 1305 -------------------------------------- 1306 |xxxxxxxxxxxxxx| . ^ 1307 |xxxxxxxxxxxxxx| . Bandwidth . 1308 |xxxxxxxxxxxxxx| . Available for . 1309 |xxxxxxxxxxxxxx| . non-priority . 1310 |xxxxxxxxxxxxxx| . use . 1311 | | . . Bandwidth 1312 | | . . available for 1313 |oooooooooooooo| v . non-priority 1314 |--------------| --- . and priority 1315 |oooooooooooooo| . use 1316 |oooooooooooooo| . 1317 |oooooooooooooo| v 1318 --------------------------------------- 1320 Figure 12: Partial non-priority load & Heavy Aggregate load 1322 Figure 13 shows the case where all of the bandwidth available to non- 1323 priority traffic is being used and all of the remaining available 1324 bandwidth is used by priority traffic. In that situation new non- 1325 priority sessions would be rejected. In that situation new priority 1326 sessions could not be accepted right away. Those priority sessions 1327 may be handled by mechanisms, which are beyond the scope of this 1328 particular document (such as established through preemption of 1329 existing non-priority sessions, or such as queuing of new priority 1330 session requests until capacity becomes available again for priority 1331 traffic). 1333 -------------------------------------- 1334 |xxxxxxxxxxxxxx| . ^ 1335 |xxxxxxxxxxxxxx| . Bandwidth . 1336 |xxxxxxxxxxxxxx| . Available for . 1337 |xxxxxxxxxxxxxx| . non-priority . 1338 |xxxxxxxxxxxxxx| . use . 1339 |xxxxxxxxxxxxxx| . . Bandwidth 1340 |xxxxxxxxxxxxxx| . . available for 1341 |xxxxxxxxxxxxxx| v . non-priority 1342 |--------------| --- . and priority 1343 |oooooooooooooo| . use 1344 |oooooooooooooo| . 1345 |oooooooooooooo| v 1346 --------------------------------------- 1348 Figure 13: Full non-priority load & Full Aggregate load 1350 A.3. Admission Priority with Priority Bypass Model (PrBM) 1352 This section illustrates operations of admission priority when a 1353 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1354 across non-priority traffic and priority traffic. With the Priority 1355 Bypass Model, non-priority traffic is subject to resource based 1356 admission control while priority traffic simply bypasses the resource 1357 based admission control. In other words: 1359 o when a non-priority session arrives, this session is subject to 1360 bandwidth admission control and is accepted if the current total 1361 load (aggregate over non-priority and priority traffic) is below 1362 the engineered/allocated bandwidth. 1364 o when a priority session arrives, this session is admitted 1365 regardless of the current load. 1367 A property of this model is that a priority session is never 1368 rejected. 1370 The rationale for this simple scheme is that, in practice in some 1371 networks: 1373 o the volume of priority sessions is very low for the vast majority 1374 of time, so it may not be economical to completely set aside 1375 bandwidth for priority sessions and preclude the utilization of 1376 this bandwidth by normal sessions in normal situations 1378 o even in emergency periods where priority sessions are more heavily 1379 used, those always still represent a fairly small proportion of 1380 the overall load which can be absorbed within the safety margin of 1381 the engineered capacity limits. Thus, even if they are admitted 1382 beyond the engineered bandwidth threshold, they are unlikely to 1383 result in noticeable QoS degradation. 1385 As with the MAM and RDM model, an operator may map the Priority 1386 Bypass model onto the Engineered Capacity limits according to 1387 different policies. The operator may decide to configure the 1388 bandwidth limit for admission of non-priority traffic to the full 1389 engineered capacity limits; As an example, if the engineered capacity 1390 limit on a given link is X, the operator may configure the bandwidth 1391 limit for non-priority traffic to X. Alternatively, the operator may 1392 decide to configure the bandwidth limit for non-priority traffic to 1393 below the engineered capacity limits (so that the sum of the non- 1394 priority and priority traffic stays below the engineered capacity); 1395 As an example, if the engineered capacity limit on a given link is X, 1396 the operator may configure the bandwidth limit for non-priority 1397 traffic to 95% of X. Finally, the operator may decide to strike a 1398 balance in between. The considerations presented for these policies 1399 in the previous sections in the MAM and RDM contexts are equally 1400 applicable to the Priority Bypass Model. 1402 Figure 14 illustrates the bandwidth allocation with the Priority 1403 Bypass Model. 1405 ----------------------- 1406 ^ ^ | | ^ 1407 . . | | . 1408 Total . . | | . Bandwidth Limit 1409 (1) (2) | | . (on non-priority + priority) 1410 Engi- . . | | . for admission 1411 neered . or . | | . of non-priority traffic 1412 . . | | . 1413 Capacity. . | | . 1414 v . | | v 1415 . |--------------| --- 1416 . | | 1417 v | | 1418 | | 1420 Figure 14: Priority Bypass Model Bandwidth Allocation 1422 Figure 15 shows some of the non-priority capacity of this link being 1423 used. In this situation, both new non-priority and new priority 1424 sessions would be accepted. 1426 ----------------------- 1427 ^ ^ |xxxxxxxxxxxxxx| ^ 1428 . . |xxxxxxxxxxxxxx| . 1429 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1430 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1431 Engi- . . | | . for admission 1432 neered . or . | | . of non-priority traffic 1433 . . | | . 1434 Capacity. . | | . 1435 v . | | v 1436 . |--------------| --- 1437 . | | 1438 v | | 1439 | | 1441 Figure 15: Partial load of non-priority calls 1443 Figure 16 shows the same amount of non-priority load being used at 1444 this link, and a small amount of priority bandwidth being used. In 1445 this situation, both new non-priority and new priority sessions would 1446 be accepted. 1448 ----------------------- 1449 ^ ^ |xxxxxxxxxxxxxx| ^ 1450 . . |xxxxxxxxxxxxxx| . 1451 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1452 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1453 Engi- . . |oooooooooooooo| . for admission 1454 neered . or . | | . of non-priority traffic 1455 . . | | . 1456 Capacity. . | | . 1457 v . | | v 1458 . |--------------| --- 1459 . | | 1460 v | | 1461 | | 1463 Figure 16: Partial load of non-priority calls & partial load of 1464 priority calls 1466 Figure 17 shows the case where aggregate non-priority and priority 1467 load exceeds the bandwidth limit for admission of non-priority 1468 traffic. In this situation, any new non-priority session is rejected 1469 while any new priority session is admitted. 1471 ----------------------- 1472 ^ ^ |xxxxxxxxxxxxxx| ^ 1473 . . |xxxxxxxxxxxxxx| . 1474 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1475 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1476 Engi- . . |oooooooooooooo| . for admission 1477 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1478 . . |xxoxxxxxxoxxxx| . 1479 Capacity. . |oxxxooooxxxxoo| . 1480 v . |xxoxxxooxxxxxx| v 1481 . |--------------| --- 1482 . |oooooooooooooo| 1483 v | | 1484 | | 1486 Figure 17: Full non-priority load 1488 Appendix B. Example Usages of RSVP Extensions 1490 This section provides examples of how RSVP extensions defined in this 1491 document can be used (in conjunctions with other RSVP functionality 1492 and SIP functionality) to enforce different hypothetical policies for 1493 handling Emergency sessions in a given administrative domain. This 1494 Appendix does not provide additional specification. It is only 1495 included in this document for illustration purposes. 1497 We assume an environment where SIP is used for session control and 1498 RSVP is used for resource reservation. 1500 In a mild abuse of language, we refer here to "Call Queueing" as the 1501 set of "session" layer capabilities that may be implemented by SIP 1502 user agents to influence their treatment of SIP requests. This may 1503 include the ability to "queue" session requests when those can not be 1504 immediately honored (in some cases with the notion of "bumping", or 1505 "displacement", of less important session requests from that queue). 1506 It may include additional mechanisms such as exemption from certain 1507 network management controls, and alternate routing. 1509 We only mention below the RSVP policy elements that are to be 1510 enforced by PEPs. It is assumed that these policy elements are set 1511 at administrative domain boundaries by PDPs. The Admission Priority 1512 and Preemption Priority RSVP policy elements are set by PDPs as a 1513 result of processing the Application Level Resource Priority Policy 1514 Element (which is carried in RSVP messages). 1516 If one wants to implement an emergency service purely based on Call 1517 Queueing, one can achieve this by signaling emergency sessions: 1519 o using "Resource-Priority" Header in SIP 1521 o not using Admission-Priority Policy Element in RSVP 1523 o not using Preemption Policy Element in RSVP 1525 If one wants to implement an emergency service based on Call Queueing 1526 and on "prioritized access to network layer resources", one can 1527 achieve this by signaling emergency sessions: 1529 o using "Resource-Priority" Header in SIP 1531 o using Admission-Priority Policy Element in RSVP 1533 o not using Preemption Policy Element in RSVP 1535 Emergency sessions will not result in preemption of any session. 1536 Different bandwidth allocation models can be used to offer different 1537 "prioritized access to network resources". Just as examples, this 1538 includes strict setting aside of capacity for emergency sessions as 1539 well as simple bypass of admission limits for emergency sessions. 1541 If one wants to implement an emergency service based on Call 1542 Queueing, on "prioritized access to network layer resources", and 1543 ensures that (say) "Emergency-1" sessions can preempt "Emergency-2" 1544 sessions, but non-emergency sessions are not affected by preemption, 1545 one can do that by signaling emergency sessions: 1547 o using "Resource-Priority" Header in SIP 1549 o using Admission-Priority Policy Element in RSVP 1551 o using Preemption Policy Element in RSVP with: 1553 * setup (Emergency-1) > defending (Emergency-2) 1555 * setup (Emergency-2) <= defending (Emergency-1) 1557 * setup (Emergency-1) <= defending (Non-Emergency) 1559 * setup (Emergency-2) <= defending (Non-Emergency) 1561 If one wants to implement an emergency service based on Call 1562 Queueing, on "prioritized access to network layer resources", and 1563 ensure that "emergency" sessions can preempt regular sessions, one 1564 could do that by signaling emergency sessions: 1566 o using "Resource-Priority" Header in SIP 1568 o using Admission-Priority Policy Element in RSVP 1570 o using Preemption Policy Element in RSVP with: 1572 * setup (Emergency) > defending (Non-Emergency) 1574 * setup (Non-Emergency) <= defending (Emergency) 1576 If one wants to implement an emergency service based on Call 1577 Queueing, on "prioritized access to network layer resources", and 1578 ensure that "emergency" sessions can partially preempt regular 1579 sessions (i.e. reduce their reservation size), one could do that by 1580 signaling emergency sessions: 1582 o using "Resource-Priority" Header in SIP 1584 o using Admission-Priority Policy Element in RSVP 1586 o using Preemption in Policy Element RSVP with: 1588 * setup (Emergency) > defending (Non-Emergency) 1590 * setup (Non-Emergency) <= defending (Emergency) 1592 o activate RFC4495 RSVP Bandwidth Reduction mechanisms 1594 Authors' Addresses 1596 Francois Le Faucheur 1597 Cisco Systems 1598 Greenside, 400 Avenue de Roumanille 1599 Sophia Antipolis 06410 1600 France 1602 Phone: +33 4 97 23 26 19 1603 Email: flefauch@cisco.com 1604 James Polk 1605 Cisco Systems 1606 2200 East President George Bush Highway 1607 Richardson, TX 75082-3550 1608 United States 1610 Phone: +1 972 813 5208 1611 Email: jmpolk@cisco.com 1613 Ken Carlberg 1614 G11 1615 123a Versailles Circle 1616 Towson, MD 21204 1617 United States 1619 Email: carlberg@g11.org.uk