idnits 2.17.1 draft-lefaucheur-emergency-rsvp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 732. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 709. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 722. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 11) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 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 24 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 (October 2005) is 6766 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 57, but not defined == Missing Reference: 'POLICY-RSVP' is mentioned on line 611, but not defined == Missing Reference: 'IANA-CONSIDERATIONS' is mentioned on line 613, 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') == Outdated reference: A later version (-04) exists of draft-ietf-tsvwg-mlpp-that-works-02 ** 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: 12 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Admission Priority Policy Element October 2005 3 Internet Draft Francois Le Faucheur 4 James Polk 5 Cisco Systems, Inc. 7 draft-lefaucheur-emergency-rsvp-00.txt 8 Expires: March 2006 October 2005 10 RSVP Admission Priority Policy Element for Emergency Services 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Abstract 36 An Emergency Telecommunications Service (ETS) requires the ability to 37 provide an elevated probability of call completion to an authorized 38 user in times of crisis. When supported over the Internet Protocol 39 suite, this may be achieved through an admission control solution 40 which supports call preemption capabilities as well as admission 41 priority capabilities, whereby some resources (e.g. bandwidth) are 42 reserved for emergency services only. 44 Admission Priority Policy Element October 2005 46 This document specifies RSVP extensions necessary for supporting such 47 admission priority capabilities. 49 Copyright Notice 50 Copyright (C) The Internet Society. (2005) 52 Specification of Requirements 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 56 document are to be interpreted as described in [RFC2119]. 58 1. Introduction 60 [EMERG-RQTS] and [EMERG-TEL] detail requirements for an Emergency 61 Telecommunications Service (ETS). The key requirement is to guarantee 62 superior probability of call completion from an authorized user in 63 times of crisis. To that end, some of these types of services require 64 that the network be capable of preempting calls; others do not 65 involve preemption but instead rely on another network mechanism 66 which we refer throughout this document as "admission priority" 67 whereby some resources (e.g. bandwidth) is set aside for the 68 emergency services only, in order to obtain a high probability of 69 call completion for those. 71 [EMERG-IMP] describes the call and admission control procedures (at 72 initial call set up, as well as after call establishment through 73 maintenance of a continuing call model of the status of all calls) 74 which allow support of an Emergency Telecommunications Service. 75 [EMERG-IMP] also describes how these call and admission control 76 procedures can be realized using the Resource reSerVation Protocol 77 [RSVP] along with its associated protocol suite and extensions, 78 including those for policy based admission control ([FW-POLICY], 79 [RSVP-POLICY]), for user authentication and authorization ([RSVP-ID]) 80 and for integrity and authentication of RSVP messages ([RSVP-CRYPTO- 81 1], [RSVP-CRYPTO-2]). 83 Furthermore, [EMERG-IMP] describes how the RSVP Signaled Preemption 84 Priority Policy Element specified in [RSVP-PREEMP] can be used to 85 enforce the call preemption needed by some services of the ETS. 87 This document specifies RSVP extensions which can be used to enforce 88 the "admission priority" required by other services of the ETS. 90 1.1. Changes from previous versions 92 Admission Priority Policy Element October 2005 94 This is the initial version of the document 96 2. Overview of RSVP extensions and Operations 98 Let us consider the case where a call requiring Internet Emergency 99 Preference Service is to be established, and more specifically that 100 the preference to be granted to this call is in terms of admission 101 priority (i.e. by allowing that call to seize resources that have 102 been set-aside and not made available to normal calls) and that the 103 preference to be granted to this new call does not involve preempting 104 existing calls. 106 As described in [EMERG-IMP], the session establishment can be 107 conditioned to resource-based and policy-based admission control 108 achieved via RSVP signaling. In the case where the session control 109 protocol is SIP, the use of RSVP-based admission control by SIP is 110 specified in [SIP-RESOURCE]. 112 Devices involved in the session establishment are expected to be 113 aware of the priority requirements of emergency calls. Again, in the 114 case where the session control protocol is SIP, the SIP user agents 115 can be aware of the resource priority requirements in the case of an 116 emergency call using mechanisms specified in [SIP-PRIORITY]. 118 Where, as per our considered case, the priority requirement of the 119 emergency call involves admission priority, the devices involved in 120 the session establishment simply need to map the priority 121 requirements of the emergency call into an RSVP "admission priority" 122 level and convey this information in the relevant RSVP messages used 123 for admission control. The admission priority is encoded inside the 124 new Admission Priority Policy Element defined in this document. This 125 way, the RSVP-based admission control can take this information into 126 account at every RSVP-enabled network hop. 128 Note that this operates in a very similar manner to the case where 129 the priority requirement of the emergency call involves preemption 130 priority. In that case, the devices involved in the session 131 establishment map the emergency call requirement into an RSVP 132 "preemption priority" level (or more accurately into both a setup 133 preemption level and a defending preemption priority level) and 134 convey this information in the relevant RSVP messages used for 135 admission control. This preemption priority information is encoded 136 inside the Preemption Priority Policy Element of [RSVP-PREEMP] and 137 thus, can be taken into account at every RSVP-enabled network hop. 139 2.1. Operations of Admission Priority 141 Admission Priority Policy Element October 2005 143 The RSVP admission priority defined in this document allows admission 144 bandwidth to be allocated for use by an authorized priority service. 145 Multiple models of bandwidth allocation MAY be used to that end. 146 However, the bandwidth allocation model MUST ensure that it is 147 possible to limit admission of non-priority traffic [Respectively, 148 lower priority traffic] to a maximum bandwidth which can be 149 configured below the link capacity (or below the bandwidth granted by 150 the scheduler to the relevant Diffserv PHB) thereby ensuring that 151 some capacity is effectively set aside for admission of priority 152 traffic [Respectively, higher priority traffic]. 154 A number of bandwidth allocation models have been defined in the IETF 155 for allocation of bandwidth across different classes of traffic 156 trunks in the context of Diffserv-aware MPLS Traffic Engineering. 157 Those include the Maximum Allocation Model (MAM) defined in [DSTE- 158 MAM] and the Russian Dolls Model (RDM) specified in [DSTE-RDM]. These 159 same models MAY however be applied for allocation of bandwidth across 160 different levels of admission priority as defined in this document. 161 This section illustrates how MAM and RDM can indeed be used for 162 support of admission priority. For simplicity, operations with only a 163 single "priority" level (beyond non-priority) is illustrated here; 164 However, the reader will appreciate that operations with multiple 165 priority levels can easily be supported with these models. 167 In all the charts below: 168 x represents a non-priority session 169 o represents a priority session 171 2.1.1. 172 Illustration of Admission Priority with Maximum Allocation Model 174 This section illustrates operations of admission priority when a 175 Maximum Allocation Model is used for bandwidth allocation across non- 176 priority traffic and priority traffic. A property of the Maximum 177 Allocation Model is that priority traffic can not use more than the 178 bandwidth reserved for priority traffic (even if the non-priority 179 traffic is not using all of the bandwidth available for it). 181 ----------------------- 182 ^ | | ^ 183 . | | . 184 Total . | | . Bandwidth 185 . | | . Available 186 Avail . | | . for non-priority use 187 . | | . 188 BW . | | . 189 . | | . 190 . | | v 191 . |--------------| --- 193 Admission Priority Policy Element October 2005 195 . | | ^ 196 . | | . Bandwidth reserved for 197 v | | v priority use 198 ------------------------- 200 Chart 1. Overall Link Capacity 202 Chart 1 shows a link within a routed network conforming to this 203 document. On this link are two amounts of bandwidth available to two 204 types of traffic: non-priority and priority. The aggregate of the 205 two amounts equals the total link capacity (or the total capacity 206 granted to the corresponding Diffserv Per Hop Behavior). 207 If the non-priority traffic load reaches the maximum bandwidth 208 available for non-priority, no additional non-priority sessions can 209 be accepted even if the bandwidth reserved for priority traffic is 210 not currently utilized. 212 With the Maximum Allocation Model, in the case where the priority 213 load reaches the maximum bandwidth reserved for priority calls, no 214 additional priority sessions can be accepted. 216 Chart 2 shows some of the non-priority capacity of this link being 217 used. 219 ---------------------- 220 ^ | | ^ 221 . | | . 222 Total . | | . Bandwidth 223 . | | . Available 224 Avail . |xxxxxxxxxxxxxx| . for non-priority use 225 . |xxxxxxxxxxxxxx| . 226 BW . |xxxxxxxxxxxxxx| . 227 . |xxxxxxxxxxxxxx| . 228 . |xxxxxxxxxxxxxx| v 229 . |--------------| --- 230 . | | ^ 231 . | | . Bandwidth reserved for 232 v | | v_ priority use 233 ---------------------- 235 Chart 2. Partial load of non-priority calls 237 Chart 3 shows the same amount of non-priority load being used at this 238 link, and a small amount of priority bandwidth being used. 240 ---------------------- 241 ^ | | ^ 242 . | | . 244 Admission Priority Policy Element October 2005 246 Total . | | . Bandwidth 247 . | | . Available 248 Avail . |xxxxxxxxxxxxxx| . for non-priority use 249 . |xxxxxxxxxxxxxx| . 250 BW . |xxxxxxxxxxxxxx| . 251 . |xxxxxxxxxxxxxx| . 252 . |xxxxxxxxxxxxxx| v 253 . |--------------| --- 254 . | | ^ 255 . | | . Bandwidth reserved for 256 v |oooooooooooooo| v priority use 257 ---------------------- 259 Chart 3. Partial load of non-priority calls 260 & partial load of priority calls 262 Chart 4 shows the case where non-priority load equates or exceeds the 263 maximum bandwidth available to non-priority traffic. Note that 264 additional non-priority sessions would be rejected even if the 265 bandwidth reserved for priority sessions is not fully utilized. 267 ---------------------- 268 ^ |xxxxxxxxxxxxxx| ^ 269 . |xxxxxxxxxxxxxx| . 270 Total . |xxxxxxxxxxxxxx| . Bandwidth 271 . |xxxxxxxxxxxxxx| . Available 272 Avail . |xxxxxxxxxxxxxx| . for non-priority use 273 . |xxxxxxxxxxxxxx| . 274 BW . |xxxxxxxxxxxxxx| . 275 . |xxxxxxxxxxxxxx| . 276 . |xxxxxxxxxxxxxx| v 277 . |--------------| --- 278 . | | ^ 279 . | | . Bandwidth reserved for 280 v |oooooooooooooo| v priority use 281 ---------------------- 283 Chart 4. Full non-priority load 284 & partial load of priority calls 286 Although this is not expected to occur in practice because of proper 287 allocation of bandwidth to priority traffic, for completeness Chart 5 288 shows the case where there priority traffic equates or exceeds the 289 bandwidth reserved for such priority traffic. 290 In that case additional priority sessions could not be accepted. They 291 may be handled by mechanisms which are beyond the scope of this 292 particular document (such as established through preemption of 294 Admission Priority Policy Element October 2005 296 existing non-priority sessions, or new priority session requests 297 could be queues until capacity becomes available again for priority 298 traffic). 300 ---------------------- 301 ^ |xxxxxxxxxxxxxx| ^ 302 . |xxxxxxxxxxxxxx| . 303 Total . |xxxxxxxxxxxxxx| . Bandwidth 304 . |xxxxxxxxxxxxxx| . Available 305 Avail . |xxxxxxxxxxxxxx| . for non-priority use 306 . |xxxxxxxxxxxxxx| . 307 BW . |xxxxxxxxxxxxxx| . 308 . | | . 309 . | | v 310 . |--------------| --- 311 . |oooooooooooooo| ^ 312 . |oooooooooooooo| . Bandwidth reserved for 313 v |oooooooooooooo| v priority use 314 ---------------------- 316 Chart 5. Partial non-priority load & Full priority load 318 2.1.2. 319 Illustration of Admission Priority with Russian Dolls Model 321 This section illustrates operations of admission priority when a 322 Russian Dolls Model is used for bandwidth allocation across non- 323 priority traffic and priority traffic. A property of the Russian 324 Dolls Model is that priority traffic can use the bandwidth which is 325 not currently used by non-priority traffic. 327 Chart 6 shows the case where only some of the bandwidth available to 328 non-priority traffic is being used and a small amount of priority 329 traffic is in place. In that situation both new non-priority sessions 330 and new priority sessions would be accepted. 332 -------------------------------------- 333 |xxxxxxxxxxxxxx| . ^ 334 |xxxxxxxxxxxxxx| . Bandwidth . 335 |xxxxxxxxxxxxxx| . Available for . 336 |xxxxxxxxxxxxxx| . non-priority . 337 |xxxxxxxxxxxxxx| . use . 338 |xxxxxxxxxxxxxx| . . Bandwidth 339 | | . . available for 340 | | v . non-priority 341 |--------------| --- . and priority 342 | | . use 343 | | . 344 |oooooooooooooo| v 346 Admission Priority Policy Element October 2005 348 --------------------------------------- 350 Chart 6. Partial non-priority load & Partial Aggregate load 352 Chart 7 shows the case where all of the bandwidth available to non- 353 priority traffic is being used and a small amount of priority traffic 354 is in place. In that situation new priority sessions would be 355 accepted but new non-priority sessions would be rejected. 357 -------------------------------------- 358 |xxxxxxxxxxxxxx| . ^ 359 |xxxxxxxxxxxxxx| . Bandwidth . 360 |xxxxxxxxxxxxxx| . Available for . 361 |xxxxxxxxxxxxxx| . non-priority . 362 |xxxxxxxxxxxxxx| . use . 363 |xxxxxxxxxxxxxx| . . Bandwidth 364 |xxxxxxxxxxxxxx| . . available for 365 |xxxxxxxxxxxxxx| v . non-priority 366 |--------------| --- . and priority 367 | | . use 368 | | . 369 |oooooooooooooo| v 370 --------------------------------------- 372 Chart 7. Full non-priority load & Partial Aggregate load 374 Chart 8 shows the case where only some of the bandwidth available to 375 non-priority traffic is being used and a heavy load of priority 376 traffic is in place. In that situation both new non-priority sessions 377 and new priority sessions would be accepted. 378 Note that, as illustrated in Chart 7, priority calls use some of the 379 bandwidth currently not used by non-priority traffic. 381 -------------------------------------- 382 |xxxxxxxxxxxxxx| . ^ 383 |xxxxxxxxxxxxxx| . Bandwidth . 384 |xxxxxxxxxxxxxx| . Available for . 385 |xxxxxxxxxxxxxx| . non-priority . 386 |xxxxxxxxxxxxxx| . use . 387 | | . . Bandwidth 388 | | . . available for 389 |oooooooooooooo| v . non-priority 390 |--------------| --- . and priority 391 |oooooooooooooo| . use 392 |oooooooooooooo| . 393 |oooooooooooooo| v 394 --------------------------------------- 396 Admission Priority Policy Element October 2005 398 Chart 8. Partial non-priority load & Heavy Aggregate load 400 Chart 9 shows the case where all of the bandwidth available to non- 401 priority traffic is being used and all of the remaining available 402 bandwidth is used by priority traffic. In that situation new non- 403 priority sessions would be rejected. In that situation new priority 404 sessions could not be accepted right away. Those priority sessions 405 may be handled by mechanisms which are beyond the scope of this 406 particular document (such as established through preemption of 407 existing non-priority sessions, or new priority session requests 408 could be queues until capacity becomes available again for priority 409 traffic). This is not expected to occur in practice because of proper 410 allocation of bandwidth to priority traffic (or more precisely 411 because of proper sizing of the difference in bandwidth allocated to 412 non-priority traffic and bandwidth allocated to non-priority & 413 priority traffic). 415 -------------------------------------- 416 |xxxxxxxxxxxxxx| . ^ 417 |xxxxxxxxxxxxxx| . Bandwidth . 418 |xxxxxxxxxxxxxx| . Available for . 419 |xxxxxxxxxxxxxx| . non-priority . 420 |xxxxxxxxxxxxxx| . use . 421 |xxxxxxxxxxxxxx| . . Bandwidth 422 |xxxxxxxxxxxxxx| . . available for 423 |xxxxxxxxxxxxxx| v . non-priority 424 |--------------| --- . and priority 425 |oooooooooooooo| . use 426 |oooooooooooooo| . 427 |oooooooooooooo| v 428 --------------------------------------- 430 Chart 8. Full non-priority load & Full Aggregate load 432 3. Admission Priority Policy Element 434 [RSVP-POLICY] defines extensions for supporting generic policy based 435 admission control in RSVP. These extensions include the standard 436 format of POLICY_DATA objects and a description of RSVP handling of 437 policy events. 439 The POLICY_DATA object contains one or more of Policy Elements, each 440 representing a different (and perhaps orthogonal) policy. As an 441 example [RSVP-PREEMP] specifies the Preemption Priority Policy 442 Element. 444 Admission Priority Policy Element October 2005 446 This document defines a new Policy Element called the Admission 447 Priority Policy Element. 449 The format of Admission Priority policy element is as follows: 451 +-------------+-------------+-------------+-------------+ 452 | Length (12) | P-Type = ADMISSION_PRI | 453 +-------------+-------------+-------------+-------------+ 454 | Flags | M. Strategy | Error Code | Reserved(0) | 455 +-------------+-------------+-------------+-------------+ 456 | Admission Priority | Reserved (0) | 457 +---------------------------+---------------------------+ 459 Length: 16 bits 460 Always 12. The overall length of the policy element, in bytes. 462 P-Type: 16 bits 463 ADMISSION_PRI = To be allocated by IANA 464 (see "IANA Considerations" section) 466 Flags: 8 bits 467 Reserved (always 0). 469 Merge Strategy: 8 bit 470 1 Take priority of highest QoS: recommended 471 2 Take highest priority: aggressive 472 3 Force Error on heterogeneous merge 474 Error code: 8 bits 475 0 NO_ERROR Value used for regular ADMISSION_PRI elements 476 2 HETEROGENEOUS This element encountered heterogeneous merge 478 Reserved: 8 bits 479 Always 0. 481 Admission Priority: 16 bit (unsigned) 482 The admission control priority of the flow, in terms of access 483 to resources set aside in order to provide higher probability of 484 call completion to selected flows. Higher values represent 485 higher Priority. A reservation established without an Admission 486 Priority policy element is equivalent to a reservation 487 established with an Admission Priority policy element whose 488 Admission Priority value is 0. 490 Reserved: 16 bits 491 Always 0. 493 Admission Priority Policy Element October 2005 495 4. Admission Priority Merging Rules 497 This session discusses alternatives for dealing with RSVP admission 498 priority in case of merging of reservations. As merging is only 499 applicable to multicast, this section also only applies to multicast 500 sessions. 502 4.1. Admission Priority Merging Strategies 504 In merging situations Local Decision Points (LDPs) may receive 505 multiple preemption elements and must compute the admission priority 506 of the merged flow according to the following rules: 508 a. Participating admission priority elements are selected. 509 All admission priority elements are examined according to their 510 merging strategy to decide whether they should participate in the 511 merged result (as specified below). 513 b. The highest admission priority of all participating admission 514 priority elements is computed. 516 The remainder of this section describes the different merging 517 strategies the can be specified in the ADMISSION_PRI element. 519 4.1.1. 520 Take priority of highest QoS 522 The ADMISSION_PRI element would participate in the merged reservation 523 only if it belongs to a flow that contributed to the merged QoS level 524 (i.e., that its QoS requirement does not constitute a subset of 525 another reservation.) A simple way to determine whether a flow 526 contributed to the merged QoS result is to compute the merged QoS 527 with and without it and to compare the results (although this is 528 clearly not the most efficient method). 530 The reasoning for this approach is that the highest QoS flow is the 531 one dominating the merged reservation and as such its priority should 532 dominate it as well. 534 4.1.2. 535 Take highest priority 537 All ADMISSION_PRI elements participate in the merged reservation. 539 This strategy disassociates priority and QoS level, and therefore is 540 highly subject to free-riders and its inverse image, denial of 541 service. 543 4.1.3. 544 Force error on heterogeneous merge 546 A ADMISSION_PRI element may participate in a merged reservation only 548 Admission Priority Policy Element October 2005 550 if all other flows in the merged reservation have the same QoS level 551 (homogeneous flows). 553 The reasoning for this approach assumes that the heterogeneous case 554 is relatively rare and too complicated to deal with, thus it better 555 be prohibited. 557 This strategy lends itself to denial of service, when a single 558 receiver specifying a non-compatible QoS level may cause denial of 559 service for all other receivers of the merged reservation. 561 Note: The determination of heterogeneous flows applies to QoS level 562 only (FLOWSPEC values), and is a matter for local (LDP) definition. 563 Other types of heterogeneous reservations (e.g. conflicting 564 reservation styles) are handled by RSVP and are unrelated to this 565 ADMISSION_PRI element. 567 4.2. Modifying Admission Priority Elements 569 When POLICY_DATA objects are protected by integrity, LDPs should not 570 attempt to modify them. They must be forwarded as-is or else their 571 security envelope would be invalidated. In other cases, LDPs may 572 modify and merge incoming ADMISSION _PRI elements to reduce their 573 size and number according to the following rule: 575 Merging is performed for each merging strategy separately. 577 There is no known algorithm to merge ADMISSION_PRI element of 578 different merging strategies without losing valuable information that 579 may affect OTHER nodes. 581 - For each merging strategy, the highest QoS of all participating 582 ADMISSION _PRI elements is taken and is placed in an outgoing 583 ADMISSION _PRI element of this merging strategy. 585 - This approach effectively compresses the number of forwarded 586 ADMISSION _PRI elements to at most to the number of different 587 merging strategies, regardless of the number of receivers. 589 5. Error Processing 591 An Error Code is sent back (inside the Admission Priority Policy 592 Element) toward the appropriate receivers when an error involving 593 ADMISSION_PRI elements occur. 595 Heterogeneity 597 Admission Priority Policy Element October 2005 599 When a flow F1 with "Force Error on heterogeneous merge" merging 600 strategy set in its ADMISSION_PRI element encounters 601 heterogeneity, the ADMISSION_PRI element is sent back toward 602 receivers with the Heterogeneity error code set. 604 6. Security Considerations 606 The integrity of ADMISSION_PRI is guaranteed, as any other policy 607 element, by the encapsulation into a Policy Data object [RSVP-POLICY]. 609 7. IANA Considerations 611 As specified in [POLICY-RSVP], Standard RSVP Policy Elements (P-type 612 values) are to be assigned by IANA as per "IETF Consensus" following 613 the policies outlined in [IANA-CONSIDERATIONS]. 615 IANA needs to allocate a P-Type from the Standard RSVP Policy Element 616 range to the Admission Priority Policy Element. 618 8. Acknowledgments 620 We would like to thank An Nguyen for his encouragement to address 621 this topic and comments. Also, this document borrows heavily from 622 some of the work of S. Herzog on Preemption Priority Policy Element 623 [RSVP-PREEMP]. 625 9. Normative References 627 [EMERG-RQTS] Carlberg, K. and R. Atkinson, "General Requirements for 628 Emergency Telecommunication Service (ETS)", RFC 3689, February 2004. 630 [EMERG-TEL] Carlberg, K. and R. Atkinson, "IP Telephony Requirements 631 for Emergency Telecommunication Service (ETS)", RFC 3690, February 632 2004. 634 [EMERG-IMP] F. Baker & J. Polk, Implementing an Emergency 635 Telecommunications Service for Real Time Services in the Internet 636 Protocol Suite, draft-ietf-tsvwg-mlpp-that-works-02, Work in Progress 638 [RSVP] Braden, R., ed., et al., "Resource ReSerVation Protocol 639 (RSVP)- Functional Specification", RFC 2205, September 1997. 641 [FW-POLICY] Yavatkar, R., Pendarakis, D., and R. Guerin, "A 642 Framework for Policy-based Admission Control", RFC 2753, January 2000. 644 Admission Priority Policy Element October 2005 646 [RSVP-POLICY] Herzog, S., "RSVP Extensions for Policy Control", RFC 647 2750, January 2000. 649 [RSVP-PREEMP] Herzog, S., "Signaled Preemption Priority Policy 650 Element", RFC 3181, October 2001. 652 [DSTE-MAM] Le Faucheur & Lai, "Maximum Allocation Bandwidth 653 Constraints Model for Diffserv-aware MPLS Traffic Engineering", 654 RFC 4125, June 2005. 656 [DSTE-RDM] Le Faucheur et al, Russian Dolls Bandwidth Constraints 657 Model for Diffserv-aware MPLS Traffic Engineering, RFC 4127, June 658 2005 660 10. Informative References 662 [RSVP-ID] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T., 663 Herzog, S., and R. Hess, "Identity Representation for RSVP", RFC 3182, 664 October 2001. 666 [RSVP-CRYPTO-1] Baker, F., Lindell, B., and M. Talwar, "RSVP 667 Cryptographic Authentication", RFC 2747, January 2000. 669 [RSVP-CRYPTO-2] Braden, R. and L. Zhang, "RSVP Cryptographic 670 Authentication -- Updated Message Type Value", RFC 3097, April 2001. 672 [SIP-RESOURCE] Camarillo, G., Marshall, W., and J. Rosenberg, 673 "Integration of Resource Management and Session Initiation Protocol 674 (SIP)", RFC 3312, October 2002. 676 [SIP-PRIORITY] H. Schulzrinne & J. Polk. Communications Resource 677 Priority for the Session Initiation Protocol (SIP), draft-ietf-sip- 678 resource-priority-10, work in progress 680 11. Authors Address: 682 Francois Le Faucheur 683 Cisco Systems, Inc. 684 Village d'Entreprise Green Side - Batiment T3 685 400, Avenue de Roumanille 686 06410 Biot Sophia-Antipolis 687 France 688 Email: flefauch@cisco.com 690 James Polk 691 Cisco Systems, Inc. 692 2200 East President George Bush Turnpike 694 Admission Priority Policy Element October 2005 696 Richardson, Texas 75082 697 USA 698 Email: jmpolk@cisco.com 700 12. IPR Statements 702 The IETF takes no position regarding the validity or scope of any 703 Intellectual Property Rights or other rights that might be claimed to 704 pertain to the implementation or use of the technology described in 705 this document or the extent to which any license under such rights 706 might or might not be available; nor does it represent that it has 707 made any independent effort to identify any such rights. Information 708 on the procedures with respect to rights in RFC documents can be 709 found in BCP 78 and BCP 79. 711 Copies of IPR disclosures made to the IETF Secretariat and any 712 assurances of licenses to be made available, or the result of an 713 attempt made to obtain a general license or permission for the use of 714 such proprietary rights by implementers or users of this 715 specification can be obtained from the IETF on-line IPR repository at 716 http://www.ietf.org/ipr. 718 The IETF invites any interested party to bring to its attention any 719 copyrights, patents or patent applications, or other proprietary 720 rights that may cover technology that may be required to implement 721 this standard. 722 Please address the information to the IETF at ietf-ipr@ietf.org. 724 13. Disclaimer of Validity 726 This document and the information contained herein are provided on an 727 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 728 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 729 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 730 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 731 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 732 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 734 14. Copyright Notice 736 Copyright (C) The Internet Society (2005). This document is subject 737 to the rights, licenses and restrictions contained in BCP 78, and 738 except as set forth therein, the authors retain all their rights.