idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1532. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1556. 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 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 (October 17, 2008) is 5669 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 160, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 772, 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-06 == Outdated reference: A later version (-11) exists of draft-ietf-dime-qos-parameters-06 == 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-20 == Outdated reference: A later version (-07) exists of draft-ietf-tsvwg-rsvp-l3vpn-00 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-01 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 7 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: April 20, 2009 K. Carlberg 6 G11 7 October 17, 2008 9 Resource ReSerVation Protovol (RSVP) Extensions for Emergency Services 10 draft-ietf-tsvwg-emergency-rsvp-09.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 This Internet-Draft will expire on April 20, 2009. 37 Abstract 39 An Emergency Telecommunications Service (ETS) requires the ability to 40 provide an elevated probability of session establishment to an 41 authorized user in times of network congestion (typically, during a 42 crisis). When supported over the Internet Protocol suite, this may 43 be facilitated through a network layer admission control solution, 44 which supports prioritized access to resources (e.g., bandwidth). 45 These resources may be explicitly set aside for emergency services, 46 or they may be shared with other sessions. 48 This document specifies extensions to the Resource reSerVation 49 Protocol (RSVP) that can be used to support such an admission 50 priority capability at the network layer. Note that these extensions 51 represent one possible solution component in satisfying ETS 52 requirements. Other solution components, or other solutions, are 53 outside the scope of this document. 55 The mechanisms defined in this document are applicable to controlled 56 environments formed by either a single administrative domain or a set 57 of administrative domains that closely coordinate their network 58 policy and network design. The mechanisms defined in this document 59 can be used for a session whose path spans over such a controlled 60 environment in order to elevate the session establishment probability 61 through the controlled environment (thereby elevating the end to end 62 session establishment probability). 64 Requirements Language 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Related Technical Documents . . . . . . . . . . . . . . . 5 74 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Overview of RSVP extensions and Operations . . . . . . . . . . 6 76 2.1. Operations of Admission Priority . . . . . . . . . . . . . 8 77 3. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 9 78 3.1. Admission Priority Policy Element . . . . . . . . . . . . 9 79 3.1.1. Admission Priority Merging Rules . . . . . . . . . . . 11 80 3.2. Application-Level Resource Priority Policy Element . . . . 12 81 3.2.1. Application-Level Resource Priority Modifying and 82 Merging Rules . . . . . . . . . . . . . . . . . . . . 13 83 3.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 14 84 4. Security Considerations . . . . . . . . . . . . . . . . . . . 14 85 4.1. Use of RSVP Authentication between RSVP neighbors . . . . 15 86 4.2. Use of INTEGRITY object within the POLICY_DATA object . . 15 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 88 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 91 7.2. Informative References . . . . . . . . . . . . . . . . . . 20 92 Appendix A. Examples of Bandwidth Allocation Model for 93 Admission Priority . . . . . . . . . . . . . . . . . 21 94 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 22 95 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 26 96 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 29 97 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 32 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 99 Intellectual Property and Copyright Statements . . . . . . . . . . 36 101 1. Introduction 103 [RFC3689] and [RFC3690] detail requirements for an Emergency 104 Telecommunications Service (ETS), which is an umbrella term 105 identifying those networks and specific services used to support 106 emergency communications. An underlying goal of these documents is 107 to present requirements that elevate the probability of session 108 establishment from an authorized user in times of network congestion 109 (presumably because of a crisis condition). In some extreme cases, 110 the requirement for this probability may reach 100%, but that is a 111 topic subject to policy and most likely local regulation (the latter 112 being outside the scope of this document). 114 Solutions to meet this requirement for elevated session establishment 115 probability may involve session layer capabilities prioritizing 116 access to resources controlled by the session control function. As 117 an example, entities involved in session control (such as SIP user 118 agents, when the Session Initiation Protocol (SIP) [RFC3261], is the 119 session control protocol in use) can influence their treatment of 120 session establishment requests (such as SIP requests). This may 121 include the ability to "queue" session establishment requests when 122 those can not be immediately honored (in some cases with the notion 123 of "bumping", or "displacement", of less important session 124 establishment requests from that queue). It may include additional 125 mechanisms such as exemption from certain network management 126 controls, and alternate routing. 128 Solutions to meet the requirement for elevated session establishment 129 probability may also take advantage of network layer admission 130 control mechanisms supporting admission priority. Networks usually 131 have engineered capacity limits that characterize the maximum load 132 that can be handled (say, on any given link) for a class of traffic 133 while satisfying the quality of service requirements of that traffic 134 class. Admission priority may involve setting aside some network 135 resources (e.g. bandwidth) out of the engineered capacity limits for 136 the emergency services only. Or alternatively, it may involve 137 allowing the emergency related sessions to seize additional resources 138 beyond the engineered capacity limits applied to normal sessions. 139 This document specifies the necessary extensions to support such 140 admission priority when network layer admission control is performed 141 using the Resource ReSerVation Protovol (RSVP) ([RFC2205]). 143 The mechanisms defined in this document are applicable to controlled 144 environments formed by either a single administrative domain or a set 145 of administrative domains that closely coordinate their network 146 policy and network design. The mechanisms defined in this document 147 can be used for a session whose path spans over such a controlled 148 environment in order to elevate the session establishment probability 149 through the controlled environment (thereby elevating the end to end 150 session establishment probability). 152 IP telephony "calls" are one form of "sessions" that can benefit from 153 the elevated session establishment probability discussed in this 154 document. Video over IP and Instant Messaging are other examples. 155 For the sake of generality, we use the term "session" throughout this 156 document to refer to any type of session. 158 1.1. Related Technical Documents 160 [RFC4542] is patterned after [ITU.I.225] and describes an example of 161 one type of prioritized network layer admission control procedure 162 that may be used for emergency services operating over an IP network 163 infrastructure. It discusses initial session set up, as well as 164 operations after session establishment through maintenance of a 165 continuing call model of the status of all sessions. [RFC4542] also 166 describes how these network layer admission control procedures can be 167 realized using the Resource reSerVation Protocol [RFC2205] along with 168 its associated protocol suite and extensions, including those for 169 policy based admission control ([RFC2753], [RFC2750]), for user 170 authentication and authorization ([RFC3182]) and for integrity and 171 authentication of RSVP messages ([RFC2747], [RFC3097]). The Diameter 172 QoS Application ([I-D.ietf-dime-diameter-qos]) allows network 173 elements to interact with Diameter servers when allocating QoS 174 resources in the network and thus, is also a possible method for 175 authentication and authorization of RSVP reservations in the context 176 of emergency services. 178 [RFC4542] describes how the RSVP Signaled Preemption Priority Policy 179 Element specified in [RFC3181] can be used to enforce the session 180 preemption that may be needed by some emergency services. In 181 contrast to [RFC4542], this document specifies new RSVP extensions to 182 increase the probability of session establishment without preemption. 183 Engineered capacity techniques in the form of bandwidth allocation 184 models are used to satisfy the "admission priority" required by an 185 RSVP capable ETS network. In particular this document specifies two 186 new RSVP Policy Elements allowing the admission priority to be 187 conveyed inside RSVP signaling messages so that RSVP nodes can 188 enforce selective bandwidth admission control decision based on the 189 session admission priority. Appendix A of this document also 190 provides examples of bandwidth allocation models which can be used by 191 RSVP-routers to enforce such admission priority on every link. 193 1.2. Terminology 195 This document assumes the terminology defined in [RFC2753]. For 196 convenience, the definition of a few key terms is repeated here: 198 o Policy Decision Point (PDP): The point where policy decisions are 199 made. 201 o Local Policy Decision Point (LPDP): PDP local to the network 202 element. 204 o Policy Enforcement Point (PEP): The point where the policy 205 decisions are actually enforced. 207 o Policy Ignorant Node (PIN): A network element that does not 208 explicitly support policy control using the mechanisms defined in 209 [RFC2753]. 211 2. Overview of RSVP extensions and Operations 213 Let us consider the case where a session requiring ETS type service 214 is to be established, and more specifically that the preference to be 215 granted to this session is in terms of network layer "admission 216 priority" (as opposed to preference granted through preemption of 217 existing sessions). By "admission priority" we mean allowing that 218 priority session to seize network layer resources from the engineered 219 capacity that have been set-aside and not made available to normal 220 sessions, or alternatively by allowing that session to seize 221 additional resources beyond the engineered capacity limits applied to 222 normal sessions. 224 As described in [RFC4542], the session establishment can be 225 conditioned to resource-based and policy-based network layer 226 admission control achieved via RSVP signaling. In the case where the 227 session control protocol is SIP, the use of RSVP-based admission 228 control by SIP is specified in [RFC3312]. 230 Devices involved in the session establishment are expected to be 231 aware of the application-level priority requirements of emergency 232 sessions. Again considering the case where the session control 233 protocol is SIP, the SIP user agents can be made aware of the 234 resource priority requirements in the case of an emergency session 235 using the Resource-Priority Header mechanism specified in [RFC4412]. 236 The end-devices involved in the upper-layer session establishment 237 simply need to copy the application-level resource priority 238 requirements (e.g. as communicated in SIP Resource-Priority Header) 239 inside the new RSVP Application-Level Resource-Priority Policy 240 Element defined in this document. 242 Conveying the application-level resource priority requirements inside 243 the RSVP message allows this application level requirement to be 244 mapped/remapped into a different RSVP "admission priority" at every 245 administrative domain boundary based on the policy applicable in that 246 domain. In a typical model (see [RFC2753]) where PDPs control PEPs 247 at the periphery of the policy domain (e.g., in border routers), PDPs 248 would interpret the RSVP Application-Level Resource-Priority Policy 249 Element and map the requirement of the emergency session into an RSVP 250 "admission priority" level. Then, PDPs would convey this information 251 inside the new Admission Priority Policy Element defined in this 252 document. This way, the RSVP admission priority can be communicated 253 to downstream PEPs (ie RSVP Routers) of the same policy domain, which 254 have LPDPs but no controlling PDP. In turn, this means the necessary 255 RSVP Admission priority can be enforced at every RSVP hop, including 256 all the (many) hops which do not have any understanding of 257 Application-Level Resource-Priority semantics. 259 As an example of operation across multiple administrative domains, a 260 first domain might decide to provide network layer admission priority 261 to sessions of a given Application Level Resource Priority and map it 262 into a high RSVP admission control priority inside the Admission 263 Priority Policy Element; while a second domain may decide to not 264 provide admission priority to sessions of this same Application Level 265 Resource Priority and hence map it into a low RSVP admission control 266 priority. 268 As another example of operation across multiple administrative 269 domains, we can consider the case where the resource priority header 270 enumerates several namespaces, as explicitly allowed by [RFC4412], 271 for support of scenarios where sessions traverse multiple 272 administrative domains using different namespace. In that case, the 273 relevant namespace can be used at each domain boundary to map into an 274 RSVP Admission priority for that domain. It is not expected that the 275 RSVP Application-Level Resource-Priority Header Policy Element would 276 be taken into account at RSVP-hops within a given administrative 277 domain. It is expected to be used at administrative domain 278 boundaries only in order to set/reset the RSVP Admission Priority 279 Policy Element. 281 The existence of pre-established inter-domain policy agreements or 282 Service Level Agreements may avoid the need to take real-time action 283 at administrative domain boundaries for mapping/remapping of 284 admission priorities. 286 Mapping/remapping by PDPs may also be applied to boundaries between 287 various signaling protocols, such as those advanced by the NSIS 288 working group. 290 As can be observed, the framework described above for mapping/ 291 remapping application level resource priority requirements into an 292 RSVP admission priority can also be used together with [RFC3181] for 293 mapping/remapping application level resource priority requirements 294 into an RSVP preemption priority (when preemption is indeed needed). 295 In that case, when processing the RSVP Application-Level Resource- 296 Priority Policy Element, the PDPs at boundaries between 297 administrative domains (or between various QoS signaling protocols) 298 can map it into an RSVP "preemption priority" information. This 299 Preemption priority information comprises a setup preemption level 300 and a defending preemption priority level. This preemption priority 301 information can then be encoded inside the Preemption Priority Policy 302 Element of [RFC3181] and thus, can be taken into account at every 303 RSVP-enabled network hop as discussed [RFC4542]. Appendix B provides 304 examples of various hypothetical policies for emergency session 305 handling, some of them involving admission priority, some of them 306 involving both admission priority and preemption priority. Appendix 307 B also identifies how the Application-Level Resource Priority need to 308 be mapped into RSVP policy elements by the PDPs to realize these 309 policies. 311 2.1. Operations of Admission Priority 313 The RSVP Admission Priority policy element defined in this document 314 allows admission bandwidth to be allocated preferentially to an 315 authorized priority service. Multiple models of bandwidth allocation 316 MAY be used to that end. 318 A number of bandwidth allocation models have been defined in the IETF 319 for allocation of bandwidth across different classes of traffic 320 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 321 Those include the Maximum Allocation Model (MAM) defined in 322 [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and 323 the Maximum Allocation model with Reservation (MAR) defined in 324 [RFC4126]. These same models MAY however be applied for allocation 325 of bandwidth across different levels of admission priority as defined 326 in this document. Appendix A provides an illustration of how these 327 bandwidth allocation models can be applied for such purposes and 328 introduces an additional bandwidth allocation model that we term the 329 Priority Bypass Model (PrBM). It is important to note that the 330 models described and illustrated in Appendix A are only informative 331 and do not represent a recommended course of action. 333 We can see in these examples, that the RSVP Admission Priority may 334 effectively influence the fundamental admission control decision of 335 RSVP (for example by determining which bandwidth pool is to be used 336 by RSVP for performing its fundamental bandwidth allocation). In 337 that sense, we observe that the policy control and admission control 338 are not separate logics but instead somewhat blended. 340 3. New Policy Elements 342 The Framework document for policy-based admission control [RFC2753] 343 describes the various components that participate in policy decision 344 making (i.e., PDP, PEP and LPDP). 346 As described in section 2 of the present document, the Application- 347 Level Resource Priority Policy Element and the Admission Priority 348 Policy Element serve different roles in this framework: 350 o the Application-Level Resource Priority Policy Element conveys 351 application level information and is processed by PDPs 353 o the emphasis of Admission Priority Policy Element is to be simple, 354 stateless, and light-weight such that it can be processed 355 internally within a node's LPDP. It can then be enforced 356 internally within a node's PEP. It is set by PDPs based on 357 processing of the Application-Level Resource Priority Policy 358 Element. 360 [RFC2750] defines extensions for supporting generic policy based 361 admission control in RSVP. These extensions include the standard 362 format of POLICY_DATA objects and a description of RSVP handling of 363 policy events. 365 The POLICY_DATA object contains one or more of Policy Elements, each 366 representing a different (and perhaps orthogonal) policy. As an 367 example, [RFC3181] specifies the Preemption Priority Policy Element. 368 This document defines two new Policy Elements called: 370 o the Admission Priority Policy Element 372 o the Application-Level Resource Priority Policy Element 374 3.1. Admission Priority Policy Element 376 The format of the Admission Priority policy element is as shown in 377 Figure 1: 379 0 0 0 1 1 2 2 3 380 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 381 +-------------+-------------+-------------+-------------+ 382 | Length | P-Type = ADMISSION_PRI | 383 +-------------+-------------+-------------+-------------+ 384 | Flags | M. Strategy | Error Code | Reserved | 385 +-------------+-------------+-------------+-------------+ 386 | Reserved |Adm. Priority| 387 +---------------------------+---------------------------+ 389 Figure 1: Admission Priority Policy Element 391 where: 393 o Length: 16 bits 395 * Always 12. The overall length of the policy element, in bytes. 397 o P-Type: 16 bits 399 * ADMISSION_PRI = To be allocated by IANA (see "IANA 400 Considerations" section) 402 o Flags: Reserved 404 * SHALL be set to zero on transmit and SHALL be ignored on 405 reception 407 o Merge Strategy: 8 bits (only applicable to multicast flows) 409 * values are defined by corresponding registry maintained by IANA 410 (see "IANA Considerations" section) 412 o Error code: 8 bits (only applicable to multicast flows) 414 * values are defined by corresponding registry maintained by IANA 415 (see "IANA Considerations" section) 417 o Reserved: 8 bits 419 * SHALL be set to zero on transmit and SHALL be ignored on 420 reception 422 o Reserved: 24 bits 424 * SHALL be set to zero on transmit and SHALL be ignored on 425 reception 427 o Adm. Priority (Admission Priority): 8 bits (unsigned) 429 * The admission control priority of the flow, in terms of access 430 to network bandwidth in order to provide higher probability of 431 session completion to selected flows. Higher values represent 432 higher Priority. A given Admission Priority is encoded in this 433 information element using the same value as when encoded in the 434 "Admission Priority" field of the "Admission Priority" 435 parameter defined in [I-D.ietf-nsis-qspec], or in the 436 "Admission Priority" parameter defined in 437 [I-D.ietf-dime-qos-parameters]. In other words, a given value 438 inside the Admission Priority information element defined in 439 the present document, inside the [I-D.ietf-nsis-qspec] 440 Admission Priority field or inside the 441 [I-D.ietf-dime-qos-parameters] Admission Priority parameter, 442 refers to the same admission priority. Bandwidth allocation 443 models such as those described in Appendix A are to be used by 444 the RSVP router to achieve such increased probability of 445 session establishment. The admission priority value 446 effectively indicates which bandwidth constraint(s) of the 447 bandwidth constraint model in use is(are) applicable to 448 admission of this RSVP reservation. 450 Note that the Admission Priority Policy Element does NOT indicate 451 that this RSVP reservation is to preempt any other RSVP reservation. 452 If a priority session justifies both admission priority and 453 preemption priority, the corresponding RSVP reservation needs to 454 carry both an Admission Priority Policy Element and a Preemption 455 Priority Policy Element. The Admission Priority and Preemption 456 Priority are handled by LPDPs and PEPs as separate mechanisms. They 457 can be used one without the other, or they can be used both in 458 combination. 460 3.1.1. Admission Priority Merging Rules 462 This section discusses alternatives for dealing with RSVP admission 463 priority in case of merging of reservations. As merging is only 464 applicable to multicast, this section also only applies to multicast 465 sessions. 467 The rules for merging Admission Priority Policy Elements are defined 468 by the value encoded inside the Merge Strategy field in accordance 469 with the corresponding IANA registry. The merge strategies (and 470 associated values) defined by the present document are the same as 471 those defined in [RFC3181] for merging Preemption Priority Policy 472 Elements (see "IANA Considerations" section). 474 The only difference with [RFC3181] is that this document does not 475 recommend any merge strategies for Admission Priority, while 476 [RFC3181] recommends the first of these merge strategies for 477 Preemption Priority. Note that with the Admission Priority (as is 478 the case with the Preemption Priority), "Take highest priority" 479 translates into "take the highest numerical value". 481 3.2. Application-Level Resource Priority Policy Element 483 The format of the Application-Level Resource Priority policy element 484 is as shown in Figure 2: 486 0 0 0 1 1 2 2 3 487 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 488 +-------------+-------------+-------------+-------------+ 489 | Length | P-Type = APP_RESOURCE_PRI | 490 +-------------+-------------+-------------+-------------+ 491 // ALRP List // 492 +---------------------------+---------------------------+ 494 Figure 2: Application-Level Resource Priority Policy Element 496 where: 498 o Length: 500 * The length of the policy element (including the Length and 501 P-Type) is in number of octets (MUST be a multiple of 4) and 502 indicates the end of the ALRP list. 504 o P-Type: 16 bits 506 * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA 507 Considerations" section) 509 o ALRP List: 511 * List of ALRP where each ALRP is encoded as shown in Figure 3. 513 ALRP: 514 0 0 0 1 1 2 2 3 515 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 516 +---------------------------+-------------+-------------+ 517 | ALRP Namespace | Reserved |ALRP Priority| 518 +---------------------------+---------------------------+ 520 Figure 3: Application-Level Resource Priority 522 where: 524 o ALRP Namespace (Application-Level Resource Priority Namespace): 16 525 bits (unsigned) 527 * Contains a numerical value identifying the namespace of the 528 application-level resource priority. This value is encoded as 529 per the "Resource-Priority Namespaces" IANA registry. (See 530 IANA Considerations section for the request to IANA to extend 531 the registry to include this numerical value). 533 o Reserved: 8 bits 535 * SHALL be set to zero on transmit and SHALL be ignored on 536 reception. 538 o ALRP Priority: (Application-Level Resource Priority Priority): 8 539 bits (unsigned) 541 * Contains the priority value within the namespace of the 542 application-level resource priority. This value is encoded as 543 per the "Resource-Priority Priority-Value" IANA registry. (See 544 IANA Considerations section for the request to IANA to extend 545 the registry to include this numerical value). 547 3.2.1. Application-Level Resource Priority Modifying and Merging Rules 549 When POLICY_DATA objects are protected by integrity, LPDPs should not 550 attempt to modify them. They MUST be forwarded as-is to ensure their 551 security envelope is not invalidated. 553 In case of multicast, when POLICY_DATA objects are not protected by 554 integrity, LPDPs MAY merge incoming Application-Level Resource 555 Priority elements to reduce their size and number. When they do 556 merge those, LPDPs MUST do so according to the following rule: 558 o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST list 559 all the ALRPs appearing in the ALRP List of an incoming 560 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 561 once. In other words, the outgoing ALRP List is the union of the 562 incoming ALRP Lists that are merged. 564 As merging is only applicable to Multicast, this rule only applies to 565 Multicast sessions. 567 3.3. Default Handling 569 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 570 (PINs) implement a default handling of POLICY_DATA objects ensuring 571 that those objects can traverse PIN nodes in transit from one PEP to 572 another. This applies to the situations where POLICY_DATA objects 573 contain the Admission Priority Policy Element and the ALRP Policy 574 Element specified in this document, so that those can traverse PIN 575 nodes. 577 Section 4.2 of [RFC2750] also defines a similar default behavior for 578 policy-capable nodes that do not recognized a particular Policy 579 Element. This applies to the Admission Priority Policy Element and 580 the ALRP Policy Element specified in this document, so that those can 581 traverse policy-capable nodes that do not support this document. 583 4. Security Considerations 585 As this document defines extensions to RSVP, the security 586 considerations of RSVP apply. Those are discussed in [RFC2205], 587 [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 589 A subset of RSVP messages are signaled with the Router Alert Option 590 (RAO)([RFC2113],[RFC2711]). However, some network administrators 591 activate mechanisms at the edge of their administrative domain to 592 protect against potential Denial Of Service (DOS) attacks associated 593 with RAO. This may include hiding of the RAO to downstream interior 594 routers in the domain (as recommended by default over an MPLS network 595 in [I-D.dasmith-mpls-ip-options]) or complete blocking of packets 596 received with RAO at the administrative boundary. As the mechanisms 597 defined in this document rely on RSVP, their usage assume that such 598 protection against RAO packets are not activated in a way that 599 prevents RSVP processing on relevant interfaces or routers of the 600 controlled environments electing to deploy these mechanisms. 601 Nonetheless, it is recommended that protection mechanisms be 602 activated against potential DOS attacks through RAO even when RAO 603 message are processed. This may include rate limiting of incoming 604 RAO packets (e.g. at interface and/or router level). This may also 605 include deploying an RSVP architecture whereby interior routers are 606 not exposed to any RSVP messages associated with end to end 607 reservations (such as the architecture defined in 609 [I-D.ietf-tsvwg-rsvp-l3vpn]). We observe that the risks and security 610 measures associated with processing of RAO messages at an 611 administrative domain edge are fundamentally similar to those 612 involved with other forms of control plane interactions allowed at 613 administrative domain edges, such as routing or multicast routing 614 interactions allowed between a customer and his Internet Service 615 Provider, MPLS VPN ( [RFC4364] Service Provider , [RFC4659]) or MPLS 616 MVPN ([I-D.ietf-l3vpn-2547bis-mcast]) Service Provider. 618 The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in 619 this doocument are signaled by RSVP through encapsulation in a Policy 620 Data object as defined in [RFC2750]. Therefore, like any other 621 Policy Elements, their integrity can be protected as discussed in 622 section 6 of [RFC2750] by two optional security mechanisms. The 623 first mechanism relies on RSVP Authentication as specified in 624 [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP 625 nodes are policy capable. With this mechanism, the INTEGRITY object 626 is carried inside RSVP messages. The second mechanism relies on the 627 INTEGRITY object within the POLICY_DATA object to guarantee integrity 628 between RSVP Policy Enforcement Points (PEPs) that are not RSVP 629 neighbors. 631 4.1. Use of RSVP Authentication between RSVP neighbors 633 This mechanism can be used between RSVP neighbors that are policy 634 capable. The RSVP neighbors use shared keys to compute the 635 cryptographic signature of the RSVP message. 636 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key 637 provisioning methods as well as their respective applicability. 639 4.2. Use of INTEGRITY object within the POLICY_DATA object 641 The INTEGRITY object within the POLICY_DATA object can be used to 642 guarantee integrity between non-neighboring RSVP PEPs. 644 Details for computation of the content of the INTEGRITY object can be 645 found in Appendix B of [RFC2750]. This states that the Policy 646 Decision Point (PDP), at its discretion, and based on destination 647 PEP/PDP or other criteria, selects an Authentication Key and the hash 648 algorithm to be used. Keys to be used between PDPs can be 649 distributed manually or via standard key management protocol for 650 secure key distribution. 652 Note that where non-RSVP hops may exist in between RSVP hops, as well 653 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 654 between PEPs, it may be difficult for the PDP to determine what is 655 the destination PDP for a POLICY_DATA object contained in some RSVP 656 messages (such as a Path message). This is because in those cases 657 the next PEP is not known at the time of forwarding the message. In 658 this situation, key shared across multiple PDPs may be used. This is 659 conceptually similar to the use of key shared across multiple RSVP 660 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 661 We observe also that this issue may not exist in some deployment 662 scenarios where a single (or low number of) PDP is used to control 663 all the PEPs of a region (such as an administrative domain). In such 664 scenarios, it may be easy for a PDP to determine what is the next hop 665 PDP, even when the next hop PEP is not known, simply by determining 666 what is the next region that will be traversed (say based on the 667 destination address). 669 5. IANA Considerations 671 As specified in [RFC2750], Standard RSVP Policy Elements (P-type 672 values) are to be assigned by IANA as per "IETF Consensus" policy 673 following the policies outlined in [RFC2434] (this policy is now 674 called "IETF Review" as per [RFC5226]) . 676 IANA needs to allocate two P-Types from the Standard RSVP Policy 677 Element range: 679 o one P-Type to the Admission Priority Policy Element 681 o one P-Type to the Application-Level Resource Priority Policy 682 Element. 684 In section 3.1, the present document defines a Merge Strategy field 685 inside the Admission Priority policy element. IANA needs to create a 686 registry for this field and allocate the following values: 688 o 1: Take priority of highest QoS 690 o 2: Take highest priority 692 o 3: Force Error on heterogeneous merge 694 Following the policies outlined in [RFC5226], numbers in the range 695 4-127 are allocated according to the "IETF Review" policy, numbers in 696 the range 128-240 as "First Come First Served" and numbers between 697 241-255 are reserved for "Private Use". Value 0 is Reserved (for 698 consistency with [RFC3181] Merge Strategy values). 700 In section 3.1, the present document defines an Error Code field 701 inside the Admission Priority policy element. IANA needs to create a 702 registry for this field and allocate the following values: 704 o 0: NO_ERROR Value used for regular ADMISSION_PRI elements 706 o 2: HETEROGENEOUS This element encountered heterogeneous merge 708 Following the policies outlined in [RFC5226], numbers in the range 709 3-127 are allocated according to the "IETF Review" policy, numbers in 710 the range 128-240 as "First Come First Served" and numbers between 711 241-255 are reserved for "Private Use". Value 1 is Reserved (for 712 consistency with [RFC3181] Error Code values). 714 The present document defines an ALRP Namespace field in section 3.2 715 that contains a numerical value identifying the namespace of the 716 application-level resource priority. The IANA already maintains the 717 Resource-Priority Namespaces registry (under the SIP Parameters) 718 listing all such namespace. However, that registry does not 719 currently allocate a numerical value to each namespace. Hence, this 720 document requests the IANA to extend the Resource-Priority Namespace 721 registry in the following ways: 723 o a new column should be added to the registry 725 o the title of the new column should be "Namespace Numerical Value 726 *" 728 o in the Legend, add a line saying "Namespace Numerical Value = the 729 unique numerical value identifying the namespace" 731 o add a line at the bottom of the registry stating the following "* 732 : [RFCXXX] " where XXX is the RFC number of the present document 734 o allocate an actual numerical value to each namespace in the 735 registry and state that value in the new "Namespace numerical 736 Value *" column. 738 A numerical value should be allocated immediately by IANA to all 739 existing namespace. Then, in the future, IANA should automatically 740 allocate a numerical value to any new namespace added to the 741 registry. 743 The present document defines an ALRP Priority field in section 3.2 744 that contains a numerical value identifying the actual application- 745 level resource priority within the application-level resource 746 priority namespace. The IANA already maintains the Resource-Priority 747 Priority-values registry (under the SIP Parameters) listing all such 748 priorities. However, that registry does not currently allocate a 749 numerical value to each priority-value. Hence, this document 750 requests the IANA to extend the Resource-Priority Priority-Values 751 registry in the following ways: 753 o for each namespace, the registry should be structured with two 754 columns 756 o the title of the first column should read "Priority Values (least 757 to greatest)" 759 o the first column should list all the values currently defined in 760 the registry (e.g. for the drsn namespace: "routine", "priority", 761 "immediate", "flash", "flash-override", "flash-override-override" 762 for the drsn namespace) 764 o the title of the second column should read "Priority Numerical 765 Value *" 767 o At the bottom of the registry, add a "Legend" with a line saying 768 "Priority Numerical Value = the unique numerical value identifying 769 the priority within a namespace" 771 o add a line at the bottom of the registry stating the following "* 772 : [RFCXXX] " where XXX is the RFC number of the present document 774 o allocate an actual numerical value to each and state that value in 775 the new "Priority Numerical Value *" column. 777 A numerical value should be allocated immediately by IANA to all 778 existing priority. Then, in the future, IANA should automatically 779 allocate a numerical value to any new namespace added to the 780 registry. The numerical value must be unique within each namespace. 781 For the initial allocation, within each namespace, values should be 782 allocated in decreasing order ending with 0 (so that the greatest 783 priority is always allocated value 0). For example, in the drsn 784 namespace, "routine" would be allocated numerical value 5 and "flash- 785 override-override" would be allocated numerical value 0. 787 6. Acknowledgments 789 We would like to thank An Nguyen for his encouragement to address 790 this topic and ongoing comments. Also, this document borrows heavily 791 from some of the work of S. Herzog on Preemption Priority Policy 792 Element [RFC3181]. Dave Oran and Janet Gunn provided useful input 793 into this document. Thanks to Magnus Westerlund, Cullen Jennings and 794 Ross Callon for helping clarify applicability of the mechanisms 795 defined in this document. 797 7. References 798 7.1. Normative References 800 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 801 February 1997. 803 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 804 Requirement Levels", BCP 14, RFC 2119, March 1997. 806 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 807 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 808 Functional Specification", RFC 2205, September 1997. 810 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 811 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 812 October 1998. 814 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 815 RFC 2711, October 1999. 817 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 818 Authentication", RFC 2747, January 2000. 820 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 821 RFC 2750, January 2000. 823 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 824 Authentication -- Updated Message Type Value", RFC 3097, 825 April 2001. 827 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 828 RFC 3181, October 2001. 830 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 831 A., Peterson, J., Sparks, R., Handley, M., and E. 832 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 833 June 2002. 835 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 836 Priority for the Session Initiation Protocol (SIP)", 837 RFC 4412, February 2006. 839 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 840 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 841 May 2008. 843 7.2. Informative References 845 [I-D.dasmith-mpls-ip-options] 846 Jaeger, W., Mullooly, J., Scholl, T., and D. Smith, 847 "Requirements for Label Edge Router Forwarding of IPv4 848 Option Packets", draft-dasmith-mpls-ip-options-01 (work in 849 progress), October 2008. 851 [I-D.ietf-dime-diameter-qos] 852 Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 853 and G. Zorn, "Diameter Quality of Service Application", 854 draft-ietf-dime-diameter-qos-06 (work in progress), 855 July 2008. 857 [I-D.ietf-dime-qos-parameters] 858 Korhonen, J. and H. Tschofenig, "Quality of Service 859 Parameters for Usage with the AAA Framework", 860 draft-ietf-dime-qos-parameters-06 (work in progress), 861 May 2008. 863 [I-D.ietf-l3vpn-2547bis-mcast] 864 Aggarwal, R., Bandi, S., Cai, Y., Morin, T., Rekhter, Y., 865 Rosen, E., Wijnands, I., and S. Yasukawa, "Multicast in 866 MPLS/BGP IP VPNs", draft-ietf-l3vpn-2547bis-mcast-07 (work 867 in progress), July 2008. 869 [I-D.ietf-nsis-qspec] 870 Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP 871 QSPEC Template", draft-ietf-nsis-qspec-20 (work in 872 progress), April 2008. 874 [I-D.ietf-tsvwg-rsvp-l3vpn] 875 Davie, B., Faucheur, F., and A. Narayanan, "Support for 876 RSVP in Layer 3 VPNs", draft-ietf-tsvwg-rsvp-l3vpn-00 877 (work in progress), July 2008. 879 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 880 Behringer, M. and F. Faucheur, "Applicability of Keying 881 Methods for RSVP Security", 882 draft-ietf-tsvwg-rsvp-security-groupkeying-01 (work in 883 progress), July 2008. 885 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 886 for Policy-based Admission Control", RFC 2753, 887 January 2000. 889 [RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 890 Herzog, S., and R. Hess, "Identity Representation for 891 RSVP", RFC 3182, October 2001. 893 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 894 "Integration of Resource Management and Session Initiation 895 Protocol (SIP)", RFC 3312, October 2002. 897 [RFC3689] Carlberg, K. and R. Atkinson, "General Requirements for 898 Emergency Telecommunication Service (ETS)", RFC 3689, 899 February 2004. 901 [RFC3690] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 902 for Emergency Telecommunication Service (ETS)", RFC 3690, 903 February 2004. 905 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 906 Constraints Model for Diffserv-aware MPLS Traffic 907 Engineering", RFC 4125, June 2005. 909 [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth 910 Constraints Model for Diffserv-aware MPLS Traffic 911 Engineering & Performance Comparisons", RFC 4126, 912 June 2005. 914 [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints 915 Model for Diffserv-aware MPLS Traffic Engineering", 916 RFC 4127, June 2005. 918 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 919 Properties", RFC 4230, December 2005. 921 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 922 Networks (VPNs)", RFC 4364, February 2006. 924 [RFC4542] Baker, F. and J. Polk, "Implementing an Emergency 925 Telecommunications Service (ETS) for Real-Time Services in 926 the Internet Protocol Suite", RFC 4542, May 2006. 928 [RFC4659] De Clercq, J., Ooms, D., Carugi, M., and F. Le Faucheur, 929 "BGP-MPLS IP Virtual Private Network (VPN) Extension for 930 IPv6 VPN", RFC 4659, September 2006. 932 Appendix A. Examples of Bandwidth Allocation Model for Admission 933 Priority 935 Sections A.1 and A.2 respectively illustrate how the Maximum 936 Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) 937 ([RFC4127]) can be used for support of admission priority. The 938 Maximum Allocation model with Reservation (MAR) ([RFC4126]) could 939 also be used in a similar manner for support of admission priority. 940 Section A.3 illustrates how a simple "Priority Bypass Model" can also 941 be used for support of admission priority. 943 For simplicity, operations with only a single "priority" level 944 (beyond non-priority) are illustrated here; However, the reader will 945 appreciate that operations with multiple priority levels can easily 946 be supported with these models. 948 In all the figures below: 950 x represents a non-priority session 952 o represents a priority session 954 A.1. Admission Priority with Maximum Allocation Model (MAM) 956 This section illustrates operations of admission priority when a 957 Maximum Allocation Model (MAM) is used for bandwidth allocation 958 across non-priority traffic and priority traffic. A property of the 959 Maximum Allocation Model is that priority traffic can not use more 960 than the bandwidth made available to priority traffic (even if the 961 non-priority traffic is not using all of the bandwidth available for 962 it). 964 ----------------------- 965 ^ ^ ^ | | ^ 966 . . . | | . 967 Total . . . | | . Bandwidth 968 (1)(2)(3) | | . Available 969 Engi- . . . | | . for non-priority use 970 neered .or.or. | | . 971 . . . | | . 972 Capacity. . . | | . 973 v . . | | v 974 . . |--------------| --- 975 v . | | ^ 976 . | | . Bandwidth available for 977 v | | v priority use 978 ------------------------- 980 Figure 4: MAM Bandwidth Allocation 982 Figure 4 shows a link within a routed network conforming to this 983 document. On this link are two amounts of bandwidth available to two 984 types of traffic: non-priority and priority. 986 If the non-priority traffic load reaches the maximum bandwidth 987 available for non-priority, no additional non-priority sessions can 988 be accepted even if the bandwidth reserved for priority traffic is 989 not currently fully utilized. 991 With the Maximum Allocation Model, in the case where the priority 992 load reaches the maximum bandwidth reserved for priority sessions, no 993 additional priority sessions can be accepted. 995 As illustrated in Figure 4, an operator may map the MAM model onto 996 the Engineered Capacity limits according to different policies. At 997 one extreme, where the proportion of priority traffic is reliably 998 known to be fairly small at all times and where there may be some 999 safety margin factored in the engineered capacity limits, the 1000 operator may decide to configure the bandwidth available for non- 1001 priority use to the full engineered capacity limits; effectively 1002 allowing the priority traffic to ride within the safety margin of 1003 this engineered capacity. This policy can be seen as an economically 1004 attractive approach as all of the engineered capacity is made 1005 available to non-priority sessions. This policy is illustrated as 1006 (1) in Figure 4. As an example, if the engineered capacity limit on 1007 a given link is X, the operator may configure the bandwidth available 1008 to non-priority traffic to X, and the bandwidth available to priority 1009 traffic to 5% of X. At the other extreme, where the proportion of 1010 priority traffic may be significant at times and the engineered 1011 capacity limits are very tight, the operator may decide to configure 1012 the bandwidth available to non-priority traffic and the bandwidth 1013 available to priority traffic such that their sum is equal to the 1014 engineered capacity limits. This guarantees that the total load 1015 across non-priority and priority traffic is always below the 1016 engineered capacity and, in turn, guarantees there will never be any 1017 QoS degradation. However, this policy is less attractive 1018 economically as it prevents non-priority sessions from using the full 1019 engineered capacity, even when there is no or little priority load, 1020 which is the majority of time. This policy is illustrated as (3) in 1021 Figure 4. As an example, if the engineered capacity limit on a given 1022 link is X, the operator may configure the bandwidth available to non- 1023 priority traffic to 95% of X, and the bandwidth available to priority 1024 traffic to 5% of X. Of course, an operator may also strike a balance 1025 anywhere in between these two approaches. This policy is illustrated 1026 as (2) in Figure 4. 1028 Figure 5 shows some of the non-priority capacity of this link being 1029 used. 1031 ----------------------- 1032 ^ ^ ^ | | ^ 1033 . . . | | . 1034 Total . . . | | . Bandwidth 1035 . . . | | . Available 1036 Engi- . . . | | . for non-priority use 1037 neered .or.or. |xxxxxxxxxxxxxx| . 1038 . . . |xxxxxxxxxxxxxx| . 1039 Capacity. . . |xxxxxxxxxxxxxx| . 1040 v . . |xxxxxxxxxxxxxx| v 1041 . . |--------------| --- 1042 v . | | ^ 1043 . | | . Bandwidth available for 1044 v | | v priority use 1045 ------------------------- 1047 Figure 5: Partial load of non-priority calls 1049 Figure 6 shows the same amount of non-priority load being used at 1050 this link, and a small amount of priority bandwidth being used. 1052 ----------------------- 1053 ^ ^ ^ | | ^ 1054 . . . | | . 1055 Total . . . | | . Bandwidth 1056 . . . | | . Available 1057 Engi- . . . | | . for non-priority use 1058 neered .or.or. |xxxxxxxxxxxxxx| . 1059 . . . |xxxxxxxxxxxxxx| . 1060 Capacity. . . |xxxxxxxxxxxxxx| . 1061 v . . |xxxxxxxxxxxxxx| v 1062 . . |--------------| --- 1063 v . | | ^ 1064 . | | . Bandwidth available for 1065 v |oooooooooooooo| v priority use 1066 ------------------------- 1068 Figure 6: Partial load of non-priority calls & partial load of 1069 priority calls Calls 1071 Figure 7 shows the case where non-priority load equates or exceeds 1072 the maximum bandwidth available to non-priority traffic. Note that 1073 additional non-priority sessions would be rejected even if the 1074 bandwidth reserved for priority sessions is not fully utilized. 1076 ----------------------- 1077 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1078 . . . |xxxxxxxxxxxxxx| . 1079 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1080 . . . |xxxxxxxxxxxxxx| . Available 1081 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1082 neered .or.or. |xxxxxxxxxxxxxx| . 1083 . . . |xxxxxxxxxxxxxx| . 1084 Capacity. . . |xxxxxxxxxxxxxx| . 1085 v . . |xxxxxxxxxxxxxx| v 1086 . . |--------------| --- 1087 v . | | ^ 1088 . | | . Bandwidth available for 1089 v |oooooooooooooo| v priority use 1090 ------------------------- 1092 Figure 7: Full non-priority load & partial load of priority calls 1094 Figure 8 shows the case where the priority traffic equates or exceeds 1095 the bandwidth reserved for such priority traffic. 1097 In that case additional priority sessions could not be accepted. 1098 Note that this does not mean that such sessions are dropped 1099 altogether: they may be handled by mechanisms, which are beyond the 1100 scope of this particular document (such as establishment through 1101 preemption of existing non-priority sessions, or such as queuing of 1102 new priority session requests until capacity becomes available again 1103 for priority traffic). 1105 ----------------------- 1106 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1107 . . . |xxxxxxxxxxxxxx| . 1108 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1109 . . . |xxxxxxxxxxxxxx| . Available 1110 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1111 neered .or.or. |xxxxxxxxxxxxxx| . 1112 . . . |xxxxxxxxxxxxxx| . 1113 Capacity. . . | | . 1114 v . . | | v 1115 . . |--------------| --- 1116 v . |oooooooooooooo| ^ 1117 . |oooooooooooooo| . Bandwidth available for 1118 v |oooooooooooooo| v priority use 1119 ------------------------- 1121 Figure 8: Partial non-priority load & Full priority load 1123 A.2. Admission Priority with Russian Dolls Model (RDM) 1125 This section illustrates operations of admission priority when a 1126 Russian Dolls Model (RDM) is used for bandwidth allocation across 1127 non-priority traffic and priority traffic. A property of the Russian 1128 Dolls Model is that priority traffic can use the bandwidth which is 1129 not currently used by non-priority traffic. 1131 As with the MAM model, an operator may map the RDM model onto the 1132 Engineered Capacity limits according to different policies. The 1133 operator may decide to configure the bandwidth available for non- 1134 priority use to the full engineered capacity limits; As an example, 1135 if the engineered capacity limit on a given link is X, the operator 1136 may configure the bandwidth available to non-priority traffic to X, 1137 and the bandwidth available to non-priority and priority traffic to 1138 105% of X. 1140 Alternatively, the operator may decide to configure the bandwidth 1141 available to non-priority and priority traffic to the engineered 1142 capacity limits; As an example, if the engineered capacity limit on a 1143 given link is X, the operator may configure the bandwidth available 1144 to non-priority traffic to 95% of X, and the bandwidth available to 1145 non-priority and priority traffic to X. 1147 Finally, the operator may decide to strike a balance in between. The 1148 considerations presented for these policies in the previous section 1149 in the MAM context are equally applicable to RDM. 1151 Figure 9 shows the case where only some of the bandwidth available to 1152 non-priority traffic is being used and a small amount of priority 1153 traffic is in place. In that situation both new non-priority 1154 sessions and new priority sessions would be accepted. 1156 -------------------------------------- 1157 |xxxxxxxxxxxxxx| . ^ 1158 |xxxxxxxxxxxxxx| . Bandwidth . 1159 |xxxxxxxxxxxxxx| . Available for . 1160 |xxxxxxxxxxxxxx| . non-priority . 1161 |xxxxxxxxxxxxxx| . use . 1162 |xxxxxxxxxxxxxx| . . Bandwidth 1163 | | . . available for 1164 | | v . non-priority 1165 |--------------| --- . and priority 1166 | | . use 1167 | | . 1168 |oooooooooooooo| v 1169 --------------------------------------- 1171 Figure 9: Partial non-priority load & Partial Aggregate load 1173 Figure 10 shows the case where all of the bandwidth available to non- 1174 priority traffic is being used and a small amount of priority traffic 1175 is in place. In that situation new priority sessions would be 1176 accepted but new non-priority sessions would be rejected. 1178 -------------------------------------- 1179 |xxxxxxxxxxxxxx| . ^ 1180 |xxxxxxxxxxxxxx| . Bandwidth . 1181 |xxxxxxxxxxxxxx| . Available for . 1182 |xxxxxxxxxxxxxx| . non-priority . 1183 |xxxxxxxxxxxxxx| . use . 1184 |xxxxxxxxxxxxxx| . . Bandwidth 1185 |xxxxxxxxxxxxxx| . . available for 1186 |xxxxxxxxxxxxxx| v . non-priority 1187 |--------------| --- . and priority 1188 | | . use 1189 | | . 1190 |oooooooooooooo| v 1191 --------------------------------------- 1193 Figure 10: Full non-priority load & Partial Aggregate load 1195 Figure 11 shows the case where only some of the bandwidth available 1196 to non-priority traffic is being used and a heavy load of priority 1197 traffic is in place. In that situation both new non-priority 1198 sessions and new priority sessions would be accepted. Note that, as 1199 illustrated in Figure 10, priority sessions use some of the bandwidth 1200 currently not used by non-priority traffic. 1202 -------------------------------------- 1203 |xxxxxxxxxxxxxx| . ^ 1204 |xxxxxxxxxxxxxx| . Bandwidth . 1205 |xxxxxxxxxxxxxx| . Available for . 1206 |xxxxxxxxxxxxxx| . non-priority . 1207 |xxxxxxxxxxxxxx| . use . 1208 | | . . Bandwidth 1209 | | . . available for 1210 |oooooooooooooo| v . non-priority 1211 |--------------| --- . and priority 1212 |oooooooooooooo| . use 1213 |oooooooooooooo| . 1214 |oooooooooooooo| v 1215 --------------------------------------- 1217 Figure 11: Partial non-priority load & Heavy Aggregate load 1219 Figure 12 shows the case where all of the bandwidth available to non- 1220 priority traffic is being used and all of the remaining available 1221 bandwidth is used by priority traffic. In that situation new non- 1222 priority sessions would be rejected. In that situation new priority 1223 sessions could not be accepted right away. Those priority sessions 1224 may be handled by mechanisms, which are beyond the scope of this 1225 particular document (such as established through preemption of 1226 existing non-priority sessions, or such as queuing of new priority 1227 session requests until capacity becomes available again for priority 1228 traffic). 1230 -------------------------------------- 1231 |xxxxxxxxxxxxxx| . ^ 1232 |xxxxxxxxxxxxxx| . Bandwidth . 1233 |xxxxxxxxxxxxxx| . Available for . 1234 |xxxxxxxxxxxxxx| . non-priority . 1235 |xxxxxxxxxxxxxx| . use . 1236 |xxxxxxxxxxxxxx| . . Bandwidth 1237 |xxxxxxxxxxxxxx| . . available for 1238 |xxxxxxxxxxxxxx| v . non-priority 1239 |--------------| --- . and priority 1240 |oooooooooooooo| . use 1241 |oooooooooooooo| . 1242 |oooooooooooooo| v 1243 --------------------------------------- 1245 Figure 12: Full non-priority load & Full Aggregate load 1247 A.3. Admission Priority with Priority Bypass Model (PrBM) 1249 This section illustrates operations of admission priority when a 1250 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1251 across non-priority traffic and priority traffic. With the Priority 1252 Bypass Model, non-priority traffic is subject to resource based 1253 admission control while priority traffic simply bypasses the resource 1254 based admission control. In other words: 1256 o when a non-priority session arrives, this session is subject to 1257 bandwidth admission control and is accepted if the current total 1258 load (aggregate over non-priority and priority traffic) is below 1259 the engineered/allocated bandwidth. 1261 o when a priority session arrives, this session is admitted 1262 regardless of the current load. 1264 A property of this model is that a priority session is never 1265 rejected. 1267 The rationale for this simple scheme is that, in practice in some 1268 networks: 1270 o the volume of priority sessions is very low for the vast majority 1271 of time, so it may not be economical to completely set aside 1272 bandwidth for priority sessions and preclude the utilization of 1273 this bandwidth by normal sessions in normal situations 1275 o even in emergency periods where priority sessions are more heavily 1276 used, those always still represent a fairly small proportion of 1277 the overall load which can be absorbed within the safety margin of 1278 the engineered capacity limits. Thus, even if they are admitted 1279 beyond the engineered bandwidth threshold, they are unlikely to 1280 result in noticeable QoS degradation. 1282 As with the MAM and RDM model, an operator may map the Priority 1283 Bypass model onto the Engineered Capacity limits according to 1284 different policies. The operator may decide to configure the 1285 bandwidth limit for admission of non-priority traffic to the full 1286 engineered capacity limits; As an example, if the engineered capacity 1287 limit on a given link is X, the operator may configure the bandwidth 1288 limit for non-priority traffic to X. Alternatively, the operator may 1289 decide to configure the bandwidth limit for non-priority traffic to 1290 below the engineered capacity limits (so that the sum of the non- 1291 priority and priority traffic stays below the engineered capacity); 1292 As an example, if the engineered capacity limit on a given link is X, 1293 the operator may configure the bandwidth limit for non-priority 1294 traffic to 95% of X. Finally, the operator may decide to strike a 1295 balance in between. The considerations presented for these policies 1296 in the previous sections in the MAM and RDM contexts are equally 1297 applicable to the Priority Bypass Model. 1299 Figure 13 illustrates the bandwidth allocation with the Priority 1300 Bypass Model. 1302 ----------------------- 1303 ^ ^ | | ^ 1304 . . | | . 1305 Total . . | | . Bandwidth Limit 1306 (1) (2) | | . (on non-priority + priority) 1307 Engi- . . | | . for admission 1308 neered . or . | | . of non-priority traffic 1309 . . | | . 1310 Capacity. . | | . 1311 v . | | v 1312 . |--------------| --- 1313 . | | 1314 v | | 1315 | | 1317 Figure 13: Priority Bypass Model Bandwidth Allocation 1319 Figure 14 shows some of the non-priority capacity of this link being 1320 used. In this situation, both new non-priority and new priority 1321 sessions would be accepted. 1323 ----------------------- 1324 ^ ^ |xxxxxxxxxxxxxx| ^ 1325 . . |xxxxxxxxxxxxxx| . 1326 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1327 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1328 Engi- . . | | . for admission 1329 neered . or . | | . of non-priority traffic 1330 . . | | . 1331 Capacity. . | | . 1332 v . | | v 1333 . |--------------| --- 1334 . | | 1335 v | | 1336 | | 1338 Figure 14: Partial load of non-priority calls 1340 Figure 15 shows the same amount of non-priority load being used at 1341 this link, and a small amount of priority bandwidth being used. In 1342 this situation, both new non-priority and new priority sessions would 1343 be accepted. 1345 ----------------------- 1346 ^ ^ |xxxxxxxxxxxxxx| ^ 1347 . . |xxxxxxxxxxxxxx| . 1348 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1349 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1350 Engi- . . |oooooooooooooo| . for admission 1351 neered . or . | | . of non-priority traffic 1352 . . | | . 1353 Capacity. . | | . 1354 v . | | v 1355 . |--------------| --- 1356 . | | 1357 v | | 1358 | | 1360 Figure 15: Partial load of non-priority calls & partial load of 1361 priority calls 1363 Figure 16 shows the case where aggregate non-priority and priority 1364 load exceeds the bandwidth limit for admission of non-priority 1365 traffic. In this situation, any new non-priority session is rejected 1366 while any new priority session is admitted. 1368 ----------------------- 1369 ^ ^ |xxxxxxxxxxxxxx| ^ 1370 . . |xxxxxxxxxxxxxx| . 1371 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1372 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1373 Engi- . . |oooooooooooooo| . for admission 1374 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1375 . . |xxoxxxxxxoxxxx| . 1376 Capacity. . |oxxxooooxxxxoo| . 1377 v . |xxoxxxooxxxxxx| v 1378 . |--------------| --- 1379 . |oooooooooooooo| 1380 v | | 1381 | | 1383 Figure 16: Full non-priority load 1385 Appendix B. Example Usages of RSVP Extensions 1387 This section provides examples of how RSVP extensions defined in this 1388 document can be used (in conjunctions with other RSVP functionality 1389 and SIP functionality) to enforce different hypothetical policies for 1390 handling Emergency sessions in a given administrative domain. This 1391 Appendix does not provide additional specification. It is only 1392 included in this document for illustration purposes. 1394 We assume an environment where SIP is used for session control and 1395 RSVP is used for resource reservation. 1397 In a mild abuse of language, we refer here to "Call Queueing" as the 1398 set of "session" layer capabilities that may be implemented by SIP 1399 user agents to influence their treatment of SIP requests. This may 1400 include the ability to "queue" session requests when those can not be 1401 immediately honored (in some cases with the notion of "bumping", or 1402 "displacement", of less important session requests from that queue). 1403 It may include additional mechanisms such as exemption from certain 1404 network management controls, and alternate routing. 1406 We only mention below the RSVP policy elements that are to be 1407 enforced by PEPs. It is assumed that these policy elements are set 1408 at administrative domain boundaries by PDPs. The Admission Priority 1409 and Preemption Priority RSVP policy elements are set by PDPs as a 1410 result of processing the Application Level Resource Priority Policy 1411 Element (which is carried in RSVP messages). 1413 If one wants to implement an emergency service purely based on Call 1414 Queueing, one can achieve this by signaling emergency sessions: 1416 o using "Resource-Priority" Header in SIP 1418 o not using Admission-Priority Policy Element in RSVP 1420 o not using Preemption Policy Element in RSVP 1422 If one wants to implement an emergency service based on Call Queueing 1423 and on "prioritized access to network layer resources", one can 1424 achieve this by signaling emergency sessions: 1426 o using "Resource-Priority" Header in SIP 1428 o using Admission-Priority Policy Element in RSVP 1430 o not using Preemption Policy Element in RSVP 1432 Emergency sessions will not result in preemption of any session. 1433 Different bandwidth allocation models can be used to offer different 1434 "prioritized access to network resources". Just as examples, this 1435 includes strict setting aside of capacity for emergency sessions as 1436 well as simple bypass of admission limits for emergency sessions. 1438 If one wants to implement an emergency service based on Call 1439 Queueing, on "prioritized access to network layer resources", and 1440 ensures that (say) "Emergency-1" sessions can preempt "Emergency-2" 1441 sessions, but non-emergency sessions are not affected by preemption, 1442 one can do that by signaling emergency sessions: 1444 o using "Resource-Priority" Header in SIP 1446 o using Admission-Priority Policy Element in RSVP 1448 o using Preemption Policy Element in RSVP with: 1450 * setup (Emergency-1) > defending (Emergency-2) 1452 * setup (Emergency-2) <= defending (Emergency-1) 1454 * setup (Emergency-1) <= defending (Non-Emergency) 1456 * setup (Emergency-2) <= defending (Non-Emergency) 1458 If one wants to implement an emergency service based on Call 1459 Queueing, on "prioritized access to network layer resources", and 1460 ensure that "emergency" sessions can preempt regular sessions, one 1461 could do that by signaling emergency sessions: 1463 o using "Resource-Priority" Header in SIP 1465 o using Admission-Priority Policy Element in RSVP 1467 o using Preemption Policy Element in RSVP with: 1469 * setup (Emergency) > defending (Non-Emergency) 1471 * setup (Non-Emergency) <= defending (Emergency) 1473 If one wants to implement an emergency service based on Call 1474 Queueing, on "prioritized access to network layer resources", and 1475 ensure that "emergency" sessions can partially preempt regular 1476 sessions (ie reduce their reservation size), one could do that by 1477 signaling emergency sessions: 1479 o using "Resource-Priority" Header in SIP 1481 o using Admission-Priority Policy Element in RSVP 1483 o using Preemption in Policy Element RSVP with: 1485 * setup (Emergency) > defending (Non-Emergency) 1487 * setup (Non-Emergency) <= defending (Emergency) 1489 o activate RFC4495 RSVP Bandwidth Reduction mechanisms 1491 Authors' Addresses 1493 Francois Le Faucheur 1494 Cisco Systems 1495 Greenside, 400 Avenue de Roumanille 1496 Sophia Antipolis 06410 1497 France 1499 Phone: +33 4 97 23 26 19 1500 Email: flefauch@cisco.com 1501 James Polk 1502 Cisco Systems 1503 2200 East President George Bush Highway 1504 Richardson, TX 75082-3550 1505 United States 1507 Phone: +1 972 813 5208 1508 Email: jmpolk@cisco.com 1510 Ken Carlberg 1511 G11 1512 123a Versailles Circle 1513 Towson, MD 21204 1514 United States 1516 Email: carlberg@g11.org.uk 1518 Full Copyright Statement 1520 Copyright (C) The IETF Trust (2008). 1522 This document is subject to the rights, licenses and restrictions 1523 contained in BCP 78, and except as set forth therein, the authors 1524 retain all their rights. 1526 This document and the information contained herein are provided on an 1527 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1528 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1529 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1530 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1531 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1532 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1534 Intellectual Property 1536 The IETF takes no position regarding the validity or scope of any 1537 Intellectual Property Rights or other rights that might be claimed to 1538 pertain to the implementation or use of the technology described in 1539 this document or the extent to which any license under such rights 1540 might or might not be available; nor does it represent that it has 1541 made any independent effort to identify any such rights. Information 1542 on the procedures with respect to rights in RFC documents can be 1543 found in BCP 78 and BCP 79. 1545 Copies of IPR disclosures made to the IETF Secretariat and any 1546 assurances of licenses to be made available, or the result of an 1547 attempt made to obtain a general license or permission for the use of 1548 such proprietary rights by implementers or users of this 1549 specification can be obtained from the IETF on-line IPR repository at 1550 http://www.ietf.org/ipr. 1552 The IETF invites any interested party to bring to its attention any 1553 copyrights, patents or patent applications, or other proprietary 1554 rights that may cover technology that may be required to implement 1555 this standard. Please address the information to the IETF at 1556 ietf-ipr@ietf.org.