idnits 2.17.1 draft-lefaucheur-emergency-rsvp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1108. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1085. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1092. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1098. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 24 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 25 has weird spacing: '... and may be...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2006) is 6646 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: 'RFC2119' is mentioned on line 61, but not defined == Missing Reference: 'POLICY-RSVP' is mentioned on line 980, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 982, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3689 (ref. 'EMERG-RQTS') ** Downref: Normative reference to an Informational RFC: RFC 3690 (ref. 'EMERG-TEL') ** Downref: Normative reference to an Informational draft: draft-ietf-tsvwg-mlpp-that-works (ref. 'EMERG-IMP') ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'FW-POLICY') ** Downref: Normative reference to an Experimental RFC: RFC 4125 (ref. 'DSTE-MAM') ** Downref: Normative reference to an Experimental RFC: RFC 4127 (ref. 'DSTE-RDM') Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Francois Le Faucheur 2 James Polk 3 Cisco Systems, Inc. 5 Ken Carlberg 6 G11 8 draft-lefaucheur-emergency-rsvp-01.txt 9 Expires: March 2006 February 2006 11 RSVP Extensions for Emergency Services 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 An Emergency Telecommunications Service (ETS) requires the ability to 38 provide an elevated probability of call completion to an authorized 39 user in times of network congestion (typically, during a crisis). 40 When supported over the Internet Protocol suite, this may be achieved 41 through an admission control solution which supports admission 42 priority capabilities and possibly session preemption capabilities 43 (depending on policies and deployed implementations). Admission 44 priority involves setting aside some resources (e.g. bandwidth) out 45 of the engineered capacity limits for the emergency services only, or 46 alternatively involves allowing the emergency sessions to seize 47 additional resources beyond the engineered capacity limits applied to 48 normal calls. 50 This document specifies RSVP extensions necessary for supporting such 51 admission priority capabilities. 53 Copyright Notice 54 Copyright (C) The Internet Society (2006) 56 Specification of Requirements 58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 60 document are to be interpreted as described in [RFC2119]. 62 1. Introduction 64 [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency 65 Telecommunications Service (ETS), which is an umbrella term 66 identifying those networks and specific services used to support 67 emergency communications. An underlying goal of these documents is to 68 present requirements that elevate the probability of session 69 establishment from an authorized user in times of network congestion 70 (presumably because of a crisis condition). To that end, some of 71 these types of services require that the network be capable of 72 preempting sessions; others do not involve preemption but instead 73 rely on another network mechanism which we refer throughout this 74 document as "admission priority", in order to obtain a high 75 probability of session completion for those. Admission priority 76 involves setting aside some resources (e.g. bandwidth) out of the 77 engineered capacity limits for the emergency services only, or 78 alternatively involves allowing the emergency related sessions to 79 seize additional resources beyond the engineered capacity limits 80 applied to normal calls. 82 Note: Below, this document references several examples of IP 83 telephony and its use of "calls", which is one form of the term 84 "sessions" (Video over IP and Instant Messaging being other examples 85 that rely on session establishment). For the sake of simplicity, we 86 shall use the widely known term "call" for the remainder of this 87 document. 89 [EMERG-IMP] describes the call and admission control procedures (at 90 initial call set up, as well as after call establishment through 91 maintenance of a continuing call model of the status of all calls) 92 which allow support of an Emergency Telecommunications Service. 93 [EMERG-IMP] also describes how these call and admission control 94 procedures can be realized using the Resource reSerVation Protocol 95 [RSVP] along with its associated protocol suite and extensions, 96 including those for policy based admission control ([FW-POLICY], 97 [RSVP-POLICY]), for user authentication and authorization ([RSVP-ID]) 98 and for integrity and authentication of RSVP messages ([RSVP-CRYPTO- 99 1], [RSVP-CRYPTO-2]). 101 Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption 102 Priority Policy Element specified in [RSVP-PREEMP] can be used to 103 enforce the call preemption needed by some emergency services. 105 This document specifies RSVP extensions, which can be used to enforce 106 the "admission priority" required by an RSVP capable ETS network. In 107 particular this document specifies two new RSVP Policy Elements 108 allowing the admission priority to be conveyed inside RSVP signaling 109 messages so that RSVP nodes can enforce selective bandwidth admission 110 control decision based on the call admission priority. This document 111 also provides three examples of a bandwidth allocation model which 112 can be used by RSVP-routers to enforce such admission priority on 113 every link. 115 1.1. Changes from previous versions 117 1.1.1. Changes from -00 to -01 119 The most significant changes are: 121 o adding a second RSVP Policy Element that contains the 122 application-level resource priority requirements (for example as 123 communicated in the SIP Resource-Priority Header) for scenarios 124 where priority calls transits through multiple administrative 125 domains. 127 o adding description of a third bandwidth allocation model 128 example: the Priority Bypass Model 130 o adding discussion on policies for mapping the various bandwidth 131 allocation model over the engineered capacity limits. 133 2. Overview of RSVP extensions and Operations 135 Let us consider the case where a call requiring ETS type service is 136 to be established, and more specifically that the preference to be 137 granted to this call is in terms of "admission priority" (as opposed 138 to preference granted through preemption of existing calls). By 139 "admission priority" we mean allowing that priority call to seize 140 resources from the engineered capacity that have been set-aside and 141 not made available to normal calls, or alternatively by allowing that 142 call to seize additional resources beyond the engineered capacity 143 limits applied to normal calls. 145 As described in [EMERG-IMP], the session establishment can be 146 conditioned to resource-based and policy-based admission control 147 achieved via RSVP signaling. In the case where the session control 148 protocol is SIP, the use of RSVP-based admission control by SIP is 149 specified in [SIP-RESOURCE]. 151 Devices involved in the session establishment are expected to be 152 aware of the application-level priority requirements of emergency 153 calls. Again considering the case where the session control protocol 154 is SIP, the SIP user agents can be made aware of the resource 155 priority requirements in the case of an emergency call using the 156 Resource-Priority Header mechanism specified in [SIP-PRIORITY]. 158 Where, as per our considered case, the application-level priority 159 requirement of the emergency call involves admission priority, the 160 devices involved in the upper-layer session establishment simply need 161 to: 163 (1) map the application-level priority requirements of the 164 emergency call into an RSVP "admission priority" level and 165 convey this information in the relevant RSVP messages used 166 for admission control. The admission priority is encoded 167 inside the new Admission Priority Policy Element defined in 168 this document. This way, the RSVP-based admission control 169 can take this information into account at every RSVP-enabled 170 network hop. 172 (2) Copy the application-level resource priority requirements 173 (e.g. as communicated in SIP Resource-Priority Header) 174 inside the new RSVP Application-Level Resource-Priority 175 Header Policy Element defined in this document. Conveying 176 the application-level resource priority requirements inside 177 the RSVP message allows this application level requirement 178 to be remapped into a different RSVP "admission priority" at 179 every administrative domain boundary based on the policy 180 applicable in that domain. 182 For example, the first domain may honor the resource 183 priority requirement and map it into a high RSVP admission 184 control priority while the second domain may decide to not 185 honor that resource priority requirement and map it into the 186 default (lowest) RSVP admission control priority. As another 187 example, we can consider the case where the resource 188 priority header enumerates several namespaces, as explicitly 189 allowed by [SIP-PRIORITY], for support of scenarios where 190 calls traverse multiple administrative domains using 191 different namespace. In that case, the relevant namespace 192 can be used at the domain boundary to map into an RSVP 193 Admission priority. It is not expected that the RSVP 194 Application-Level Resource-Priority Header Policy Element 195 would be taken into account at RSVP-hops within a given 196 administrative domain. It is expected to be used at 197 administrative domain boundaries only in order to set/reset 198 the RSVP Admission Priority Policy Element. 200 Note: The existence of pre-established inter-domain policy 201 agreements or Service Level Agreements may preclude the need 202 to take real-time action on step (2) at domain boundaries. 203 Also, step (2) may be applied to boundaries between various 204 signaling protocols, such as those advanced by the NSIS 205 working group. 207 Note that this operates in a very similar manner to the case where 208 the priority requirement of the emergency call involves preemption 209 priority. In that case, the devices involved in the session 210 establishment map the emergency call requirement into an RSVP 211 "preemption priority" level (or more accurately into both a setup 212 preemption level and a defending preemption priority level) and 213 convey this information in the relevant RSVP messages used for 214 admission control. This preemption priority information is encoded 215 inside the Preemption Priority Policy Element of [RSVP-PREEMP] and 216 thus, can be taken into account at every RSVP-enabled network hop. 218 2.1. Operations of Admission Priority 220 The RSVP Admission Priority policy element defined in this document 221 allows admission bandwidth to be allocated selectively to an 222 authorized priority service. Multiple models of bandwidth allocation 223 MAY be used to that end. However, the bandwidth allocation model MUST 224 ensure that it is possible to limit admission of non-priority traffic 225 [Respectively, lower priority traffic] to a maximum bandwidth which 226 can be configured below the link capacity (or below the bandwidth 227 granted by the scheduler to the relevant Diffserv PHB) thereby 228 ensuring that some capacity is effectively set aside for admission of 229 priority traffic [Respectively, higher priority traffic]. 231 A number of bandwidth allocation models have been defined in the IETF 232 for allocation of bandwidth across different classes of traffic 233 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 235 Those include the Maximum Allocation Model (MAM) defined in [DSTE- 236 MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These 237 same models MAY however be applied for allocation of bandwidth across 238 different levels of admission priority as defined in this document. 239 Sections 2.1.1 and 2.1.2 respectively illustrate how MAM and RDM can 240 indeed be used for support of admission priority. Section 2.1.3 241 illustrates how a simple "priority bypass" model can also be used for 242 support of admission priority. 244 For simplicity, operations with only a single "priority" level 245 (beyond non-priority) are illustrated here; However, the reader will 246 appreciate that operations with multiple priority levels can easily 247 be supported with these models. 249 In all the charts below: 250 x represents a non-priority session 251 o represents a priority session 253 2.1.1. 254 Illustration of Admission Priority with Maximum Allocation Model 256 This section illustrates operations of admission priority when a 257 Maximum Allocation Model is used for bandwidth allocation across non- 258 priority traffic and priority traffic. A property of the Maximum 259 Allocation Model is that priority traffic can not use more than the 260 bandwidth made available to priority traffic (even if the non- 261 priority traffic is not using all of the bandwidth available for it). 263 ----------------------- 264 ^ ^ ^ | | ^ 265 . . . | | . 266 Total . . . | | . Bandwidth 267 (1)(2)(3) | | . Available 268 Engi- . . . | | . for non-priority use 269 neered .or.or. | | . 270 . . . | | . 271 Capacity. . . | | . 272 v . . | | v 273 . . |--------------| --- 274 v . | | ^ 275 . | | . Bandwidth available for 276 v | | v priority use 277 ------------------------- 279 Chart 1. MAM Bandwidth Allocation 281 Chart 1 shows a link within a routed network conforming to this 282 document. On this link are two amounts of bandwidth available to two 283 types of traffic: non-priority and priority. 285 If the non-priority traffic load reaches the maximum bandwidth 286 available for non-priority, no additional non-priority sessions can 287 be accepted even if the bandwidth reserved for priority traffic is 288 not currently fully utilized. 290 With the Maximum Allocation Model, in the case where the priority 291 load reaches the maximum bandwidth reserved for priority calls, no 292 additional priority sessions can be accepted. 294 As illustrated in Chart 1, an operator may map the MAM model onto the 295 Engineered Capacity limits according to different policies. At one 296 extreme, where the proportion of priority traffic is reliably known 297 to be fairly small at all times and where there may be some safety 298 margin factored in the engineered capacity limits, the operator may 299 decide to configure the bandwidth available for non-priority use to 300 the full engineered capacity limits; effectively allowing the 301 priority traffic to ride within the safety margin of this engineered 302 capacity. This policy can be seen as an economically attractive 303 approach as all of the engineered capacity is made available to non- 304 priority calls. This policy illustrated as (1) in Chart 1. As an 305 example, if the engineered capacity limit on a given link is X, the 306 operator may configure the bandwidth available to non-priority 307 traffic to X, and the bandwidth available to priority traffic to 5% 308 of X. 310 At the other extreme, where the proportion of priority traffic may be 311 significant at times and the engineered capacity limits are very 312 tight, the operator may decide to configure the bandwidth available 313 to non-priority traffic and the bandwidth available to priority 314 traffic such that their sum is equal to the engineered capacity 315 limits. This guarantees that the total load across non-priority and 316 priority traffic is always below the engineered capacity and, in turn, 317 guarantees there will never be any QoS degradation. However, this 318 policy is less attractive economically as it prevents non-priority 319 calls from using the full engineered capacity, even when there is no 320 or little priority load, which is the majority of time. This policy 321 illustrated as (3) in Chart 1. As an example, if the engineered 322 capacity limit on a given link is X, the operator may configure the 323 bandwidth available to non-priority traffic to 95% of X, and the 324 bandwidth available to priority traffic to 5% of X. 326 Of course, an operator may also strike a balance anywhere in between 327 these two approaches. This policy illustrated as (2) in Chart 1. 329 Chart 2 shows some of the non-priority capacity of this link being 330 used. 332 ----------------------- 333 ^ ^ ^ | | ^ 334 . . . | | . 335 Total . . . | | . Bandwidth 336 . . . | | . Available 337 Engi- . . . | | . for non-priority use 338 neered .or.or. |xxxxxxxxxxxxxx| . 339 . . . |xxxxxxxxxxxxxx| . 340 Capacity. . . |xxxxxxxxxxxxxx| . 341 v . . |xxxxxxxxxxxxxx| v 342 . . |--------------| --- 343 v . | | ^ 344 . | | . Bandwidth available for 345 v | | v priority use 346 ------------------------- 347 Chart 2. Partial load of non-priority calls 349 Chart 3 shows the same amount of non-priority load being used at this 350 link, and a small amount of priority bandwidth being used. 352 ----------------------- 353 ^ ^ ^ | | ^ 354 . . . | | . 355 Total . . . | | . Bandwidth 356 . . . | | . Available 357 Engi- . . . | | . for non-priority use 358 neered .or.or. |xxxxxxxxxxxxxx| . 359 . . . |xxxxxxxxxxxxxx| . 360 Capacity. . . |xxxxxxxxxxxxxx| . 361 v . . |xxxxxxxxxxxxxx| v 362 . . |--------------| --- 363 v . | | ^ 364 . | | . Bandwidth available for 365 v |oooooooooooooo| v priority use 366 ------------------------- 368 Chart 3. Partial load of non-priority calls 369 & partial load of priority calls 371 Chart 4 shows the case where non-priority load equates or exceeds the 372 maximum bandwidth available to non-priority traffic. Note that 373 additional non-priority sessions would be rejected even if the 374 bandwidth reserved for priority sessions is not fully utilized. 376 ----------------------- 377 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 378 . . . |xxxxxxxxxxxxxx| . 379 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 380 . . . |xxxxxxxxxxxxxx| . Available 382 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 383 neered .or.or. |xxxxxxxxxxxxxx| . 384 . . . |xxxxxxxxxxxxxx| . 385 Capacity. . . |xxxxxxxxxxxxxx| . 386 v . . |xxxxxxxxxxxxxx| v 387 . . |--------------| --- 388 v . | | ^ 389 . | | . Bandwidth available for 390 v |oooooooooooooo| v priority use 391 ------------------------- 392 Chart 4. Full non-priority load 393 & partial load of priority calls 395 Although this is not expected to occur in practice (or to occur 396 extremely rarely) because of proper allocation of bandwidth to 397 priority traffic, Chart 5 shows for completeness the case where the 398 priority traffic equates or exceeds the bandwidth reserved for such 399 priority traffic. 401 In that case additional priority sessions could not be accepted. Note 402 that this does not mean that such calls are dropped altogether: they 403 may be handled by mechanisms which are beyond the scope of this 404 particular document (such as establishment through preemption of 405 existing non-priority sessions, or such as queueing of new priority 406 session requests until capacity becomes available again for priority 407 traffic). 409 ----------------------- 410 ^ ^ ^ |xxxxxxxxxxxxxx| ^ 411 . . . |xxxxxxxxxxxxxx| . 412 Total . . . |xxxxxxxxxxxxxx| . Bandwidth 413 . . . |xxxxxxxxxxxxxx| . Available 414 Engi- . . . |xxxxxxxxxxxxxx| . for non-priority use 415 neered .or.or. |xxxxxxxxxxxxxx| . 416 . . . |xxxxxxxxxxxxxx| . 417 Capacity. . . | | . 418 v . . | | v 419 . . |--------------| --- 420 v . |oooooooooooooo| ^ 421 . |oooooooooooooo| . Bandwidth available for 422 v |oooooooooooooo| v priority use 423 ------------------------- 425 Chart 5. Partial non-priority load & Full priority load 427 2.1.2. 428 Illustration of Admission Priority with Russian Dolls Model 430 This section illustrates operations of admission priority when a 431 Russian Dolls Model is used for bandwidth allocation across non- 432 priority traffic and priority traffic. A property of the Russian 433 Dolls Model is that priority traffic can use the bandwidth which is 434 not currently used by non-priority traffic. 436 As with the MAM model, an operator may map the RDM model onto the 437 Engineered Capacity limits according to different policies. The 438 operator may decide to configure the bandwidth available for non- 439 priority use to the full engineered capacity limits; As an example, 440 if the engineered capacity limit on a given link is X, the operator 441 may configure the bandwidth available to non-priority traffic to X, 442 and the bandwidth available to non-priority and priority traffic to 443 105% of X. 445 Alternatively, the operator may decide to configure the bandwidth 446 available to non-priority and priority traffic to the engineered 447 capacity limits; As an example, if the engineered capacity limit on a 448 given link is X, the operator may configure the bandwidth available 449 to non-priority traffic to 95% of X, and the bandwidth available to 450 non-priority and priority traffic to X. 452 Finally, the operator may decide to strike a balance in between. The 453 considerations presented for these policies in the previous section 454 in the MAM context are equally applicable to RDM. 456 Chart 6 shows the case where only some of the bandwidth available to 457 non-priority traffic is being used and a small amount of priority 458 traffic is in place. In that situation both new non-priority sessions 459 and new priority sessions would be accepted. 461 -------------------------------------- 462 |xxxxxxxxxxxxxx| . ^ 463 |xxxxxxxxxxxxxx| . Bandwidth . 464 |xxxxxxxxxxxxxx| . Available for . 465 |xxxxxxxxxxxxxx| . non-priority . 466 |xxxxxxxxxxxxxx| . use . 467 |xxxxxxxxxxxxxx| . . Bandwidth 468 | | . . available for 469 | | v . non-priority 470 |--------------| --- . and priority 471 | | . use 472 | | . 473 |oooooooooooooo| v 474 --------------------------------------- 476 Chart 6. Partial non-priority load & Partial Aggregate load 478 Chart 7 shows the case where all of the bandwidth available to non- 479 priority traffic is being used and a small amount of priority traffic 480 is in place. In that situation new priority sessions would be 481 accepted but new non-priority sessions would be rejected. 483 -------------------------------------- 484 |xxxxxxxxxxxxxx| . ^ 485 |xxxxxxxxxxxxxx| . Bandwidth . 486 |xxxxxxxxxxxxxx| . Available for . 487 |xxxxxxxxxxxxxx| . non-priority . 488 |xxxxxxxxxxxxxx| . use . 489 |xxxxxxxxxxxxxx| . . Bandwidth 490 |xxxxxxxxxxxxxx| . . available for 491 |xxxxxxxxxxxxxx| v . non-priority 492 |--------------| --- . and priority 493 | | . use 494 | | . 495 |oooooooooooooo| v 496 --------------------------------------- 498 Chart 7. Full non-priority load & Partial Aggregate load 500 Chart 8 shows the case where only some of the bandwidth available to 501 non-priority traffic is being used and a heavy load of priority 502 traffic is in place. In that situation both new non-priority sessions 503 and new priority sessions would be accepted. 504 Note that, as illustrated in Chart 7, priority calls use some of the 505 bandwidth currently not used by non-priority traffic. 507 -------------------------------------- 508 |xxxxxxxxxxxxxx| . ^ 509 |xxxxxxxxxxxxxx| . Bandwidth . 510 |xxxxxxxxxxxxxx| . Available for . 511 |xxxxxxxxxxxxxx| . non-priority . 512 |xxxxxxxxxxxxxx| . use . 513 | | . . Bandwidth 514 | | . . available for 515 |oooooooooooooo| v . non-priority 516 |--------------| --- . and priority 517 |oooooooooooooo| . use 518 |oooooooooooooo| . 519 |oooooooooooooo| v 520 --------------------------------------- 522 Chart 8. Partial non-priority load & Heavy Aggregate load 524 Chart 9 shows the case where all of the bandwidth available to non- 525 priority traffic is being used and all of the remaining available 526 bandwidth is used by priority traffic. In that situation new non- 527 priority sessions would be rejected. In that situation new priority 528 sessions could not be accepted right away. Those priority sessions 529 may be handled by mechanisms which are beyond the scope of this 530 particular document (such as established through preemption of 531 existing non-priority sessions, or such as queueing of new priority 532 session requests until capacity becomes available again for priority 533 traffic). This is not expected to occur (or to occur extremely 534 rarely) in practice because of proper allocation of bandwidth to 535 priority traffic (or more precisely because of proper sizing of the 536 difference in bandwidth allocated to non-priority traffic and 537 bandwidth allocated to non-priority & priority traffic). 539 -------------------------------------- 540 |xxxxxxxxxxxxxx| . ^ 541 |xxxxxxxxxxxxxx| . Bandwidth . 542 |xxxxxxxxxxxxxx| . Available for . 543 |xxxxxxxxxxxxxx| . non-priority . 544 |xxxxxxxxxxxxxx| . use . 545 |xxxxxxxxxxxxxx| . . Bandwidth 546 |xxxxxxxxxxxxxx| . . available for 547 |xxxxxxxxxxxxxx| v . non-priority 548 |--------------| --- . and priority 549 |oooooooooooooo| . use 550 |oooooooooooooo| . 551 |oooooooooooooo| v 552 --------------------------------------- 554 Chart 9. Full non-priority load & Full Aggregate load 556 2.1.3. 557 Illustration of Admission Priority with Priority Bypass Model 559 This section illustrates operations of admission priority when a 560 simple Priority Bypass Model is used for bandwidth allocation across 561 non-priority traffic and priority traffic. With the Priority Bypass 562 Model, non-priority traffic is subject to resource based admission 563 control while priority traffic simply bypasses the resource based 564 admission control. In other words: 565 - when a non-priority call arrives, this call is subject to 566 bandwidth admission control and is accepted if the current total load 567 (aggregate over non-priority and priority traffic) is below the 568 engineered/allocated bandwidth. 569 - when a priority call arrives, this call is admitted regardless 570 of the current load. 572 A property of this model is that a priority call is never rejected. 574 The rationale for this simple scheme is that, in practice in some 575 networks: 576 - the volume of priority calls is very low for the vast majority 577 of time, so it may not be economical to completely set aside 578 bandwidth for priority calls and preclude the utilization of 579 this bandwidth by normal calls in normal situations 580 - even in emergency periods where priority calls are more heavily 581 used, those always still represent a fairly small proportion of 582 the overall load which can be absorbed within the safety margin 583 of the engineered capacity limits. Thus, even if they are 584 admitted beyond the engineered bandwidth threshold, they are 585 unlikely to result in noticeable QoS degradation. 587 As with the MAM and RDM model, an operator may map the Priority 588 Bypass model onto the Engineered Capacity limits according to 589 different policies. The operator may decide to configure the 590 bandwidth limit for admission of non-priority traffic to the full 591 engineered capacity limits; As an example, if the engineered capacity 592 limit on a given link is X, the operator may configure the bandwidth 593 limit for non-priority traffic to X. Alternatively, the operator may 594 decide to configure the bandwidth limit for non-priority traffic to 595 below the engineered capacity limits (so that the sum of the non- 596 priority and priority traffic stays below the engineered capacity); 597 As an example, if the engineered capacity limit on a given link is X, 598 the operator may configure the bandwidth limit for non-priority 599 traffic to 95% of X. Finally, the operator may decide to strike a 600 balance in between. The considerations presented for these policies 601 in the previous sections in the MAM and RDM contexts are equally 602 applicable to the Priority Bypass Model. 604 Chart 10 shows illustrates the bandwidth allocation with the Priority 605 Bypass Model. 607 ----------------------- 608 ^ ^ | | ^ 609 . . | | . 610 Total . . | | . Bandwidth Limit 611 (1) (2) | | . (on non-priority + priority) 612 Engi- . . | | . for admission 613 neered . or . | | . of non-priority traffic 614 . . | | . 615 Capacity. . | | . 616 v . | | v 617 . |--------------| --- 618 . | | 619 v | | 620 | | 622 Chart 10. Priority Bypass Model Bandwidth Allocation 624 Chart 11 shows some of the non-priority capacity of this link being 625 used. In this situation, both new non-priority and new priority calls 626 would be accepted. 628 ----------------------- 629 ^ ^ |xxxxxxxxxxxxxx| ^ 630 . . |xxxxxxxxxxxxxx| . 631 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 632 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 633 Engi- . . | | . for admission 634 neered . or . | | . of non-priority traffic 635 . . | | . 636 Capacity. . | | . 637 v . | | v 638 . |--------------| --- 639 . | | 640 v | | 641 | | 643 Chart 11. Partial load of non-priority calls 645 Chart 12 shows the same amount of non-priority load being used at 646 this link, and a small amount of priority bandwidth being used. In 647 this situation, both new non-priority and new priority calls would be 648 accepted. 650 ----------------------- 651 ^ ^ |xxxxxxxxxxxxxx| ^ 652 . . |xxxxxxxxxxxxxx| . 653 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 654 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 655 Engi- . . |oooooooooooooo| . for admission 656 neered . or . | | . of non-priority traffic 657 . . | | . 658 Capacity. . | | . 659 v . | | v 660 . |--------------| --- 661 . | | 662 v | | 663 | | 665 Chart 12. Partial load of non-priority calls 666 & partial load of priority calls 668 Chart 13 shows the case where aggregate non-priority and priority 669 load exceeds the bandwidth limit for admission of non-priority 670 traffic. In this situation, any new non-priority call is rejected 671 while any new priority call is admitted. 673 ----------------------- 674 ^ ^ |xxxxxxxxxxxxxx| ^ 675 . . |xxxxxxxxxxxxxx| . 676 Total . . |xxxxxxxxxxxxxx| . Bandwidth Limit 677 (1) (2) |xxxxxxxxxxxxxx| . (on non-priority + priority) 678 Engi- . . |oooooooooooooo| . for admission 679 neered . or . |xxxooxxxooxxxo| . of non-priority traffic 680 . . |xxoxxxxxxoxxxx| . 681 Capacity. . |oxxxooooxxxxoo| . 682 v . |xxoxxxooxxxxxx| v 683 . |--------------| --- 684 . |oooooooooooooo| 685 v | | 686 | | 688 Chart 13. Full non-priority load 690 3. New Policy Elements 692 3.1. Admission Priority Policy Element 694 [RSVP-POLICY] defines extensions for supporting generic policy based 695 admission control in RSVP. These extensions include the standard 696 format of POLICY_DATA objects and a description of RSVP handling of 697 policy events. 699 The POLICY_DATA object contains one or more of Policy Elements, each 700 representing a different (and perhaps orthogonal) policy. As an 701 example, [RSVP-PREEMP] specifies the Preemption Priority Policy 702 Element. 704 This document defines a new Policy Element called the Admission 705 Priority Policy Element. 707 The format of Admission Priority policy element is as follows: 709 +-------------+-------------+-------------+-------------+ 710 | Length | P-Type = ADMISSION_PRI | 711 +-------------+-------------+-------------+-------------+ 712 | Flags | M. Strategy | Error Code | Reserved | 713 +-------------+-------------+-------------+-------------+ 714 | Rvd | Pri| Reserved | 715 +---------------------------+---------------------------+ 717 Length: 16 bits 718 Always 12. The overall length of the policy element, in bytes. 720 P-Type: 16 bits 721 ADMISSION_PRI = To be allocated by IANA 722 (see "IANA Considerations" section) 724 Flags: 8 bits 725 Reserved (always 0). 727 Merge Strategy: 8 bit (only applicable to multicast flows) 728 1 Take priority of highest QoS: recommended 729 2 Take highest priority: aggressive 730 3 Force Error on heterogeneous merge 732 Error code: 8 bits (only applicable to multicast flows) 733 0 NO_ERROR Value used for regular ADMISSION_PRI elements 734 2 HETEROGENEOUS This element encountered heterogeneous merge 736 Reserved: 8 bits 737 Always 0. 739 Reserved: 5 bits 740 Always 0. 742 Pri. (Admission Priority): 3 bits (unsigned) 743 The admission control priority of the flow, in terms of access 744 to network bandwidth in order to provide higher probability of 745 call completion to selected flows. Lower values represent higher 746 Priority. 0 represents the highest priority. A reservation 747 established without an Admission Priority policy element is 748 equivalent to a reservation established with the lowest 749 supported admission priority. 751 Bandwidth allocation models such as those described in section 752 2.1 are to be used by the RSVP router to achieve such increased 753 probability of call completion. The admission priority value 754 indicates the bandwidth constraint(s) of the bandwidth 755 constraint model in use which is(are) applicable to admission of 756 this RSVP reservation. 758 Reserved: 16 bits 759 Always 0. 761 Note that the Admission Priority Policy Element does NOT indicate 762 that this RSVP reservation is to preempt any call. If a priority 763 session justifies both admission priority and preemption priority, 764 the corresponding RSVP reservation needs to carry both an Admission 765 Priority Policy Element and a Preemption Priority Policy Element. 767 It has been identified that some ETS emergency type sessions would 768 need: 769 - to benefit from elevated admission priority 770 - to be able to preempt other ETS emergency type sessions (the 771 ones with lower preemption priorities) 772 - to not be able to preempt non-emergency sessions. 773 One approach to address this requirement is to add a new Flag in the 774 Preemption Priority Policy Element in order to reduce the scope of 775 the RSVP preemption mechanism to emergency sessions. Feedback is 776 sought on this requirement and potential solution. This will be 777 addressed further in next revisions of this document. 779 3.1.1. 780 Admission Priority Merging Rules 782 This session discusses alternatives for dealing with RSVP admission 783 priority in case of merging of reservations. As merging is only 784 applicable to multicast, this section also only applies to multicast 785 sessions. 787 3.1.1.1 Admission Priority Merging Strategies 789 In merging situations Local Decision Points (LDPs) may receive 790 multiple admission priority elements and must compute the admission 791 priority of the merged flow according to the following rules: 793 a. Participating admission priority elements are selected. 794 All admission priority elements are examined according to their 795 merging strategy to decide whether they should participate in the 796 merged result (as specified below). 798 b. The highest admission priority of all participating admission 799 priority elements is computed. 801 The remainder of this section describes the different merging 802 strategies the can be specified in the ADMISSION_PRI element. 804 3.1.1.2 Take priority of highest QoS 806 The ADMISSION_PRI element would participate in the merged reservation 807 only if it belongs to a flow that contributed to the merged QoS level 808 (i.e., that its QoS requirement does not constitute a subset of 809 another reservation.) A simple way to determine whether a flow 810 contributed to the merged QoS result is to compute the merged QoS 811 with and without it and to compare the results (although this is 812 clearly not the most efficient method). 814 The reasoning for this approach is that the highest QoS flow is the 815 one dominating the merged reservation and as such its priority should 816 dominate it as well. 818 3.1.1.3 Take highest priority 820 All ADMISSION_PRI elements participate in the merged reservation. 822 This strategy disassociates priority and QoS level, and therefore is 823 highly subject to free-riders and its inverse image, denial of 824 service. 826 3.1.1.4 Force error on heterogeneous merge 828 A ADMISSION_PRI element may participate in a merged reservation only 829 if all other flows in the merged reservation have the same QoS level 830 (homogeneous flows). 832 The reasoning for this approach assumes that the heterogeneous case 833 is relatively rare and too complicated to deal with, thus it better 834 be prohibited. 836 This strategy lends itself to denial of service, when a single 837 receiver specifying a non-compatible QoS level may cause denial of 838 service for all other receivers of the merged reservation. 840 Note: The determination of heterogeneous flows applies to QoS level 841 only (FLOWSPEC values), and is a matter for local (LDP) definition. 842 Other types of heterogeneous reservations (e.g. conflicting 843 reservation styles) are handled by RSVP and are unrelated to this 844 ADMISSION_PRI element. 846 3.1.2. 847 Modifying Admission Priority Elements 849 When POLICY_DATA objects are protected by integrity, LDPs should not 850 attempt to modify them. They must be forwarded as-is or else their 851 security envelope would be invalidated. In other cases, LDPs may 852 modify and merge incoming ADMISSION _PRI elements to reduce their 853 size and number according to the following rule: 855 Merging is performed for each merging strategy separately. 857 There is no known algorithm to merge ADMISSION_PRI element of 858 different merging strategies without losing valuable information that 859 may affect OTHER nodes. 861 - For each merging strategy, the highest QoS of all participating 862 ADMISSION _PRI elements is taken and is placed in an outgoing 863 ADMISSION _PRI element of this merging strategy. 865 - This approach effectively compresses the number of forwarded 866 ADMISSION _PRI elements to at most to the number of different 867 merging strategies, regardless of the number of receivers. 869 3.1.3. 870 Merging Error Processing 872 An Error Code is sent back (inside the Admission Priority Policy 873 Element) toward the appropriate receivers when an error involving 874 ADMISSION_PRI elements occur. 876 Heterogeneity 878 When a flow F1 with "Force Error on heterogeneous merge" merging 879 strategy set in its ADMISSION_PRI element encounters 880 heterogeneity, the ADMISSION_PRI element is sent back toward 881 receivers with the Heterogeneity error code set. 883 3.2. Application-Level Resource Priority Policy Element 885 This document defines another new Policy Element called the 886 Application-Level Resource Priority Element. 888 The format of Admission Priority policy element is as follows: 890 +-------------+-------------+-------------+-------------+ 891 | Length | P-Type = APP_RESOURCE_PRI | 892 +-------------+-------------+-------------+-------------+ 893 | Flags | M. Strategy | Error Code | Reserved | 894 +-------------+-------------+-------------+-------------+ 895 | ARP Namespace | ARP Priority| Reserved | 896 +---------------------------+---------------------------+ 898 Length: 16 bits 899 Always 12. The overall length of the policy element, in bytes. 901 P-Type: 16 bits 902 APP_RESOURCE_PRI = To be allocated by IANA 903 (see "IANA Considerations" section) 905 Flags: 8 bits 906 Reserved (always 0). 908 Merge Strategy: 8 bit (only applicable to multicast flows) 909 TBD 911 Error code: 8 bits (only applicable to multicast flows) 912 TBD 914 Reserved: 8 bits 915 Always 0. 917 ARP Namespace (Application-Level Resource Priority Namespace): 918 16 bits (unsigned) 919 Contains the namespace of the application-level resource 920 priority. This is encoded as a numerical value which represents 921 the position of the namespace in the "Resource-Priority 922 Namespace" IANA registry, starting with 0. Creation of this 923 registry has been requested to IANA in [SIP-PRIORITY]. 924 For example, as "dsn", "drsn", "q735", "ets" and "wps" are 925 currently the first, second, third, fourth and fifth namespaces 926 defined in the "Resource-Priority Namespace" registry, those are 927 respectively encoded as value 0, 1, 2, 3 and 4. 929 ARP Priority: (Application-Level Resource Priority Priority): 930 8 bits (unsigned) 931 Contains the priority value within the namespace of the 932 application-level resource priority. 933 This is encoded as a numerical value which represents the 934 priority defined in the "Resource-Priority Namespace" IANA 935 registry for the considered namespace, starting from 0 for the 936 highest priority and increasing as priority decreases. 937 For example, as "flash-override", "flash", "immediate", 938 "priority" and "routine" are the priorities in decreasing order 939 of priority registered for the "dsn" namespace, those are 940 respectively encoded as value 0, 1, 2, 3 and 4. 942 Reserved: 16 bits 943 Always 0. 945 Multiple instances of Application-Level Resource Priority Policy 946 Elements may appear in a POLICY_DATA object or in different 947 POLICY_DATA objects. This can be used to convey application-level 948 resource priority requirements in multiple namespaces in a single 949 RSVP message (in a similar manner to how multiple namespace 950 priorities can be conveyed in the SIP Resource-Priority Header of 951 [SIP-PRIORITY]). As discussed earlier, this is useful for calls which 952 transit through multiple administrative domains. 954 3.2.1. 955 Application-Level Resource Priority Merging Rules 957 This session discusses alternatives for dealing with RSVP 958 application-level resource priority in case of merging of 959 reservations. As merging is only applicable to multicast, this 960 section also only applies to multicast sessions. 962 This will be discussed in the next revision of this document. 964 [Editor's note: One approach could be to ensure that the reunion of 965 all the namespaces is included in the merge (ie if one receiver 966 includes namespace1.prio1 and another one includes namespace2.prio2, 967 the merged reservation will contain both namespace1.prio1 and 968 namespace2.prio2. Feedback on that is sought] 970 4. Security Considerations 972 The integrity of ADMISSION_PRI and APP_RESOURCE_PRI is guaranteed, as 973 any other policy element, by the encapsulation into a Policy Data 974 object [RSVP-POLICY]. The two optional security mechanisms discussed 975 in section 6 of [RSVP-POLICY] can be used to protect the 976 ADMISSION_PRI and APP_RESOURCE_PRI policy elements. 978 5. IANA Considerations 980 As specified in [POLICY-RSVP], Standard RSVP Policy Elements (P-type 981 values) are to be assigned by IANA as per "IETF Consensus" following 982 the policies outlined in [IANA-CONSIDERATIONS]. 984 IANA needs to allocate two P-Types from the Standard RSVP Policy 985 Element range: 986 - one P-Type to the Admission Priority Policy Element 987 - one P-Type to the Application-Level Resource Priority 988 Policy Element 990 6. Acknowledgments 992 We would like to thank An Nguyen for his encouragement to address 993 this topic and ongoing comments. Also, this document borrows heavily 994 from some of the work of S. Herzog on Preemption Priority Policy 995 Element [RSVP-PREEMP]. Dave Oran and Janet Gunn provided useful input 996 into this document. 998 7. Normative References 1000 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for 1001 Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. 1003 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 1004 for Emergency Telecommunication Service (ETS)", RFC 3690, February 1005 2004. 1007 [EMERG-IMP] F. Baker & J. Polk, "Implementing an Emergency 1008 Telecommunications Service for Real Time Services in the Internet 1009 Protocol Suite", draft-ietf-tsvwg-mlpp-that-works-04, Work in 1010 Progress 1012 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 1013 (RSVP)- Functional Specification", RFC 2205, September 1997. 1015 [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A 1016 Framework for Policy-based Admission Control", RFC 2753, January 2000. 1018 [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC 1019 2750, January 2000. 1021 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 1022 Element", RFC 3181, October 2001. 1024 [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth 1025 Constraints Model for Diffserv-aware MPLS Traffic Engineering", 1026 RFC 4125, June 2005. 1028 [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints 1029 Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June 1030 2005 1032 [SIP-PRIORITY] H. Schulzrinne & J. Polk. Communications Resource 1033 Priority for the Session Initiation Protocol (SIP), RFC4412, February 1034 2006. 1036 8. Informative References 1038 [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 1039 Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, 1040 October 2001. 1042 [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 1043 Cryptographic Authentication", RFC 2747, January 2000. 1045 [RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic 1046 Authentication -- Updated Message Type Value", RFC 3097, April 2001. 1048 [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, 1049 "Integration of Resource Management and Session Initiation Protocol 1050 (SIP)", RFC 3312, October 2002. 1052 9. Authors Address: 1054 Francois Le Faucheur 1055 Cisco Systems, Inc. 1056 Village d'Entreprise Green Side - Batiment T3 1057 400, Avenue de Roumanille 1058 06410 Biot Sophia-Antipolis 1059 France 1060 Email: flefauch@cisco.com 1062 James Polk 1063 Cisco Systems, Inc. 1064 2200 East President George Bush Turnpike 1065 Richardson, Texas 75082 1066 USA 1067 Email: jmpolk@cisco.com 1069 Ken Carlberg 1070 G11 1071 123a Versailles Circle 1072 Towson, MD. 21204 1073 USA 1074 email: carlberg@g11.org.uk 1076 10. IPR Statements 1078 The IETF takes no position regarding the validity or scope of any 1079 Intellectual Property Rights or other rights that might be claimed to 1080 pertain to the implementation or use of the technology described in 1081 this document or the extent to which any license under such rights 1082 might or might not be available; nor does it represent that it has 1083 made any independent effort to identify any such rights. Information 1084 on the procedures with respect to rights in RFC documents can be 1085 found in BCP 78 and BCP 79. 1087 Copies of IPR disclosures made to the IETF Secretariat and any 1088 assurances of licenses to be made available, or the result of an 1089 attempt made to obtain a general license or permission for the use of 1090 such proprietary rights by implementers or users of this 1091 specification can be obtained from the IETF on-line IPR repository at 1092 http://www.ietf.org/ipr. 1094 The IETF invites any interested party to bring to its attention any 1095 copyrights, patents or patent applications, or other proprietary 1096 rights that may cover technology that may be required to implement 1097 this standard. 1098 Please address the information to the IETF at ietf-ipr@ietf.org. 1100 11. Disclaimer of Validity 1102 This document and the information contained herein are provided on an 1103 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1104 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1105 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1106 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1107 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1108 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1110 12. Copyright Notice 1112 Copyright (C) The Internet Society (2006). This document is subject 1113 to the rights, licenses and restrictions contained in BCP 78, and 1114 except as set forth therein, the authors retain all their rights.