idnits 2.17.1 draft-ietf-tsvwg-emergency-rsvp-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5135 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: 'RFC-XXX' is mentioned on line 662, but not defined == Missing Reference: 'RFCXXX' is mentioned on line 741, 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 (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 2 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: September 9, 2010 K. Carlberg 6 G11 7 March 8, 2010 9 Resource ReSerVation Protocol (RSVP) Extensions for Admission Priority 10 draft-ietf-tsvwg-emergency-rsvp-15.txt 12 Abstract 14 Some applications require the ability to provide an elevated 15 probability of session establishment to specific sessions in times of 16 network congestion. When supported over the Internet Protocol suite, 17 this may be facilitated through a network layer admission control 18 solution that supports prioritized access to resources (e.g., 19 bandwidth). These resources may be explicitly set aside for 20 prioritized sessions, or may be shared with other sessions. This 21 document specifies extensions to the Resource reSerVation Protocol 22 (RSVP) that can be used to support such an admission priority 23 capability at the network layer. 25 Based on current security concerns, these extensions are intended for 26 use in a single administrative domain. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on September 9, 2010. 51 Copyright Notice 53 Copyright (c) 2010 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 81 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 82 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 5 83 3. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 84 4. Overview of RSVP extensions and Operations . . . . . . . . . . 5 85 4.1. Operations of Admission Priority . . . . . . . . . . . . . 7 86 5. New Policy Elements . . . . . . . . . . . . . . . . . . . . . 8 87 5.1. Admission Priority Policy Element . . . . . . . . . . . . 9 88 5.1.1. Admission Priority Merging Rules . . . . . . . . . . . 10 89 5.2. Application-Level Resource Priority Policy Element . . . . 11 90 5.2.1. Application-Level Resource Priority Modifying and 91 Merging Rules . . . . . . . . . . . . . . . . . . . . 12 92 5.3. Default Handling . . . . . . . . . . . . . . . . . . . . . 12 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 94 6.1. Use of RSVP Authentication between RSVP neighbors . . . . 14 95 6.2. Use of INTEGRITY object within the POLICY_DATA object . . 14 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 97 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 100 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 101 Appendix A. Examples of Bandwidth Allocation Model for 102 Admission Priority . . . . . . . . . . . . . . . . . 19 103 A.1. Admission Priority with Maximum Allocation Model (MAM) . . 20 104 A.2. Admission Priority with Russian Dolls Model (RDM) . . . . 24 105 A.3. Admission Priority with Priority Bypass Model (PrBM) . . . 27 106 Appendix B. Example Usages of RSVP Extensions . . . . . . . . . . 30 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 109 1. Introduction 111 Some applications require the ability to provide an elevated 112 probability of session establishment to specific sessions in times of 113 network congestion. 115 Solutions to meet this requirement for elevated session establishment 116 probability may involve session layer capabilities prioritizing 117 access to resources controlled by the session control function. As 118 an example, entities involved in session control (such as SIP user 119 agents, when the Session Initiation Protocol (SIP) [RFC3261], is the 120 session control protocol in use) can influence their treatment of 121 session establishment requests (such as SIP requests). This may 122 include the ability to "queue" session establishment requests when 123 those can not be immediately honored (in some cases with the notion 124 of "bumping", or "displacement", of less important session 125 establishment requests from that queue). It may include additional 126 mechanisms such as exemption from certain network management 127 controls, and alternate routing. 129 Solutions to meet the requirement for elevated session establishment 130 probability may also take advantage of network layer admission 131 control mechanisms supporting admission priority. Networks usually 132 have engineered capacity limits that characterize the maximum load 133 that can be handled (say, on any given link) for a class of traffic 134 while satisfying the quality of service requirements of that traffic 135 class. Admission priority may involve setting aside some network 136 resources (e.g. Bandwidth) out of the engineered capacity limits for 137 the prioritized sessions only. Or alternatively, it may involve 138 allowing the prioritized sessions to seize additional resources 139 beyond the engineered capacity limits applied to normal sessions. 140 This document specifies the necessary extensions to support such 141 admission priority when network layer admission control is performed 142 using the Resource reSerVation Protocol (RSVP) ([RFC2205]). 144 [RFC3181] specifies the Signaled Preemption Priority Policy Element 145 that can be signaled in RSVP so that network node may take into 146 account this policy element in order to preempt some previously 147 admitted low priority sessions in order to make room for a newer, 148 higher priority session. In contrast, this document specifies new 149 RSVP extensions to increase the probability of session establishment 150 without preemption of existing sessions. This is achieved by 151 engineered capacity techniques in the form of bandwidth allocation 152 models. In particular this document specifies two new RSVP Policy 153 Elements allowing the admission priority to be conveyed inside RSVP 154 signaling messages so that RSVP nodes can enforce selective bandwidth 155 admission control decision based on the session admission priority. 156 Appendix A of this document also provides examples of bandwidth 157 allocation models which can be used by RSVP-routers to enforce such 158 admission priority on every link. A given reservation may be 159 signaled with the admission priority extensions specified in the 160 present document, with the preemption priority specified in [RFC3181] 161 or with both. 163 1.1. Terminology 165 This document assumes the terminology defined in [RFC2753]. For 166 convenience, the definition of a few key terms is repeated here: 168 o Policy Decision Point (PDP): The point where policy decisions are 169 made. 171 o Local Policy Decision Point (LPDP): PDP local to the network 172 element. 174 o Policy Enforcement Point (PEP): The point where the policy 175 decisions are actually enforced. 177 o Policy Ignorant Node (PIN): A network element that does not 178 explicitly support policy control using the mechanisms defined in 179 [RFC2753]. 181 2. Applicability Statement 183 A subset of RSVP messages are signaled with the Router Alert Option 184 (RAO)([RFC2113],[RFC2711]). The security aspects and common 185 practices around the use of the current IP Router Alert option and 186 consequences on the use of IP Router Alert by applications such as 187 RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations]. 188 Based on those, the extensions defined in this document are intended 189 for use within a single administrative domain. Thus, in particular, 190 the extensions defined in this document are not intended for use end 191 to end on the Internet. 193 3. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 4. Overview of RSVP extensions and Operations 201 Let us consider the case where a session requires elevated 202 probability of establishment, and more specifically that the 203 preference to be granted to this session is in terms of network layer 204 "admission priority" (as opposed to preference granted through 205 preemption of existing sessions). By "admission priority" we mean 206 allowing the priority session to seize network layer resources from 207 the engineered capacity that has been set-aside for priority sessions 208 (and not made available to normal sessions), or alternatively 209 allowing the priority session to seize additional resources beyond 210 the engineered capacity limits applied to normal sessions. 212 Session establishment can be made conditional on resource-based and 213 policy-based network layer admission control achieved via RSVP 214 signaling. In the case where the session control protocol is SIP, 215 the use of RSVP-based admission control in conjunction with SIP is 216 specified in [RFC3312]. 218 Devices involved in the session establishment are expected to be 219 aware of the application-level priority requirements of prioritized 220 sessions. For example, considering the case where the session 221 control protocol is SIP, the SIP user agents may be made aware of the 222 resource priority requirements of a given session using the 223 "Resource-Priority" header mechanism specified in [RFC4412]. The 224 end-devices involved in the upper-layer session establishment simply 225 need to copy the application-level resource priority requirements 226 (e.g. As communicated in SIP "Resource-Priority" header) inside the 227 new RSVP Application-Level Resource Priority Policy Element defined 228 in this document. 230 Conveying the application-level resource priority requirements inside 231 the RSVP message allows this application level requirement to be 232 mapped/remapped into a different RSVP "admission priority" at a 233 policy boundary based on the policy applicable in that policy area. 234 In a typical model (see [RFC2753]) where PDPs control PEPs at the 235 periphery of the policy area (e.g. On the first hop router), PDPs 236 would interpret the RSVP Application-Level Resource Priority Policy 237 Element and map the requirement of the prioritized session into an 238 RSVP "admission priority" level. Then, PDPs would convey this 239 information inside the new Admission Priority Policy Element defined 240 in this document. This way, the RSVP admission priority can be 241 communicated to downstream PEPs (i.e. RSVP Routers) of the same 242 policy domain, which have LPDPs but no controlling PDP. In turn, 243 this means the necessary RSVP Admission priority can be enforced at 244 every RSVP hop, including all the (possibly many) hops which do not 245 have any understanding of Application-Level Resource Priority 246 semantics. It is not expected that the RSVP Application-Level 247 Resource Priority Header Policy Element would be taken into account 248 at RSVP-hops within a given policy area. It is expected to be used 249 at policy area boundaries only in order to set/reset the RSVP 250 Admission Priority Policy Element. 252 Remapping by PDPs of the Admission Priority Policy Element from the 253 Application-Level Resource Priority Policy Element may also be used 254 at boundaries with other signaling protocols, such as the NSIS 255 Signaling Layer Protocol (NSLP) for QoS Signaling 256 ([I-D.ietf-nsis-qos-nslp]). 258 As can be observed, the framework described above for mapping/ 259 remapping application level resource priority requirements into an 260 RSVP admission priority can also be used together with [RFC3181] for 261 mapping/remapping application level resource priority requirements 262 into an RSVP preemption priority (when preemption is indeed deemed 263 necessary by the prioritized session handling policy). In that case, 264 when processing the RSVP Application-Level Resource Priority Policy 265 Element, the PDPs at policy boundaries (or between various QoS 266 signaling protocols) can map it into an RSVP "preemption priority" 267 information. This Preemption priority information comprises a setup 268 preemption level and a defending preemption priority level that can 269 then be encoded inside the Preemption Priority Policy Element of 270 [RFC3181]. 272 Appendix B provides examples of various hypothetical policies for 273 prioritized session handling, some of them involving admission 274 priority, some of them involving both admission priority and 275 preemption priority. Appendix B also identifies how the Application- 276 Level Resource Priority needs to be mapped into RSVP policy elements 277 by the PDPs to realize these policies. 279 4.1. Operations of Admission Priority 281 The RSVP Admission Priority policy element defined in this document 282 allows admission bandwidth to be allocated preferentially to 283 prioritized sessions. Multiple models of bandwidth allocation MAY be 284 used to that end. 286 A number of bandwidth allocation models have been defined in the IETF 287 for allocation of bandwidth across different classes of traffic 288 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 289 Those include the Maximum Allocation Model (MAM) defined in 290 [RFC4125], the Russian Dolls Model (RDM) specified in [RFC4127] and 291 the Maximum Allocation model with Reservation (MAR) defined in 292 [RFC4126]. These same models MAY however be applied for allocation 293 of bandwidth across different levels of admission priority as defined 294 in this document. Appendix A provides an illustration of how these 295 bandwidth allocation models can be applied for such purposes and also 296 introduces an additional bandwidth allocation model that we term the 297 Priority Bypass Model (PrBM). It is important to note that the 298 models described and illustrated in Appendix A are only informative 299 and do not represent a recommended course of action. 301 We can see in these examples how the RSVP Admission Priority can be 302 used by RSVP routers to influence their admission control decision 303 (for example by determining which bandwidth pool is to be used by 304 RSVP for performing its bandwidth allocation) and therefore to 305 increase the probability of reservation establishment. In turn, this 306 increases the probability of application level session establishment 307 for the corresponding session. 309 5. New Policy Elements 311 The Framework document for policy-based admission control [RFC2753] 312 describes the various components that participate in policy decision 313 making (i.e., PDP, PEP and LPDP). 315 As described in Section 4 of the present document, the Application- 316 Level Resource Priority Policy Element and the Admission Priority 317 Policy Element serve different roles in this framework: 319 o the Application-Level Resource Priority Policy Element conveys 320 application level information and is processed by PDPs 322 o the emphasis of Admission Priority Policy Element is to be simple, 323 stateless, and light-weight such that it can be processed 324 internally within a node's LPDP. It can then be enforced 325 internally within a node's PEP. It is set by PDPs based on 326 processing of the Application-Level Resource Priority Policy 327 Element. 329 [RFC2750] defines extensions for supporting generic policy based 330 admission control in RSVP. These extensions include the standard 331 format of POLICY_DATA objects and a description of RSVP handling of 332 policy events. 334 The POLICY_DATA object contains one or more of Policy Elements, each 335 representing a different (and perhaps orthogonal) policy. As an 336 example, [RFC3181] specifies the Preemption Priority Policy Element. 337 This document defines two new Policy Elements called: 339 o the Admission Priority Policy Element 341 o the Application-Level Resource Priority Policy Element 343 5.1. Admission Priority Policy Element 345 The format of the Admission Priority policy element is as shown in 346 Figure 1: 348 0 0 0 1 1 2 2 3 349 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 350 +-------------+-------------+-------------+-------------+ 351 | Length | P-Type = ADMISSION_PRI | 352 +-------------+-------------+-------------+-------------+ 353 | Flags | M. Strategy | Error Code | Reserved | 354 +-------------+-------------+-------------+-------------+ 355 | Reserved |Adm. Priority| 356 +---------------------------+---------------------------+ 358 Figure 1: Admission Priority Policy Element 360 where: 362 o Length: 16 bits 364 * Always 12. The overall length of the policy element, in bytes. 366 o P-Type: 16 bits 368 * ADMISSION_PRI = To be allocated by IANA (see "IANA 369 Considerations" section) 371 o Flags: Reserved 373 * SHALL be set to zero on transmit and SHALL be ignored on 374 reception 376 o Merge Strategy: 8 bits (applicable to multicast flows) 378 * values are defined by corresponding registry maintained by IANA 379 (see "IANA Considerations" section) 381 o Error code: 8 bits (applicable to multicast flows) 383 * values are defined by corresponding registry maintained by IANA 384 (see "IANA Considerations" section) 386 o Reserved: 8 bits 388 * SHALL be set to zero on transmit and SHALL be ignored on 389 reception 391 o Reserved: 24 bits 393 * SHALL be set to zero on transmit and SHALL be ignored on 394 reception 396 o Adm. Priority (Admission Priority): 8 bits (unsigned) 398 * The admission control priority of the flow, in terms of access 399 to network bandwidth in order to provide higher probability of 400 session completion to selected flows. Higher values represent 401 higher priority. Bandwidth allocation models such as those 402 described in Appendix A are to be used by the RSVP router to 403 achieve increased probability of session establishment. The 404 admission priority value effectively indicates which bandwidth 405 constraint(s) of the bandwidth constraint model in use is(are) 406 applicable to admission of this RSVP reservation. 408 Note that the Admission Priority Policy Element does NOT indicate 409 that this RSVP reservation is to preempt any other RSVP reservation. 410 If a priority session justifies both admission priority and 411 preemption priority, the corresponding RSVP reservation needs to 412 carry both an Admission Priority Policy Element and a Preemption 413 Priority Policy Element. The Admission Priority and Preemption 414 Priority are handled by LPDPs and PEPs as separate mechanisms. They 415 can be used one without the other, or they can be used both in 416 combination. 418 5.1.1. Admission Priority Merging Rules 420 This section discusses alternatives for dealing with RSVP admission 421 priority in case of merging of reservations. As merging applies to 422 multicast, this section also applies to multicast sessions. 424 The rules for merging Admission Priority Policy Elements are defined 425 by the value encoded inside the Merge Strategy field in accordance 426 with the corresponding IANA registry. This registry applies both to 427 the Merge Strategy field of the Admission Priority Policy Element 428 defined in the present document and to the Merge Strategy field of 429 the Preemption Priority Policy Elements defined in [RFC3181]. The 430 registry initially contains the values already defined in [RFC3181] 431 (see "IANA Considerations" section). 433 The only difference from [RFC3181] is that this document does not 434 recommend a given merge strategy over the others for Admission 435 Priority, while [RFC3181] recommends the first of these merge 436 strategies for Preemption Priority. Note that with the Admission 437 Priority (as is the case with the Preemption Priority), "Take highest 438 priority" translates into "take the highest numerical value". 440 5.2. Application-Level Resource Priority Policy Element 442 The format of the Application-Level Resource Priority policy element 443 is as shown in Figure 2: 445 0 0 0 1 1 2 2 3 446 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 447 +-------------+-------------+-------------+-------------+ 448 | Length | P-Type = APP_RESOURCE_PRI | 449 +-------------+-------------+-------------+-------------+ 450 // ALRP List // 451 +---------------------------+---------------------------+ 453 Figure 2: Application-Level Resource Priority Policy Element 455 where: 457 o Length: 459 * The length of the policy element (including the Length and 460 P-Type) is in number of octets (MUST be a multiple of 4) and 461 indicates the end of the ALRP list. 463 o P-Type: 16 bits 465 * APP_RESOURCE_PRI = To be allocated by IANA (see "IANA 466 Considerations" section) 468 o ALRP List: 470 * List of ALRP where each ALRP is encoded as shown in Figure 3. 472 ALRP: 473 0 0 0 1 1 2 2 3 474 0 . . . 7 8 . . . 5 6 . . . 3 4 . . . 1 475 +---------------------------+-------------+-------------+ 476 | ALRP Namespace | Reserved |ALRP Value | 477 +---------------------------+---------------------------+ 479 Figure 3: Application-Level Resource Priority 481 where: 483 o ALRP Namespace (Application-Level Resource Priority Namespace): 16 484 bits (unsigned) 486 * Contains a numerical value identifying the namespace of the 487 application-level resource priority. This value is encoded as 488 per the "Resource Priority Namespaces" IANA registry. (See 489 IANA Considerations section for the request to IANA to extend 490 the registry to include this numerical value). 492 o Reserved: 8 bits 494 * SHALL be set to zero on transmit and SHALL be ignored on 495 reception. 497 o ALRP Value: (Application-Level Resource Priority Value): 8 bits 498 (unsigned) 500 * Contains the priority value within the namespace of the 501 application-level resource priority. This value is encoded as 502 per the "Resource Priority Priority-Value" IANA registry. (See 503 IANA Considerations section for the request to IANA to extend 504 the registry to include this numerical value). 506 5.2.1. Application-Level Resource Priority Modifying and Merging Rules 508 When POLICY_DATA objects are protected by integrity, LPDPs should not 509 attempt to modify them. They MUST be forwarded as-is to ensure their 510 security envelope is not invalidated. 512 In case of multicast, when POLICY_DATA objects are not protected by 513 integrity, LPDPs MAY merge incoming Application-Level Resource 514 Priority elements to reduce their size and number. When they do 515 merge those, LPDPs MUST do so according to the following rule: 517 o The ALRP List in the outgoing APP_RESOURCE_PRI element MUST 518 contain all the ALRPs appearing in the ALRP List of an incoming 519 APP_RESOURCE_PRI element. A given ALRP MUST NOT appear more than 520 once. In other words, the outgoing ALRP List is the union of the 521 incoming ALRP Lists that are merged. 523 As merging applies to Multicast, this rule also applies to Multicast 524 sessions. 526 5.3. Default Handling 528 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 529 (PINs) implement a default handling of POLICY_DATA objects ensuring 530 that those objects can traverse PIN nodes in transit from one PEP to 531 another. This applies to the situations where POLICY_DATA objects 532 contain the Admission Priority Policy Element and the ALRP Policy 533 Element specified in this document, so that those can traverse PIN 534 nodes. 536 Section 4.2 of [RFC2750] also defines a similar default behavior for 537 policy-capable nodes that do not recognized a particular Policy 538 Element. This applies to the Admission Priority Policy Element and 539 the ALRP Policy Element specified in this document, so that those can 540 traverse policy-capable nodes that do not support these extensions 541 defined in the present document. 543 6. Security Considerations 545 As this document defines extensions to RSVP, the security 546 considerations of RSVP apply. Those are discussed in [RFC2205], 547 [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches 548 for addressing those concerns are discussed further below. 550 A subset of RSVP messages are signaled with the Router Alert Option 551 (RAO)(,[RFC2711]). The security aspects and common practices around 552 the use of the current IP Router Alert option and consequences on the 553 use of IP Router Alert by applications such as RSVP are discussed in 554 [I-D.rahman-rtg-router-alert-considerations]. As discussed in 555 Section 2, the extensions defined in this document are intended for 556 use within a single administrative domain. 558 [I-D.rahman-rtg-router-alert-considerations] discusses router alert 559 protection approaches for Service Providers. These approaches can be 560 used to protect a given network against the potential risks 561 associated with the leaking of router alert packets resulting from 562 the use of the present extensions in another domain. Also, where 563 RSVP is not used, by simply not enabling RSVP on the routers of a 564 given network, that network can generally isolate itself from any 565 RSVP signaling that may leak from another network that uses the 566 present extensions (since the routers will then typically ignore RSVP 567 messages). Where RSVP is to be used internally within a given 568 network, the network operator can activate, on the edge of his 569 network, mechanisms that either tunnel or drop incoming RSVP messages 570 in order to protect the given network from RSVP signaling that may 571 leak from another network that uses the present extensions. 573 The ADMISSION_PRI and APP_RESOURCE_PRI Policy Elements defined in 574 this document are signaled by RSVP through encapsulation in a Policy 575 Data object as defined in [RFC2750]. Therefore, like any other 576 Policy Elements, their integrity can be protected as discussed in 577 section 6 of [RFC2750] by two optional security mechanisms. The 578 first mechanism relies on RSVP Authentication as specified in 579 [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP 580 nodes are policy capable. With this mechanism, the INTEGRITY object 581 is carried inside RSVP messages. The second mechanism relies on the 582 INTEGRITY object within the POLICY_DATA object to guarantee integrity 583 between RSVP Policy Enforcement Points (PEPs) that are not RSVP 584 neighbors. 586 6.1. Use of RSVP Authentication between RSVP neighbors 588 RSVP authentication can be used between RSVP neighbors that are 589 policy capable. RSVP Authentication (defined in [RFC2747] and 590 [RFC3097]) SHOULD be supported by an implementation of the present 591 document. 593 With RSVP authentication, the RSVP neighbors use shared keys to 594 compute the cryptographic signature of the RSVP message. 595 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key 596 provisioning methods as well as their respective applicability. 598 6.2. Use of INTEGRITY object within the POLICY_DATA object 600 The INTEGRITY object within the POLICY_DATA object can be used to 601 guarantee integrity between non-neighboring RSVP PEPs. This is 602 useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). 603 The INTEGRITY object within the POLICY_DATA object MAY be supported 604 by an implementation of the present document. 606 Details for computation of the content of the INTEGRITY object can be 607 found in Appendix B of [RFC2750]. This states that the Policy 608 Decision Point (PDP), at its discretion, and based on destination 609 PEP/PDP or other criteria, selects an Authentication Key and the hash 610 algorithm to be used. Keys to be used between PDPs can be 611 distributed manually or via standard key management protocol for 612 secure key distribution. 614 Note that where non-RSVP hops may exist in between RSVP hops, as well 615 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 616 between PEPs, it may be difficult for the PDP to determine what is 617 the destination PDP for a POLICY_DATA object contained in some RSVP 618 messages (such as a Path message). This is because in those cases 619 the next PEP is not known at the time of forwarding the message. In 620 this situation, key shared across multiple PDPs may be used. This is 621 conceptually similar to the use of key shared across multiple RSVP 622 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 623 We observe also that this issue may not exist in some deployment 624 scenarios where a single (or low number of) PDP is used to control 625 all the PEPs of a region (such as an administrative domain). In such 626 scenarios, it may be easy for a PDP to determine what is the next hop 627 PDP, even when the next hop PEP is not known, simply by determining 628 what is the next region that will be traversed (say based on the 629 destination address). 631 7. IANA Considerations 633 As specified in [RFC2750], Standard RSVP Policy Elements (P-type 634 values) are to be assigned by IANA as per "IETF Consensus" policy 635 following the policies outlined in [RFC2434] (this policy is now 636 called "IETF Review" as per [RFC5226]) . 638 IANA needs to allocate two P-Types from the Standard RSVP Policy 639 Element range: 641 o one P-Type to the Admission Priority Policy Element 643 o one P-Type to the Application-Level Resource Priority Policy 644 Element. 646 In Section 5.1, the present document defines a Merge Strategy field 647 inside the Admission Priority policy element. This registry is to be 648 specified as also applicable to the Merge Strategy field of the 649 Preemption Priority Policy Elements defined in [RFC3181]. Since it 650 is conceivable that, in the future, values are added to the registry 651 that only apply to the Admission Priority Policy Element or to the 652 Preemption Priority Policy Element (but not to both), IANA needs to 653 list the applicable documents for each value. IANA needs to allocate 654 the following values:: 656 o 0: Reserved 658 o 1: Take priority of highest QoS [RFC3181] [RFC-XXX] 660 o 2: Take highest priority [RFC3181] [RFC-XXX] 662 o 3: Force Error on heterogeneous merge [RFC3181] [RFC-XXX] 664 Following the policies outlined in [RFC5226], numbers in the range 665 4-127 are allocated according to the "IETF Review" policy, numbers in 666 the range 128-240 as "First Come First Served" and numbers between 667 241-255 are reserved for "Private Use". 669 In Section 5.1, the present document defines an Error Code field 670 inside the Admission Priority policy element. IANA needs to create a 671 registry for this field and allocate the following values: 673 o 0: NO_ERROR Value used for regular ADMISSION_PRI elements 675 o 2: HETEROGENEOUS This element encountered heterogeneous merge 677 Following the policies outlined in [RFC5226], numbers in the range 678 3-127 are allocated according to the "IETF Review" policy, numbers in 679 the range 128-240 as "First Come First Served" and numbers between 680 241-255 are reserved for "Private Use". Value 1 is Reserved (for 681 consistency with [RFC3181] Error Code values). 683 The present document defines an ALRP Namespace field in Section 5.2 684 that contains a numerical value identifying the namespace of the 685 application-level resource priority. The IANA already maintains the 686 Resource-Priority Namespaces registry (under the SIP Parameters) 687 listing all such namespace. However, that registry does not 688 currently allocate a numerical value to each namespace. Hence, this 689 document requests the IANA to extend the Resource-Priority Namespaces 690 registry in the following ways: 692 o a new column should be added to the registry 694 o the title of the new column should be "Namespace Numerical Value 695 *" 697 o in the Legend, add a line saying "Namespace Numerical Value = the 698 unique numerical value identifying the namespace" 700 o add a line at the bottom of the registry stating the following "* 701 : [RFCXXX] " where XXX is the RFC number of the present document 703 o allocate an actual numerical value to each namespace in the 704 registry and state that value in the new "Namespace numerical 705 Value *" column. 707 A numerical value should be allocated immediately by IANA to all 708 existing namespaces. Then, in the future, IANA should automatically 709 allocate a numerical value to any new namespace added to the 710 registry. 712 The present document defines an ALRP Priority field in Section 5.2 713 that contains a numerical value identifying the actual application- 714 level resource priority within the application-level resource 715 priority namespace. The IANA already maintains the Resource-Priority 716 Priority-values registry (under the SIP Parameters) listing all such 717 priorities. However, that registry does not currently allocate a 718 numerical value to each priority-value. Hence, this document 719 requests the IANA to extend the Resource-Priority Priority-Values 720 registry in the following ways: 722 o for each namespace, the registry should be structured with two 723 columns 725 o the title of the first column should read "Priority Values (least 726 to greatest)" 728 o the first column should list all the values currently defined in 729 the registry (e.g. For the drsn namespace: "routine", "priority", 730 "immediate", "flash", "flash-override", "flash-override-override" 731 for the drsn namespace) 733 o the title of the second column should read "Priority Numerical 734 Value *" 736 o At the bottom of the registry, add a "Legend" with a line saying 737 "Priority Numerical Value = the unique numerical value identifying 738 the priority within a namespace" 740 o add a line at the bottom of the registry stating the following "* 741 : [RFCXXX] " where XXX is the RFC number of the present document 743 o allocate an actual numerical value to each and state that value in 744 the new "Priority Numerical Value *" column. 746 A numerical value should be allocated immediately by IANA to all 747 existing priorities. Then, in the future, IANA should automatically 748 allocate a numerical value to any new namespace added to the 749 registry. The numerical value must be unique within each namespace. 750 For the initial allocation, within each namespace, values should be 751 allocated in decreasing order ending with 0 (so that the greatest 752 priority is always allocated value 0). For example, in the drsn 753 namespace, "routine" would be allocated numerical value 5 and "flash- 754 override-override" would be allocated numerical value 0. 756 8. Acknowledgments 758 We would like to thank An Nguyen for his encouragement to address 759 this topic and ongoing comments. Also, this document borrows heavily 760 from some of the work of S. Herzog on Preemption Priority Policy 761 Element [RFC3181]. Dave Oran and Janet Gunn provided useful input 762 into this document. Ron Bonica, Magnus Westerlund, Cullen Jennings, 763 Ross Callon and Tim Polk provided specific guidance for the 764 applicability statement of the mechanisms defined in this document. 766 9. References 768 9.1. Normative References 770 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 771 Requirement Levels", BCP 14, RFC 2119, March 1997. 773 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 775 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 776 Functional Specification", RFC 2205, September 1997. 778 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 779 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 780 October 1998. 782 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 783 Authentication", RFC 2747, January 2000. 785 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 786 RFC 2750, January 2000. 788 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 789 Authentication -- Updated Message Type Value", RFC 3097, 790 April 2001. 792 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 793 RFC 3181, October 2001. 795 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 796 A., Peterson, J., Sparks, R., Handley, M., and E. 797 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 798 June 2002. 800 [RFC3312] Camarillo, G., Marshall, W., and J. Rosenberg, 801 "Integration of Resource Management and Session Initiation 802 Protocol (SIP)", RFC 3312, October 2002. 804 [RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource 805 Priority for the Session Initiation Protocol (SIP)", 806 RFC 4412, February 2006. 808 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 809 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 810 May 2008. 812 9.2. Informative References 814 [I-D.ietf-nsis-qos-nslp] 815 Manner, J., Karagiannis, G., and A. McDonald, "NSLP for 816 Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-18 817 (work in progress), January 2010. 819 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 820 Behringer, M. and F. Faucheur, "Applicability of Keying 821 Methods for RSVP Security", 822 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 823 progress), June 2009. 825 [I-D.rahman-rtg-router-alert-considerations] 826 Faucheur, F., "IP Router Alert Considerations and Usage", 827 draft-rahman-rtg-router-alert-considerations-03 (work in 828 progress), October 2009. 830 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 831 February 1997. 833 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 834 RFC 2711, October 1999. 836 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 837 for Policy-based Admission Control", RFC 2753, 838 January 2000. 840 [RFC4125] Le Faucheur, F. and W. Lai, "Maximum Allocation Bandwidth 841 Constraints Model for Diffserv-aware MPLS Traffic 842 Engineering", RFC 4125, June 2005. 844 [RFC4126] Ash, J., "Max Allocation with Reservation Bandwidth 845 Constraints Model for Diffserv-aware MPLS Traffic 846 Engineering & Performance Comparisons", RFC 4126, 847 June 2005. 849 [RFC4127] Le Faucheur, F., "Russian Dolls Bandwidth Constraints 850 Model for Diffserv-aware MPLS Traffic Engineering", 851 RFC 4127, June 2005. 853 [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security 854 Properties", RFC 4230, December 2005. 856 Appendix A. Examples of Bandwidth Allocation Model for Admission 857 Priority 859 Sections A.1 and A.2 respectively illustrate how the Maximum 860 Allocation Model (MAM) ([RFC4125]) and the Russian Dolls Model (RDM) 861 ([RFC4127]) can be used for support of admission priority. The 862 Maximum Allocation model with Reservation (MAR) ([RFC4126]) could 863 also be used in a similar manner for support of admission priority. 864 Section A.3 illustrates how a simple "Priority Bypass Model" can also 865 be used for support of admission priority. 867 For simplicity, operations with only a single "priority" level 868 (beyond non-priority) are illustrated here; However, the reader will 869 appreciate that operations with multiple priority levels can easily 870 be supported with these models. 872 In all the figures below: 874 x represents a non-priority session 876 o represents a priority session 878 A.1. Admission Priority with Maximum Allocation Model (MAM) 880 This section illustrates operations of admission priority when a 881 Maximum Allocation Model (MAM) is used for bandwidth allocation 882 across non-priority traffic and priority traffic. A property of the 883 Maximum Allocation Model is that priority traffic can not use more 884 than the bandwidth made available to priority traffic (even if the 885 non-priority traffic is not using all of the bandwidth available for 886 it). 888 ----------------------- 889 ^ ^ ^ | | ^ 890 . . . | | . 891 Total . . . | | . Bandwidth 892 (1)(2)(3) | | . Available 893 Engi- . . . | | . for non-priority use 894 neered .or.or. | | . 895 . . . | | . 896 Capacity. . . | | . 897 v . . | | v 898 . . |--------------| --- 899 v . | | ^ 900 . | | . Bandwidth available for 901 v | | v priority use 902 ------------------------- 904 Figure 4: MAM Bandwidth Allocation 906 Figure 4 shows a link within a routed network conforming to this 907 document. On this link are two amounts of bandwidth available to two 908 types of traffic: non-priority and priority. 910 If the non-priority traffic load reaches the maximum bandwidth 911 available for non-priority, no additional non-priority sessions can 912 be accepted even if the bandwidth reserved for priority traffic is 913 not currently fully utilized. 915 With the Maximum Allocation Model, in the case where the priority 916 load reaches the maximum bandwidth reserved for priority sessions, no 917 additional priority sessions can be accepted. 919 As illustrated in Figure 4, an operator may map the MAM to the 920 Engineered Capacity limits according to different policies. At one 921 extreme, where the proportion of priority traffic is reliably known 922 to be fairly small at all times and where there may be some safety 923 margin factored in the engineered capacity limits, the operator may 924 decide to configure the bandwidth available for non-priority use to 925 the full engineered capacity limits; effectively allowing the 926 priority traffic to ride within the safety margin of this engineered 927 capacity. This policy can be seen as an economically attractive 928 approach as all of the engineered capacity is made available to non- 929 priority sessions. This policy is illustrated as (1) in Figure 4. 930 As an example, if the engineered capacity limit on a given link is X, 931 the operator may configure the bandwidth available to non-priority 932 traffic to X, and the bandwidth available to priority traffic to 5% 933 of X. At the other extreme, where the proportion of priority traffic 934 may be significant at times and the engineered capacity limits are 935 very tight, the operator may decide to configure the bandwidth 936 available to non-priority traffic and the bandwidth available to 937 priority traffic such that their sum is equal to the engineered 938 capacity limits. This guarantees that the total load across non- 939 priority and priority traffic is always below the engineered capacity 940 and, in turn, guarantees there will never be any QoS degradation. 941 However, this policy is less attractive economically as it prevents 942 non-priority sessions from using the full engineered capacity, even 943 when there is no or little priority load, which is the majority of 944 time. This policy is illustrated as (3) in Figure 4. As an example, 945 if the engineered capacity limit on a given link is X, the operator 946 may configure the bandwidth available to non-priority traffic to 95% 947 of X, and the bandwidth available to priority traffic to 5% of X. Of 948 course, an operator may also strike a balance anywhere in between 949 these two approaches. This policy is illustrated as (2) in Figure 4. 951 Figure 5 shows some of the non-priority capacity of this link being 952 used. 954 ----------------------- 955 ^ ^ ^ | | ^ 956 . . . | | . 957 Total . . . | | . Bandwidth 958 . . . | | . Available 959 Engi- . . . | | . for non-priority use 960 neered .or.or. |xxxxxxxxxxxxxx| . 961 . . . |xxxxxxxxxxxxxx| . 962 Capacity. . . |xxxxxxxxxxxxxx| . 963 v . . |xxxxxxxxxxxxxx| v 964 . . |--------------| --- 965 v . | | ^ 966 . | | . Bandwidth available for 967 v | | v priority use 968 ------------------------- 970 Figure 5: Partial load of non-priority calls 972 Figure 6 shows the same amount of non-priority load being used at 973 this link, and a small amount of priority bandwidth being used. 975 ----------------------- 976 ^ ^ ^ | | ^ 977 . . . | | . 978 Total . . . | | . Bandwidth 979 . . . | | . Available 980 Engi- . . . | | . for non-priority use 981 neered .or.or. |xxxxxxxxxxxxxx| . 982 . . . |xxxxxxxxxxxxxx| . 983 Capacity. . . |xxxxxxxxxxxxxx| . 984 v . . |xxxxxxxxxxxxxx| v 985 . . |--------------| --- 986 v . | | ^ 987 . | | . Bandwidth available for 988 v |oooooooooooooo| v priority use 989 ------------------------- 991 Figure 6: Partial load of non-priority calls & partial load of 992 priority calls Calls 994 Figure 7 shows the case where non-priority load equates or exceeds 995 the maximum bandwidth available to non-priority traffic. Note that 996 additional non-priority sessions would be rejected even if the 997 bandwidth reserved for priority sessions is not fully utilized. 999 ----------------------- 1000 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1001 . . . |xxxxxxxxxxxxxx| . 1002 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1003 . . . |xxxxxxxxxxxxxx| . Available 1004 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1005 neered .or.or. |xxxxxxxxxxxxxx| . 1006 . . . |xxxxxxxxxxxxxx| . 1007 Capacity. . . |xxxxxxxxxxxxxx| . 1008 v . . |xxxxxxxxxxxxxx| v 1009 . . |--------------| --- 1010 v . | | ^ 1011 . | | . Bandwidth available for 1012 v |oooooooooooooo| v priority use 1013 ------------------------- 1015 Figure 7: Full non-priority load & partial load of priority calls 1017 Figure 8 shows the case where the priority traffic equates or exceeds 1018 the bandwidth reserved for such priority traffic. 1020 In that case additional priority sessions could not be accepted. 1021 Note that this does not mean that such sessions are dropped 1022 altogether: they may be handled by mechanisms, which are beyond the 1023 scope of this particular document (such as establishment through 1024 preemption of existing non-priority sessions, or such as queuing of 1025 new priority session requests until capacity becomes available again 1026 for priority traffic). 1028 ----------------------- 1029 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 1030 . . . |xxxxxxxxxxxxxx| . 1031 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 1032 . . . |xxxxxxxxxxxxxx| . Available 1033 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 1034 neered .or.or. |xxxxxxxxxxxxxx| . 1035 . . . |xxxxxxxxxxxxxx| . 1036 Capacity. . . | | . 1037 v . . | | v 1038 . . |--------------| --- 1039 v . |oooooooooooooo| ^ 1040 . |oooooooooooooo| . Bandwidth available for 1041 v |oooooooooooooo| v priority use 1042 ------------------------- 1044 Figure 8: Partial non-priority load & Full priority load 1046 A.2. Admission Priority with Russian Dolls Model (RDM) 1048 This section illustrates operations of admission priority when a 1049 Russian Dolls Model (RDM) is used for bandwidth allocation across 1050 non-priority traffic and priority traffic. A property of the Russian 1051 Dolls Model is that priority traffic can use the bandwidth which is 1052 not currently used by non-priority traffic. 1054 As with the MAM, an operator may map the RDM onto the Engineered 1055 Capacity limits according to different policies. The operator may 1056 decide to configure the bandwidth available for non-priority use to 1057 the full engineered capacity limits; As an example, if the engineered 1058 capacity limit on a given link is X, the operator may configure the 1059 bandwidth available to non-priority traffic to X, and the bandwidth 1060 available to non-priority and priority traffic to 105% of X. 1062 Alternatively, the operator may decide to configure the bandwidth 1063 available to non-priority and priority traffic to the engineered 1064 capacity limits; As an example, if the engineered capacity limit on a 1065 given link is X, the operator may configure the bandwidth available 1066 to non-priority traffic to 95% of X, and the bandwidth available to 1067 non-priority and priority traffic to X. 1069 Finally, the operator may decide to strike a balance in between. The 1070 considerations presented for these policies in the previous section 1071 in the MAM context are equally applicable to RDM. 1073 Figure 9 shows the case where only some of the bandwidth available to 1074 non-priority traffic is being used and a small amount of priority 1075 traffic is in place. In that situation both new non-priority 1076 sessions and new priority sessions would be accepted. 1078 -------------------------------------- 1079 |xxxxxxxxxxxxxx| . ^ 1080 |xxxxxxxxxxxxxx| . Bandwidth . 1081 |xxxxxxxxxxxxxx| . Available for . 1082 |xxxxxxxxxxxxxx| . non-priority . 1083 |xxxxxxxxxxxxxx| . use . 1084 |xxxxxxxxxxxxxx| . . Bandwidth 1085 | | . . available for 1086 | | v . non-priority 1087 |--------------| --- . and priority 1088 | | . use 1089 | | . 1090 |oooooooooooooo| v 1091 --------------------------------------- 1093 Figure 9: Partial non-priority load & Partial Aggregate load 1095 Figure 10 shows the case where all of the bandwidth available to non- 1096 priority traffic is being used and a small amount of priority traffic 1097 is in place. In that situation new priority sessions would be 1098 accepted but new non-priority sessions would be rejected. 1100 -------------------------------------- 1101 |xxxxxxxxxxxxxx| . ^ 1102 |xxxxxxxxxxxxxx| . Bandwidth . 1103 |xxxxxxxxxxxxxx| . Available for . 1104 |xxxxxxxxxxxxxx| . non-priority . 1105 |xxxxxxxxxxxxxx| . use . 1106 |xxxxxxxxxxxxxx| . . Bandwidth 1107 |xxxxxxxxxxxxxx| . . available for 1108 |xxxxxxxxxxxxxx| v . non-priority 1109 |--------------| --- . and priority 1110 | | . use 1111 | | . 1112 |oooooooooooooo| v 1113 --------------------------------------- 1115 Figure 10: Full non-priority load & Partial Aggregate load 1117 Figure 11 shows the case where only some of the bandwidth available 1118 to non-priority traffic is being used and a heavy load of priority 1119 traffic is in place. In that situation both new non-priority 1120 sessions and new priority sessions would be accepted. Note that, as 1121 illustrated in Figure 10, priority sessions use some of the bandwidth 1122 currently not used by non-priority traffic. 1124 -------------------------------------- 1125 |xxxxxxxxxxxxxx| . ^ 1126 |xxxxxxxxxxxxxx| . Bandwidth . 1127 |xxxxxxxxxxxxxx| . Available for . 1128 |xxxxxxxxxxxxxx| . non-priority . 1129 |xxxxxxxxxxxxxx| . use . 1130 | | . . Bandwidth 1131 | | . . available for 1132 |oooooooooooooo| v . non-priority 1133 |--------------| --- . and priority 1134 |oooooooooooooo| . use 1135 |oooooooooooooo| . 1136 |oooooooooooooo| v 1137 --------------------------------------- 1139 Figure 11: Partial non-priority load & Heavy Aggregate load 1141 Figure 12 shows the case where all of the bandwidth available to non- 1142 priority traffic is being used and all of the remaining available 1143 bandwidth is used by priority traffic. In that situation new non- 1144 priority sessions would be rejected. In that situation new priority 1145 sessions could not be accepted right away. Those priority sessions 1146 may be handled by mechanisms, which are beyond the scope of this 1147 particular document (such as established through preemption of 1148 existing non-priority sessions, or such as queuing of new priority 1149 session requests until capacity becomes available again for priority 1150 traffic). 1152 -------------------------------------- 1153 |xxxxxxxxxxxxxx| . ^ 1154 |xxxxxxxxxxxxxx| . Bandwidth . 1155 |xxxxxxxxxxxxxx| . Available for . 1156 |xxxxxxxxxxxxxx| . non-priority . 1157 |xxxxxxxxxxxxxx| . use . 1158 |xxxxxxxxxxxxxx| . . Bandwidth 1159 |xxxxxxxxxxxxxx| . . available for 1160 |xxxxxxxxxxxxxx| v . non-priority 1161 |--------------| --- . and priority 1162 |oooooooooooooo| . use 1163 |oooooooooooooo| . 1164 |oooooooooooooo| v 1165 --------------------------------------- 1167 Figure 12: Full non-priority load & Full Aggregate load 1169 A.3. Admission Priority with Priority Bypass Model (PrBM) 1171 This section illustrates operations of admission priority when a 1172 simple Priority Bypass Model (PrBM) is used for bandwidth allocation 1173 across non-priority traffic and priority traffic. With the Priority 1174 Bypass Model, non-priority traffic is subject to resource based 1175 admission control while priority traffic simply bypasses the resource 1176 based admission control. In other words: 1178 o when a non-priority session arrives, this session is subject to 1179 bandwidth admission control and is accepted if the current total 1180 load (aggregate over non-priority and priority traffic) is below 1181 the engineered/allocated bandwidth. 1183 o when a priority session arrives, this session is admitted 1184 regardless of the current load. 1186 A property of this model is that a priority session is never 1187 rejected. 1189 The rationale for this simple scheme is that, in practice in some 1190 networks: 1192 o the volume of priority sessions is very low for the vast majority 1193 of time, so it may not be economical to completely set aside 1194 bandwidth for priority sessions and preclude the utilization of 1195 this bandwidth by normal sessions in normal situations 1197 o even in congestion periods where priority sessions may be more 1198 heavily used, those always still represent a fairly small 1199 proportion of the overall load which can be absorbed within the 1200 safety margin of the engineered capacity limits. Thus, even if 1201 they are admitted beyond the engineered bandwidth threshold, they 1202 are unlikely to result in noticeable QoS degradation. 1204 As with the MAM and RDM, an operator may map the Priority Bypass 1205 model onto the Engineered Capacity limits according to different 1206 policies. The operator may decide to configure the bandwidth limit 1207 for admission of non-priority traffic to the full engineered capacity 1208 limits; As an example, if the engineered capacity limit on a given 1209 link is X, the operator may configure the bandwidth limit for non- 1210 priority traffic to X. Alternatively, the operator may decide to 1211 configure the bandwidth limit for non-priority traffic to below the 1212 engineered capacity limits (so that the sum of the non-priority and 1213 priority traffic stays below the engineered capacity); As an example, 1214 if the engineered capacity limit on a given link is X, the operator 1215 may configure the bandwidth limit for non-priority traffic to 95% of 1216 X. Finally, the operator may decide to strike a balance in between. 1217 The considerations presented for these policies in the previous 1218 sections in the MAM and RDM contexts are equally applicable to the 1219 Priority Bypass Model. 1221 Figure 13 illustrates the bandwidth allocation with the Priority 1222 Bypass Model. 1224 ----------------------- 1225 ^ ^ | | ^ 1226 . . | | . 1227 Total . . | | . Bandwidth Limit 1228 (1) (2) | | . (on non-priority + priority) 1229 Engi- . . | | . for admission 1230 neered . or . | | . of non-priority traffic 1231 . . | | . 1232 Capacity. . | | . 1233 v . | | v 1234 . |--------------| --- 1235 . | | 1236 v | | 1237 | | 1239 Figure 13: Priority Bypass Model Bandwidth Allocation 1241 Figure 14 shows some of the non-priority capacity of this link being 1242 used. In this situation, both new non-priority and new priority 1243 sessions would be accepted. 1245 ----------------------- 1246 ^ ^ |xxxxxxxxxxxxxx| ^ 1247 . . |xxxxxxxxxxxxxx| . 1248 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1249 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1250 Engi- . . | | . for admission 1251 neered . or . | | . of non-priority traffic 1252 . . | | . 1253 Capacity. . | | . 1254 v . | | v 1255 . |--------------| --- 1256 . | | 1257 v | | 1258 | | 1260 Figure 14: Partial load of non-priority calls 1262 Figure 15 shows the same amount of non-priority load being used at 1263 this link, and a small amount of priority bandwidth being used. In 1264 this situation, both new non-priority and new priority sessions would 1265 be accepted. 1267 ----------------------- 1268 ^ ^ |xxxxxxxxxxxxxx| ^ 1269 . . |xxxxxxxxxxxxxx| . 1270 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1271 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1272 Engi- . . |oooooooooooooo| . for admission 1273 neered . or . | | . of non-priority traffic 1274 . . | | . 1275 Capacity. . | | . 1276 v . | | v 1277 . |--------------| --- 1278 . | | 1279 v | | 1280 | | 1282 Figure 15: Partial load of non-priority calls & partial load of 1283 priority calls 1285 Figure 16 shows the case where aggregate non-priority and priority 1286 load exceeds the bandwidth limit for admission of non-priority 1287 traffic. In this situation, any new non-priority session is rejected 1288 while any new priority session is admitted. 1290 ----------------------- 1291 ^ ^ |xxxxxxxxxxxxxx| ^ 1292 . . |xxxxxxxxxxxxxx| . 1293 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 1294 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 1295 Engi- . . |oooooooooooooo| . for admission 1296 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 1297 . . |xxoxxxxxxoxxxx| . 1298 Capacity. . |oxxxooooxxxxoo| . 1299 v . |xxoxxxooxxxxxx| v 1300 . |--------------| --- 1301 . |oooooooooooooo| 1302 v | | 1303 | | 1305 Figure 16: Full non-priority load 1307 Appendix B. Example Usages of RSVP Extensions 1309 This section provides examples of how RSVP extensions defined in this 1310 document can be used (in conjunctions with other RSVP functionality 1311 and SIP functionality) to enforce different hypothetical policies for 1312 handling prioritized sessions in a given administrative domain. This 1313 Appendix does not provide additional specification. It is only 1314 included in this document for illustration purposes. 1316 We assume an environment where SIP is used for session control and 1317 RSVP is used for resource reservation. 1319 We refer here to "Session Queueing" as the set of "session" layer 1320 capabilities that may be implemented by SIP user agents to influence 1321 their treatment of SIP requests. This may include the ability to 1322 "queue" session requests when those can not be immediately honored 1323 (in some cases with the notion of "bumping", or "displacement", of 1324 less important session requests from that queue). It may include 1325 additional mechanisms such as exemption from certain network 1326 management controls, and alternate routing. 1328 We only mention below the RSVP policy elements that are to be 1329 enforced by PEPs. It is assumed that these policy elements are set 1330 at a policy area boundary by PDPs. The Admission Priority and 1331 Preemption Priority RSVP policy elements are set by PDPs as a result 1332 of processing the Application Level Resource Priority Policy Element 1333 (which is carried in RSVP messages). 1335 If one wants to implement a prioritized service purely based on 1336 Session Queueing, one can achieve this by signaling prioritized 1337 sessions: 1339 o using "Resource-Priority" header in SIP 1341 o not using Admission-Priority Policy Element in RSVP 1343 o not using Preemption Policy Element in RSVP 1345 If one wants to implement a prioritized service based on Session 1346 Queueing and on "prioritized access to network layer resources", one 1347 can achieve this by signaling prioritized sessions: 1349 o using "Resource-Priority" header in SIP 1351 o using Admission-Priority Policy Element in RSVP 1353 o not using Preemption Policy Element in RSVP 1355 Establishment of prioritized sessions will not result in preemption 1356 of any session. Different bandwidth allocation models can be used to 1357 offer different "prioritized access to network resources". Just as 1358 examples, this includes strict setting aside of capacity for 1359 prioritized sessions as well as simple bypass of admission limits for 1360 prioritized sessions. 1362 If one wants to implement a prioritized service based on Session 1363 Queueing, on "prioritized access to network layer resources", and 1364 ensures that (say) "Prioritized-1" sessions can preempt 1365 "Prioritized-2" sessions, but non-prioritized sessions are not 1366 affected by preemption, one can do that by signaling prioritized 1367 sessions: 1369 o using "Resource-Priority" header in SIP 1371 o using Admission-Priority Policy Element in RSVP 1373 o using Preemption Policy Element in RSVP with: 1375 * setup (Prioritized-1) > defending (Prioritized-2) 1377 * setup (Prioritized-2) <= defending (Prioritized-1) 1379 * setup (Prioritized-1) <= defending (Non-Prioritized) 1381 * setup (Prioritized-2) <= defending (Non-Prioritized) 1383 If one wants to implement a prioritized service based on Session 1384 Queueing, on "prioritized access to network layer resources", and 1385 ensure that prioritized sessions can preempt regular sessions, one 1386 could do that by signaling Prioritized sessions: 1388 o using "Resource-Priority" header in SIP 1390 o using Admission-Priority Policy Element in RSVP 1392 o using Preemption Policy Element in RSVP with: 1394 * setup (Prioritized) > defending (Non-Prioritized) 1396 * setup (Non-Prioritized) <= defending (Prioritized) 1398 If one wants to implement a prioritized service based on Session 1399 Queueing, on "prioritized access to network layer resources", and 1400 ensure that prioritized sessions can partially preempt regular 1401 sessions (i.e. Reduce their reservation size), one could do that by 1402 signaling prioritized sessions: 1404 o using "Resource-Priority" header in SIP 1406 o using Admission-Priority Policy Element in RSVP 1408 o using Preemption in Policy Element RSVP with: 1410 * setup (Prioritized) > defending (Non-Prioritized) 1412 * setup (Non-Prioritized) <= defending (Prioritized) 1414 o activate RFC4495 RSVP Bandwidth Reduction mechanisms 1416 Authors' Addresses 1418 Francois Le Faucheur 1419 Cisco Systems 1420 Greenside, 400 Avenue de Roumanille 1421 Sophia Antipolis 06410 1422 France 1424 Phone: +33 4 97 23 26 19 1425 Email: flefauch@cisco.com 1426 James Polk 1427 Cisco Systems 1428 2200 East President George Bush Highway 1429 Richardson, TX 75082-3550 1430 United States 1432 Phone: +1 972 813 5208 1433 Email: jmpolk@cisco.com 1435 Ken Carlberg 1436 G11 1437 123a Versailles Circle 1438 Towson, MD 21204 1439 United States 1441 Email: carlberg@g11.org.uk