idnits 2.17.1 draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 date (May 26, 2010) is 5084 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) == Outdated reference: A later version (-06) exists of draft-polk-tsvwg-intserv-multiple-tspec-03 -- Possible downref: Normative reference to a draft: ref. 'I-D.polk-tsvwg-intserv-multiple-tspec' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-03) exists of draft-ietf-avt-ecn-for-rtp-01 == Outdated reference: A later version (-10) exists of draft-ietf-intarea-router-alert-considerations-00 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-security-groupkeying-05 Summary: 2 errors (**), 0 flaws (~~), 5 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 A. Kudur 4 Intended status: Standards Track A. Narayanan 5 Expires: November 27, 2010 Cisco 6 May 26, 2010 8 Multiple Preemption Priority Policy Element for RSVP 9 draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt 11 Abstract 13 RSVP Extensions are being defined allowing an endpoint to signal 14 alternate "bandwidths" of interest in case the preferred bandwidth is 15 not available and allowing the RSVP routers to collectively establish 16 the reservation with the highest currently achievable bandwidth among 17 the signaled set. This can be used to achieve efficient dynamic 18 endpoint codec adjustment. The present document presents a 19 complementary set of extensions, allowing the dynamic bandwidth 20 selection to reflect a different reservation priority for each of the 21 multiple "bandwidth" associated with a reservation. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on November 27, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 59 2. Overview of RSVP Extensions and Operations . . . . . . . . . . 5 60 2.1. Policy Example 1 . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Policy Example 2 . . . . . . . . . . . . . . . . . . . . . 7 62 3. Multiple Preemption Priority Policy Element Format . . . . . . 9 63 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 11 64 4.1. Default Handling . . . . . . . . . . . . . . . . . . . . . 11 65 4.2. Associating Priorities With TSPECs and FLOWSPECs . . . . . 11 66 4.3. Merging Rules . . . . . . . . . . . . . . . . . . . . . . 12 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 68 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 14 69 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 14 70 5.3. Use of IPsec for Security Protection of RSVP . . . . . . . 15 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 72 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 78 1. Introduction 80 Guaranteed QoS for some applications with tight QoS requirements may 81 be achieved by reserving resources in each node on the end-to-end 82 path. The Resource ReSerVation Protocol (RSVP) ([RFC2205]) is a 83 protocol specified by the IETF supporting such on-path QoS signaling 84 and resource reservation. In particular, RSVP can be used (as 85 specified in [RFC2210]) to support the Control-Load ([RFC2211]) and 86 Guaranteed ([RFC2212]) services of the integrated services (IntServ) 87 framework. 89 Today, real-time applications and endpoints have evolved such that 90 they are very often capable of transmitting at different bandwidth 91 rates. This is achieved by various techniques including the use of 92 layered coding (and transmission of only a subset of these layers) or 93 by reducing frame rates, resolution or quality at a given resolution. 94 Endpoints also often have the ability to adjust their transmission 95 rate dynamically mid-session with little or no artifact. 97 Typically, a higher bandwidth allows to achieve higher quality of 98 experience so that it is desirable to take advantage of higher 99 bandwidth when available. However, when only lower bandwidth is 100 available, it is desirable that the endpoints adjust their 101 transmission rate accordingly, to avoid generating excess traffic 102 that is likely to create congestion that will affect even the base 103 quality layer of that session as well as the quality of other 104 sessions sharing the same network resources. 106 When resource reservation is not supported by the network, endpoints 107 may be able to achieve such dynamic rate adjustment in a reactive 108 manner based on congestion detection. For example, 109 [I-D.ietf-avt-ecn-for-rtp] discusses how explicit congestion 110 notification (ECN) ([RFC3168]) can be used to that effect for RTP 111 ([RFC3550]) flows running over UDP/IP that use RTCP ([RFC3550]) as 112 feedback mechanism. 114 When resource reservation is supported by the network (e.g. Using 115 RSVP), endpoints can take advantage of it to achieve efficient 116 dynamic encoding/bandwidth adjustment. This can be seen as a pro- 117 active approach to dynamic rate adjustment because the network 118 facilitates continuous apportionment (and re-apportionment) of 119 resources across competing flows before any congestion occurs. 121 It is possible to use RSVP and Intserv in their present form to 122 achieve dynamic encoding/bandwidth adjustment through an iterative 123 trial-and-error approach: i.e. Attempt to reserve bandwidth for the 124 highest quality; if that fails, attempt to reserve bandwidth for the 125 next quality level down, and so on. However, with appropriate 126 extensions, RSVP/Intserv can support a more efficient approach that 127 allows determination and reservation, within a single signaling 128 round-trip, of the highest currently achievable quality level. 129 [I-D.polk-tsvwg-intserv-multiple-tspec] proposes a first set of 130 extensions to IntServ to that effect. To put it simply, these 131 extensions allow: 133 o a sender to signal the multiple "bandwidth" (or more precisely, 134 multiple sender traffic specifications) at which it can transmit 136 o a receiver to convey multiple "bandwidth" (or more precisely, 137 multiple flow specifications) in a preference order when making 138 the reservation request 140 o RSVP routers to collectively establish the reservation with the 141 highest currently achievable "bandwidth" among the ones signaled 142 by the receiver. 144 This document presents a complementary set of extensions, allowing 145 the dynamic bandwidth selection to reflect a different reservation 146 priority for each of the multiple "bandwidth" associated with a 147 reservation. 149 With these two complementary set of extensions, it is possible to 150 enforce sophisticated cross-session policies during dynamic 151 bandwidth/codec adjustment. For example, the network operator can 152 ensure that the "base" encoding layer of any session be given higher 153 priority than "enhancement layers" of any session. This may be 154 desirable if the policy is to maximize the number of sessions that 155 can be supported (with their minimum quality/resolution guaranteed). 156 As another example, the network operator can ensure that the "base 157 layer" and "mid layer" of a premium session are given high priority, 158 while base layer of normal sessions are given medium priority, while 159 every else is given low priority. This may be desirable if the 160 policy is to ensure that granting good resolution to premium sessions 161 is favored over accepting more regular sessions, but establishing 162 more regular sessions is favored over granting highest resolution to 163 premium sessions. 165 1.1. Conventions Used in This Document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 2. Overview of RSVP Extensions and Operations 173 [RFC2750] presents a set of extensions for supporting generic policy 174 based admission control in RSVP. These extensions include the 175 standard format of POLICY_DATA objects, and a description of RSVP's 176 handling of policy events. These extensions are consistent with the 177 framework for policy-based admission control presented in [RFC2753]. 178 POLICY_DATA objects are carried by RSVP messages and contain policy 179 information. The exchange of POLICY_DATA objects between policy- 180 capable nodes along the data path, supports the generation and 181 enforcement of consistent end-to-end admission control policies. 183 POLICY_DATA objects contain a list of Policy Elements that each 184 contain a single unit of information necessary for the evaluation of 185 policy rules. Multiple policy elements are already specified. For 186 example, [RFC2872] specifies the Application and Sub Application 187 Identity policy element for use with RSVP. 189 [RFC3181] specifies another policy element, the Preemption Priority 190 Policy Element, that can be signaled in RSVP so that network node may 191 take into account this policy element in order to preempt some 192 previously admitted low priority sessions in order to make room for a 193 newer, higher priority session. The Preemption Priority Policy 194 Element contains: 196 o one Preemption Priority specifying the priority of the new flow 197 compared with the defending priority of previously admitted flows. 199 o one Defending Priority that is used once this reservation is 200 established to compare with the preemption priority of new flows. 202 The present document specifies a new Policy Element called the 203 Multiple Preemption Priority Policy Element. The Multiple Preemption 204 Priority Policy Element complements (and does not replace) the 205 existing Preemption Priority Policy Element, so that a separate set 206 of preemption priority and defending priority can be associated to 207 each traffic specification or flow specification that may be signaled 208 as per [I-D.polk-tsvwg-intserv-multiple-tspec]. 210 For example, imagine that (using the extensions defined in 211 [I-D.polk-tsvwg-intserv-multiple-tspec]) a receiver R1 signals three 212 flow specifications (corresponding to the three encoding rates 213 supported by the corresponding sender). And let us refer to those as 214 Flowspec1 (say with rate r=12 Mb/s), Flowspec2 (say with r=4 Mb/s) 215 and Flowspec3 (say with r=1.5 Mb/s). In accordance with 216 [I-D.polk-tsvwg-intserv-multiple-tspec], FlowSpec1 will be carried in 217 the FLOWSPEC object, while Flowspec2 and FlowSpec3 will be carried in 218 the MULTI-FLOWSPEC object. 220 With the extensions defined in the present document, the receiver can 221 also: 223 o associate a pair of preemption priority and defending priority to 224 the first FlowSpec (Flowspec1) using the existing Preemption 225 Priority Policy Element (as per existing procedures) 227 o associate a different pair of preemption priority and defending 228 priority to any other FlowSpec (Flowspec2 and Flowspec3) using the 229 new Multiple Preemption Priority Policy Element (as per the new 230 procedures defined in the present document). 232 Then, whenever an RSVP router performs admission control, it can 233 enforce the preemption and defending priorities of each flow spec and 234 therefore enforce sophisticated policies for dynamic bandwidth 235 adjustment. Example of policies and how they can be achieved using 236 the present extensions are described in Section 2.1 and Section 2.2. 238 2.1. Policy Example 1 240 Assume an environment where all codecs support 3 levels of 241 resolution/quality: base, medium, enhanced. 243 Assume that the operator policy is characterized by the following 244 rules: 246 o all sessions are of equal importance 248 o a reservation for a base layer is allowed to preempt a reservation 249 for medium/enhanced layer if needed to be established 251 o a reservation for a medium layer is allowed to preempt a 252 reservation for enhanced layer if needed to be established. 254 Then the operator policy can be supported by signaling the following 255 preemption priorities: 257 +----------+ 258 | All | 259 | Sessions | 260 +---------+-----------+----------+ 261 | Quality | Flowspec | Prior(*) | 262 +---------+-----------+----------+ 263 +---------+-----------+----------+ 264 | Base | Flowspec1 | High | 265 +---------+----------+-----------+ 266 | Medium | Flowspec2 | Mid | 267 +---------+-----------+----------+ 268 | Enhanced| Flowspec3 | Low | 269 +---------+-----------+----------+ 271 (*) Preemption Priority = Defending Priority 273 Figure 1: Multiple Preemption Priority Values for Policy Example 1 275 2.2. Policy Example 2 277 Assume an environment where all codecs support 3 levels of 278 resolution/quality: base, medium, enhanced. 280 Assume that the operator policy is characterized by the following 281 rules: 283 o there are two levels of importance for sessions: Premium and 284 Normal 286 o a reservation for base/medium layer of Premium is allowed to 287 preempt a reservation for enhanced layer of Premium and for medium 288 and enhanced or Normal sessions, if needed to be established 290 o a reservation for a base layer of Normal is allowed to preempt a 291 reservation for medium and enhanced layer of Normal, if needed to 292 be established. 294 o a reservation for a medium layer of Normal is allowed to preempt a 295 reservation for enhanced layer of Normal, if needed to be 296 established. 298 Then the operator policy can be supported by signaling the following 299 preemption priorities: 301 +----------+----------+ 302 | Normal | Premium | 303 | Sessions | Sessions | 304 +---------+-----------+----------+----------+ 305 | Quality | Flowspec | Prior(*) | Prior(*) | 306 +---------+-----------+----------+----------+ 307 +---------+-----------+----------+----------+ 308 | Base | Flowspec1 | High | High | 309 +---------+----------+-----------+----------+ 310 | Medium | Flowspec2 | Mid | High | 311 +---------+-----------+----------+----------+ 312 | Enhanced| Flowspec3 | Low | Low | 313 +---------+-----------+----------+----------+ 315 (*) Preemption Priority = Defending Priority 317 Figure 2: Multiple Preemption Priority Values for Policy Example 2 319 3. Multiple Preemption Priority Policy Element Format 321 [RFC2750] defines extensions for supporting generic policy based 322 admission control in RSVP. These extensions include the standard 323 format of POLICY_DATA objects and a description of RSVP handling of 324 policy events. 326 The POLICY_DATA object contains one or more of Policy Elements, each 327 representing a different (and perhaps orthogonal) policy. As an 328 example, [RFC3181] specifies the Preemption Priority Policy Element. 329 This document defines one new Policy Elements called the Multiple 330 Preemption Priority Policy Element. The Multiple Preemption Priority 331 Policy Element contains a series of Priority Sub-Elements; each Sub- 332 Element contains a preemption priority and a defending priority. The 333 format of the Multiple Preemption Priority policy element is as shown 334 in Figure 3.The format of the Priority Sub-Element is as shown in 335 Figure 4. 337 0 1 2 3 338 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Length | P-Type = MULTI_PREEMPTION_PRI | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Priority Sub-Element 1 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 ... ... 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | Priority Sub-Element N | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 Figure 3: Multiple Preemption Priority Policy Element 351 o Length: 16 bits 353 * The overall length of the policy element, in bytes. 355 o P-Type: 16 bits 357 * MULTI_PREEMPTION_PRI = To be allocated by IANA (see "IANA 358 Considerations" section) 360 0 1 2 3 361 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Preemption Priority | Defending Priority | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 Figure 4: Priority Sub-Element 368 Preemption Priority N: 16 bits (unsigned) 370 o Preemption Priority of the Sub-Element. Encoding is same as 371 corresponding field in [RFC3181] Preemption Priority Policy 372 Element. 374 Defending Priority N: 16 bits (unsigned) 376 o Defending Priority of the Sub-Element. Encoding is same as 377 corresponding field in [RFC3181] Preemption Priority Policy 378 Element. 380 4. Processing Rules 382 4.1. Default Handling 384 As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes 385 (PINs) implement a default handling of POLICY_DATA objects ensuring 386 that those objects can traverse PIN nodes in transit from one PEP to 387 another. This applies to the situations where POLICY_DATA objects 388 contain the Multiple Preemption Priority Policy Element specified in 389 this document, so that those can traverse PIN nodes. 391 Section 4.2 of [RFC2750] also defines a similar default behavior for 392 policy-capable nodes that do not recognized a particular Policy 393 Element. This applies to the Multiple Preemption Priority Policy 394 Element specified in this document, so that those can traverse 395 policy-capable nodes that do not support the extensions defined in 396 the present document. 398 4.2. Associating Priorities With TSPECs and FLOWSPECs 400 This section defines how the multiple priority sub-elements conveyed 401 in the Preemption Priority Policy Element and the Multiple Preemption 402 Priority Policy Element are to be associated with the multiple 403 traffic specification (respectively flow specifications) of a Path 404 (respectively Resv) message. 406 Each POLICY object can contain at most a single Multiple Preemption 407 Priority Policy Element. If no Preemption Priority Policy Element is 408 present in the same POLICY_DATA object then the Multiple Preemption 409 Priority Policy Element MUST be ignored. 411 The preemption priority and defending priority of the Preemption 412 Priority Policy Element carried in a Resv message MUST be associated 413 with the flow specification carried in the FLOWSPEC object. The 414 preemption priority and defending priority in each sub-element of the 415 Multiple Preemption Priority Policy Element MUST be associated with 416 the flow specification carried in the corresponding position in the 417 MULTI_FLOWSPEC object. For example, the preemption priority and 418 defending priority of the first (respectively second) sub-element 419 (when present) of the Multiple Preemption Priority Policy Element is 420 to be associated with the first (respectively second) flow 421 specification (when present) in the MULTI_FLOWSPEC object. 423 If a Resv message contains no MULTI_FLOWSPEC object, but contains a 424 Multiple Preemption Priority Policy Element in the POLICY_DATA 425 object, then the Multiple Preemption Priority Policy Element MUST be 426 ignored. If there are more sub-elements in the Multiple Preemption 427 Priority Policy Element than there are flow specifications in the 428 MULTI_FLOWSPEC object, then the extra sub-elements MUST be ignored. 429 If there are fewer sub-elements in the Multiple Preemption Priority 430 Policy Element than there are flow specifications in the 431 MULTI_FLOWSPEC object, then the extra flow specifications SHOULD be 432 associated with preempt and defend priorities of 0 (the lowest 433 priorities). This MAY be overridden by local policy. This rule also 434 applies for a Resv message containing a MULTI_FLOWSPEC but no 435 Multiple Preemption Priority Policy Element; all the flow 436 specifications in the MULTI_FLOWSPEC SHOULD be associated with 437 default preempt and defend priorities of 0. 439 This document places no restriction on the relative priorities of 440 different flow specifications. Indeed, it is possible for smaller 441 flow specifications in a MULTI_FLOWSPEC to have a lower priority than 442 larger flow specifications. 444 For Multiple Preemption Priority Policy Elements carried in PATH 445 messages, the same rules apply relating to the MULTI_SENDER_TSPEC 446 object as they do to the MULTI_FLOWSPEC object described above. 448 With some reservation styles (e.g. Fixed Filter), the Resv message 449 may contain more than one flow descriptor (and therefore more than 450 one FLOWSPEC and MULTI_FLOWSPEC objects). As specified in section 451 3.2 of [RFC2750], the POLICY_DATA object can be associated with all 452 flows of the session or associated with an explicit set of senders 453 (e.g. By including a FILTER_SPEC object in the Options List 454 preceding the Policy Element List). This existing mechanisms are not 455 modified and may be used to explicitly associate a Multiple 456 Preemption Priority Policy Element with an explicit set of senders 457 (and in turn with the corresponding FLOWSPEC and MULTI_FLOWSPEC). 458 The Preemption Priority and Multiple Preemption Priority Policy 459 Elements contained in a POLICY_DATA object with no fields in the 460 Options list MUST apply to all senders and/or receivers in the 461 message, except for those which have been specifically overridden by 462 policy elements in additional POLICY_DATA objects with their 463 FILTER_SPEC in the Options list. 465 4.3. Merging Rules 467 [I-D.polk-tsvwg-intserv-multiple-tspec] specifies merging rules 468 across multiple reservations when the MULTI_FLOWSPEC object is used 469 to signal multiple flow specifications. It specifies the rules for 470 determining the set (and order) of flow specifications to be conveyed 471 in the resulting MULTI_FLOWSPEC. 473 Before the merging, each flow specification of the FLOWSPEC and 474 MULTI_FLOWSPEC of a given reservation is associated with a given 475 priority sub-element (from the Preemption Priority Policy Element or 476 the Multiple Preemption Priority Policy Element of that reservation) 477 in accordance with the rules specified in Section 4.2 of the present 478 document. 480 After merging, the Multiple Preemption Priority Policy Element MUST 481 contain the set of priority sub-elements that were associated (before 482 the merge) to each and every flow specification conveyed in the 483 merged MULTI_FLOWSPEC, encoded in the same order. If, before the 484 merge, a given flow specification was associated with priority sub- 485 elements containing different values for different reservations, the 486 merged sub-element MUST contain the highest preemption priority 487 across all the reservations and the highest defending priority across 488 all the reservations. 490 5. Security Considerations 492 As this document defines extensions to RSVP, the security 493 considerations of RSVP apply. 495 A subset of RSVP messages are signaled with the router alert option 496 (RAO) ([RFC2113],[RFC2711]). Based on the current security concerns 497 associated with the use of the IP router alert option, the 498 applicability of RSVP (and therefore of the RSVP extension discussed 499 in the present document) is limited to controlled environments (i.e. 500 Environments where the security risks associated with the use of the 501 router alert option are understood and protected against). The 502 security aspects and common practices around the use of the current 503 IP router alert option and consequences of using the IP router alert 504 option by applications such as RSVP are discussed in details in 505 [I-D.ietf-intarea-router-alert-considerations]. 507 The Multiple Preemption Priority Policy Element defined in this 508 document is signaled by RSVP through encapsulation in a Policy Data 509 object as defined in [RFC2750]. Therefore, like any other Policy 510 Elements, its integrity can be protected as discussed in section 6 of 511 [RFC2750] by two optional security mechanisms. The first mechanism 512 relies on RSVP Authentication as specified in [RFC2747] and [RFC3097] 513 to provide a chain of trust when all RSVP nodes are policy capable. 514 With this mechanism, the INTEGRITY object is carried inside RSVP 515 messages. This is further discussed in Section 5.1. The second 516 mechanism relies on the INTEGRITY object within the POLICY_DATA 517 object to guarantee integrity between RSVP Policy Enforcement Points 518 (PEPs) that are not RSVP neighbors. This is further discussed in 519 Section 5.2. Finally, IPsec mechanisms can be applied to the 520 protection of RSVP. This is further discussed in Section 5.3. 522 5.1. Use of RSVP Authentication between RSVP neighbors 524 RSVP authentication can be used between RSVP neighbors that are 525 policy capable. RSVP Authentication (defined in [RFC2747] and 526 [RFC3097]) SHOULD be supported by an implementation of the present 527 document. 529 With RSVP authentication, the RSVP neighbors use shared keys to 530 compute the cryptographic signature of the RSVP message. 531 [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key 532 provisioning methods as well as their respective applicability. 534 5.2. Use of INTEGRITY object within the POLICY_DATA object 536 The INTEGRITY object within the POLICY_DATA object can be used to 537 guarantee integrity between non-neighboring RSVP PEPs. This is 538 useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). 539 The INTEGRITY object within the POLICY_DATA object MAY be supported 540 by an implementation of the present document. 542 Details for computation of the content of the INTEGRITY object can be 543 found in Appendix B of [RFC2750]. This states that the Policy 544 Decision Point (PDP), at its discretion, and based on destination 545 PEP/PDP or other criteria, selects an Authentication Key and the hash 546 algorithm to be used. Keys to be used between PDPs can be 547 distributed manually or via standard key management protocol for 548 secure key distribution. 550 Note that where non-RSVP hops may exist in between RSVP hops, as well 551 as where RSVP capable Policy Ignorant Nodes (PINs) may exist in 552 between PEPs, it may be difficult for the PDP to determine what is 553 the destination PDP for a POLICY_DATA object contained in some RSVP 554 messages (such as a Path message). This is because in those cases 555 the next PEP is not known at the time of forwarding the message. In 556 this situation, key shared across multiple PDPs may be used. This is 557 conceptually similar to the use of key shared across multiple RSVP 558 neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. 559 We observe also that this issue may not exist in some deployment 560 scenarios where a single (or low number of) PDP is used to control 561 all the PEPs of a region (such as an administrative domain). In such 562 scenarios, it may be easy for a PDP to determine what is the next hop 563 PDP, even when the next hop PEP is not known, simply by determining 564 what is the next region that will be traversed (say based on the 565 destination address). 567 5.3. Use of IPsec for Security Protection of RSVP 569 [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses 570 applicability of IPsec mechanisms ([RFC4302], [RFC4303]) and 571 associated key provisioning methods for security protection of RSVP. 572 IPsec protection of RSVP MAY be supported by an implementation of the 573 present document. 575 6. IANA Considerations 577 As specified in [RFC2750], Standard RSVP Policy Elements (P-type 578 values) are to be assigned by IANA as per "IETF Consensus" policy 579 following the policies outlined in [RFC2434] (this policy is now 580 called "IETF Review" as per [RFC5226]) . 582 IANA needs to allocate one P-Type from the Standard RSVP Policy 583 Element range to the Multiple Preemption Priority Policy Element. 585 7. Acknowledgments 587 This document benefited from discussions with Subha Dhesikan and 588 James Polk. 590 8. References 592 8.1. Normative References 594 [I-D.polk-tsvwg-intserv-multiple-tspec] 595 Polk, J. and S. Dhesikan, "Integrated Services (IntServ) 596 Extension to Allow Signaling of Multiple Traffic 597 Specifications and Multiple Flow Specifications in 598 RSVPv1", draft-polk-tsvwg-intserv-multiple-tspec-03 (work 599 in progress), March 2010. 601 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 602 February 1997. 604 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 605 Requirement Levels", BCP 14, RFC 2119, March 1997. 607 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 608 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 609 Functional Specification", RFC 2205, September 1997. 611 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 612 Services", RFC 2210, September 1997. 614 [RFC2211] Wroclawski, J., "Specification of the Controlled-Load 615 Network Element Service", RFC 2211, September 1997. 617 [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification 618 of Guaranteed Quality of Service", RFC 2212, 619 September 1997. 621 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 622 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 623 October 1998. 625 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 626 RFC 2711, October 1999. 628 [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic 629 Authentication", RFC 2747, January 2000. 631 [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", 632 RFC 2750, January 2000. 634 [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic 635 Authentication -- Updated Message Type Value", RFC 3097, 636 April 2001. 638 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", 639 RFC 3181, October 2001. 641 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 642 December 2005. 644 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 645 RFC 4303, December 2005. 647 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 648 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 649 May 2008. 651 8.2. Informative References 653 [I-D.ietf-avt-ecn-for-rtp] 654 Westerlund, M., Johansson, I., Perkins, C., and K. 655 Carlberg, "Explicit Congestion Notification (ECN) for RTP 656 over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in 657 progress), March 2010. 659 [I-D.ietf-intarea-router-alert-considerations] 660 Faucheur, F., "IP Router Alert Considerations and Usage", 661 draft-ietf-intarea-router-alert-considerations-00 (work in 662 progress), March 2010. 664 [I-D.ietf-tsvwg-rsvp-security-groupkeying] 665 Behringer, M. and F. Faucheur, "Applicability of Keying 666 Methods for RSVP Security", 667 draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in 668 progress), June 2009. 670 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 671 for Policy-based Admission Control", RFC 2753, 672 January 2000. 674 [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub 675 Application Identity Policy Element for Use with RSVP", 676 RFC 2872, June 2000. 678 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 679 of Explicit Congestion Notification (ECN) to IP", 680 RFC 3168, September 2001. 682 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 683 Jacobson, "RTP: A Transport Protocol for Real-Time 684 Applications", STD 64, RFC 3550, July 2003. 686 Authors' Addresses 688 Francois Le Faucheur 689 Priority Cisco Systems 690 Greenside, 400 Avenue de Roumanille 691 Sophia Antipolis 06410 692 France 694 Phone: +33 4 97 23 26 19 695 Email: flefauch@cisco.com 697 Arun Kudur 698 Cisco Systems 699 SEZ Unit, Cessna Business Park, Kadubeesanahalli Village 700 Bangalore, Karnataka 560 103 701 India 703 Email: akudur@cisco.com 705 Ashok Narayanan 706 Cisco Systems 707 1414 Massachusetts Avenue 708 Boxborough 01719 709 USA 711 Email: ashokn@cisco.com