TSVWG F. Le Faucheur Internet-Draft A. Kudur Intended status: Standards Track A. Narayanan Expires: November 27, 2010 Cisco May 26, 2010 Multiple Preemption Priority Policy Element for RSVP draft-lefaucheur-tsvwg-rsvp-multiple-preemption-02.txt Abstract RSVP Extensions are being defined allowing an endpoint to signal alternate "bandwidths" of interest in case the preferred bandwidth is not available and allowing the RSVP routers to collectively establish the reservation with the highest currently achievable bandwidth among the signaled set. This can be used to achieve efficient dynamic endpoint codec adjustment. The present document presents a complementary set of extensions, allowing the dynamic bandwidth selection to reflect a different reservation priority for each of the multiple "bandwidth" associated with a reservation. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on November 27, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Le Faucheur, et al. Expires November 27, 2010 [Page 1] Internet-Draft RSVP Multiple Preemption Priorities May 2010 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 2. Overview of RSVP Extensions and Operations . . . . . . . . . . 5 2.1. Policy Example 1 . . . . . . . . . . . . . . . . . . . . . 6 2.2. Policy Example 2 . . . . . . . . . . . . . . . . . . . . . 7 3. Multiple Preemption Priority Policy Element Format . . . . . . 9 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Default Handling . . . . . . . . . . . . . . . . . . . . . 11 4.2. Associating Priorities With TSPECs and FLOWSPECs . . . . . 11 4.3. Merging Rules . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 14 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 14 5.3. Use of IPsec for Security Protection of RSVP . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Le Faucheur, et al. Expires November 27, 2010 [Page 2] Internet-Draft RSVP Multiple Preemption Priorities May 2010 1. Introduction Guaranteed QoS for some applications with tight QoS requirements may be achieved by reserving resources in each node on the end-to-end path. The Resource ReSerVation Protocol (RSVP) ([RFC2205]) is a protocol specified by the IETF supporting such on-path QoS signaling and resource reservation. In particular, RSVP can be used (as specified in [RFC2210]) to support the Control-Load ([RFC2211]) and Guaranteed ([RFC2212]) services of the integrated services (IntServ) framework. Today, real-time applications and endpoints have evolved such that they are very often capable of transmitting at different bandwidth rates. This is achieved by various techniques including the use of layered coding (and transmission of only a subset of these layers) or by reducing frame rates, resolution or quality at a given resolution. Endpoints also often have the ability to adjust their transmission rate dynamically mid-session with little or no artifact. Typically, a higher bandwidth allows to achieve higher quality of experience so that it is desirable to take advantage of higher bandwidth when available. However, when only lower bandwidth is available, it is desirable that the endpoints adjust their transmission rate accordingly, to avoid generating excess traffic that is likely to create congestion that will affect even the base quality layer of that session as well as the quality of other sessions sharing the same network resources. When resource reservation is not supported by the network, endpoints may be able to achieve such dynamic rate adjustment in a reactive manner based on congestion detection. For example, [I-D.ietf-avt-ecn-for-rtp] discusses how explicit congestion notification (ECN) ([RFC3168]) can be used to that effect for RTP ([RFC3550]) flows running over UDP/IP that use RTCP ([RFC3550]) as feedback mechanism. When resource reservation is supported by the network (e.g. Using RSVP), endpoints can take advantage of it to achieve efficient dynamic encoding/bandwidth adjustment. This can be seen as a pro- active approach to dynamic rate adjustment because the network facilitates continuous apportionment (and re-apportionment) of resources across competing flows before any congestion occurs. It is possible to use RSVP and Intserv in their present form to achieve dynamic encoding/bandwidth adjustment through an iterative trial-and-error approach: i.e. Attempt to reserve bandwidth for the highest quality; if that fails, attempt to reserve bandwidth for the next quality level down, and so on. However, with appropriate Le Faucheur, et al. Expires November 27, 2010 [Page 3] Internet-Draft RSVP Multiple Preemption Priorities May 2010 extensions, RSVP/Intserv can support a more efficient approach that allows determination and reservation, within a single signaling round-trip, of the highest currently achievable quality level. [I-D.polk-tsvwg-intserv-multiple-tspec] proposes a first set of extensions to IntServ to that effect. To put it simply, these extensions allow: o a sender to signal the multiple "bandwidth" (or more precisely, multiple sender traffic specifications) at which it can transmit o a receiver to convey multiple "bandwidth" (or more precisely, multiple flow specifications) in a preference order when making the reservation request o RSVP routers to collectively establish the reservation with the highest currently achievable "bandwidth" among the ones signaled by the receiver. This document presents a complementary set of extensions, allowing the dynamic bandwidth selection to reflect a different reservation priority for each of the multiple "bandwidth" associated with a reservation. With these two complementary set of extensions, it is possible to enforce sophisticated cross-session policies during dynamic bandwidth/codec adjustment. For example, the network operator can ensure that the "base" encoding layer of any session be given higher priority than "enhancement layers" of any session. This may be desirable if the policy is to maximize the number of sessions that can be supported (with their minimum quality/resolution guaranteed). As another example, the network operator can ensure that the "base layer" and "mid layer" of a premium session are given high priority, while base layer of normal sessions are given medium priority, while every else is given low priority. This may be desirable if the policy is to ensure that granting good resolution to premium sessions is favored over accepting more regular sessions, but establishing more regular sessions is favored over granting highest resolution to premium sessions. 1.1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Le Faucheur, et al. Expires November 27, 2010 [Page 4] Internet-Draft RSVP Multiple Preemption Priorities May 2010 2. Overview of RSVP Extensions and Operations [RFC2750] presents a set of extensions for supporting generic policy based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects, and a description of RSVP's handling of policy events. These extensions are consistent with the framework for policy-based admission control presented in [RFC2753]. POLICY_DATA objects are carried by RSVP messages and contain policy information. The exchange of POLICY_DATA objects between policy- capable nodes along the data path, supports the generation and enforcement of consistent end-to-end admission control policies. POLICY_DATA objects contain a list of Policy Elements that each contain a single unit of information necessary for the evaluation of policy rules. Multiple policy elements are already specified. For example, [RFC2872] specifies the Application and Sub Application Identity policy element for use with RSVP. [RFC3181] specifies another policy element, the Preemption Priority Policy Element, that can be signaled in RSVP so that network node may take into account this policy element in order to preempt some previously admitted low priority sessions in order to make room for a newer, higher priority session. The Preemption Priority Policy Element contains: o one Preemption Priority specifying the priority of the new flow compared with the defending priority of previously admitted flows. o one Defending Priority that is used once this reservation is established to compare with the preemption priority of new flows. The present document specifies a new Policy Element called the Multiple Preemption Priority Policy Element. The Multiple Preemption Priority Policy Element complements (and does not replace) the existing Preemption Priority Policy Element, so that a separate set of preemption priority and defending priority can be associated to each traffic specification or flow specification that may be signaled as per [I-D.polk-tsvwg-intserv-multiple-tspec]. For example, imagine that (using the extensions defined in [I-D.polk-tsvwg-intserv-multiple-tspec]) a receiver R1 signals three flow specifications (corresponding to the three encoding rates supported by the corresponding sender). And let us refer to those as Flowspec1 (say with rate r=12 Mb/s), Flowspec2 (say with r=4 Mb/s) and Flowspec3 (say with r=1.5 Mb/s). In accordance with [I-D.polk-tsvwg-intserv-multiple-tspec], FlowSpec1 will be carried in the FLOWSPEC object, while Flowspec2 and FlowSpec3 will be carried in the MULTI-FLOWSPEC object. Le Faucheur, et al. Expires November 27, 2010 [Page 5] Internet-Draft RSVP Multiple Preemption Priorities May 2010 With the extensions defined in the present document, the receiver can also: o associate a pair of preemption priority and defending priority to the first FlowSpec (Flowspec1) using the existing Preemption Priority Policy Element (as per existing procedures) o associate a different pair of preemption priority and defending priority to any other FlowSpec (Flowspec2 and Flowspec3) using the new Multiple Preemption Priority Policy Element (as per the new procedures defined in the present document). Then, whenever an RSVP router performs admission control, it can enforce the preemption and defending priorities of each flow spec and therefore enforce sophisticated policies for dynamic bandwidth adjustment. Example of policies and how they can be achieved using the present extensions are described in Section 2.1 and Section 2.2. 2.1. Policy Example 1 Assume an environment where all codecs support 3 levels of resolution/quality: base, medium, enhanced. Assume that the operator policy is characterized by the following rules: o all sessions are of equal importance o a reservation for a base layer is allowed to preempt a reservation for medium/enhanced layer if needed to be established o a reservation for a medium layer is allowed to preempt a reservation for enhanced layer if needed to be established. Then the operator policy can be supported by signaling the following preemption priorities: Le Faucheur, et al. Expires November 27, 2010 [Page 6] Internet-Draft RSVP Multiple Preemption Priorities May 2010 +----------+ | All | | Sessions | +---------+-----------+----------+ | Quality | Flowspec | Prior(*) | +---------+-----------+----------+ +---------+-----------+----------+ | Base | Flowspec1 | High | +---------+----------+-----------+ | Medium | Flowspec2 | Mid | +---------+-----------+----------+ | Enhanced| Flowspec3 | Low | +---------+-----------+----------+ (*) Preemption Priority = Defending Priority Figure 1: Multiple Preemption Priority Values for Policy Example 1 2.2. Policy Example 2 Assume an environment where all codecs support 3 levels of resolution/quality: base, medium, enhanced. Assume that the operator policy is characterized by the following rules: o there are two levels of importance for sessions: Premium and Normal o a reservation for base/medium layer of Premium is allowed to preempt a reservation for enhanced layer of Premium and for medium and enhanced or Normal sessions, if needed to be established o a reservation for a base layer of Normal is allowed to preempt a reservation for medium and enhanced layer of Normal, if needed to be established. o a reservation for a medium layer of Normal is allowed to preempt a reservation for enhanced layer of Normal, if needed to be established. Then the operator policy can be supported by signaling the following preemption priorities: Le Faucheur, et al. Expires November 27, 2010 [Page 7] Internet-Draft RSVP Multiple Preemption Priorities May 2010 +----------+----------+ | Normal | Premium | | Sessions | Sessions | +---------+-----------+----------+----------+ | Quality | Flowspec | Prior(*) | Prior(*) | +---------+-----------+----------+----------+ +---------+-----------+----------+----------+ | Base | Flowspec1 | High | High | +---------+----------+-----------+----------+ | Medium | Flowspec2 | Mid | High | +---------+-----------+----------+----------+ | Enhanced| Flowspec3 | Low | Low | +---------+-----------+----------+----------+ (*) Preemption Priority = Defending Priority Figure 2: Multiple Preemption Priority Values for Policy Example 2 Le Faucheur, et al. Expires November 27, 2010 [Page 8] Internet-Draft RSVP Multiple Preemption Priorities May 2010 3. Multiple Preemption Priority Policy Element Format [RFC2750] defines extensions for supporting generic policy based admission control in RSVP. These extensions include the standard format of POLICY_DATA objects and a description of RSVP handling of policy events. The POLICY_DATA object contains one or more of Policy Elements, each representing a different (and perhaps orthogonal) policy. As an example, [RFC3181] specifies the Preemption Priority Policy Element. This document defines one new Policy Elements called the Multiple Preemption Priority Policy Element. The Multiple Preemption Priority Policy Element contains a series of Priority Sub-Elements; each Sub- Element contains a preemption priority and a defending priority. The format of the Multiple Preemption Priority policy element is as shown in Figure 3.The format of the Priority Sub-Element is as shown in Figure 4. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | P-Type = MULTI_PREEMPTION_PRI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority Sub-Element 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority Sub-Element N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Multiple Preemption Priority Policy Element o Length: 16 bits * The overall length of the policy element, in bytes. o P-Type: 16 bits * MULTI_PREEMPTION_PRI = To be allocated by IANA (see "IANA Considerations" section) Le Faucheur, et al. Expires November 27, 2010 [Page 9] Internet-Draft RSVP Multiple Preemption Priorities May 2010 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Preemption Priority | Defending Priority | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Priority Sub-Element Preemption Priority N: 16 bits (unsigned) o Preemption Priority of the Sub-Element. Encoding is same as corresponding field in [RFC3181] Preemption Priority Policy Element. Defending Priority N: 16 bits (unsigned) o Defending Priority of the Sub-Element. Encoding is same as corresponding field in [RFC3181] Preemption Priority Policy Element. Le Faucheur, et al. Expires November 27, 2010 [Page 10] Internet-Draft RSVP Multiple Preemption Priorities May 2010 4. Processing Rules 4.1. Default Handling As specified in section 4.2 of [RFC2750], Policy Ignorant Nodes (PINs) implement a default handling of POLICY_DATA objects ensuring that those objects can traverse PIN nodes in transit from one PEP to another. This applies to the situations where POLICY_DATA objects contain the Multiple Preemption Priority Policy Element specified in this document, so that those can traverse PIN nodes. Section 4.2 of [RFC2750] also defines a similar default behavior for policy-capable nodes that do not recognized a particular Policy Element. This applies to the Multiple Preemption Priority Policy Element specified in this document, so that those can traverse policy-capable nodes that do not support the extensions defined in the present document. 4.2. Associating Priorities With TSPECs and FLOWSPECs This section defines how the multiple priority sub-elements conveyed in the Preemption Priority Policy Element and the Multiple Preemption Priority Policy Element are to be associated with the multiple traffic specification (respectively flow specifications) of a Path (respectively Resv) message. Each POLICY object can contain at most a single Multiple Preemption Priority Policy Element. If no Preemption Priority Policy Element is present in the same POLICY_DATA object then the Multiple Preemption Priority Policy Element MUST be ignored. The preemption priority and defending priority of the Preemption Priority Policy Element carried in a Resv message MUST be associated with the flow specification carried in the FLOWSPEC object. The preemption priority and defending priority in each sub-element of the Multiple Preemption Priority Policy Element MUST be associated with the flow specification carried in the corresponding position in the MULTI_FLOWSPEC object. For example, the preemption priority and defending priority of the first (respectively second) sub-element (when present) of the Multiple Preemption Priority Policy Element is to be associated with the first (respectively second) flow specification (when present) in the MULTI_FLOWSPEC object. If a Resv message contains no MULTI_FLOWSPEC object, but contains a Multiple Preemption Priority Policy Element in the POLICY_DATA object, then the Multiple Preemption Priority Policy Element MUST be ignored. If there are more sub-elements in the Multiple Preemption Priority Policy Element than there are flow specifications in the Le Faucheur, et al. Expires November 27, 2010 [Page 11] Internet-Draft RSVP Multiple Preemption Priorities May 2010 MULTI_FLOWSPEC object, then the extra sub-elements MUST be ignored. If there are fewer sub-elements in the Multiple Preemption Priority Policy Element than there are flow specifications in the MULTI_FLOWSPEC object, then the extra flow specifications SHOULD be associated with preempt and defend priorities of 0 (the lowest priorities). This MAY be overridden by local policy. This rule also applies for a Resv message containing a MULTI_FLOWSPEC but no Multiple Preemption Priority Policy Element; all the flow specifications in the MULTI_FLOWSPEC SHOULD be associated with default preempt and defend priorities of 0. This document places no restriction on the relative priorities of different flow specifications. Indeed, it is possible for smaller flow specifications in a MULTI_FLOWSPEC to have a lower priority than larger flow specifications. For Multiple Preemption Priority Policy Elements carried in PATH messages, the same rules apply relating to the MULTI_SENDER_TSPEC object as they do to the MULTI_FLOWSPEC object described above. With some reservation styles (e.g. Fixed Filter), the Resv message may contain more than one flow descriptor (and therefore more than one FLOWSPEC and MULTI_FLOWSPEC objects). As specified in section 3.2 of [RFC2750], the POLICY_DATA object can be associated with all flows of the session or associated with an explicit set of senders (e.g. By including a FILTER_SPEC object in the Options List preceding the Policy Element List). This existing mechanisms are not modified and may be used to explicitly associate a Multiple Preemption Priority Policy Element with an explicit set of senders (and in turn with the corresponding FLOWSPEC and MULTI_FLOWSPEC). The Preemption Priority and Multiple Preemption Priority Policy Elements contained in a POLICY_DATA object with no fields in the Options list MUST apply to all senders and/or receivers in the message, except for those which have been specifically overridden by policy elements in additional POLICY_DATA objects with their FILTER_SPEC in the Options list. 4.3. Merging Rules [I-D.polk-tsvwg-intserv-multiple-tspec] specifies merging rules across multiple reservations when the MULTI_FLOWSPEC object is used to signal multiple flow specifications. It specifies the rules for determining the set (and order) of flow specifications to be conveyed in the resulting MULTI_FLOWSPEC. Before the merging, each flow specification of the FLOWSPEC and MULTI_FLOWSPEC of a given reservation is associated with a given priority sub-element (from the Preemption Priority Policy Element or Le Faucheur, et al. Expires November 27, 2010 [Page 12] Internet-Draft RSVP Multiple Preemption Priorities May 2010 the Multiple Preemption Priority Policy Element of that reservation) in accordance with the rules specified in Section 4.2 of the present document. After merging, the Multiple Preemption Priority Policy Element MUST contain the set of priority sub-elements that were associated (before the merge) to each and every flow specification conveyed in the merged MULTI_FLOWSPEC, encoded in the same order. If, before the merge, a given flow specification was associated with priority sub- elements containing different values for different reservations, the merged sub-element MUST contain the highest preemption priority across all the reservations and the highest defending priority across all the reservations. Le Faucheur, et al. Expires November 27, 2010 [Page 13] Internet-Draft RSVP Multiple Preemption Priorities May 2010 5. Security Considerations As this document defines extensions to RSVP, the security considerations of RSVP apply. A subset of RSVP messages are signaled with the router alert option (RAO) ([RFC2113],[RFC2711]). Based on the current security concerns associated with the use of the IP router alert option, the applicability of RSVP (and therefore of the RSVP extension discussed in the present document) is limited to controlled environments (i.e. Environments where the security risks associated with the use of the router alert option are understood and protected against). The security aspects and common practices around the use of the current IP router alert option and consequences of using the IP router alert option by applications such as RSVP are discussed in details in [I-D.ietf-intarea-router-alert-considerations]. The Multiple Preemption Priority Policy Element defined in this document is signaled by RSVP through encapsulation in a Policy Data object as defined in [RFC2750]. Therefore, like any other Policy Elements, its integrity can be protected as discussed in section 6 of [RFC2750] by two optional security mechanisms. The first mechanism relies on RSVP Authentication as specified in [RFC2747] and [RFC3097] to provide a chain of trust when all RSVP nodes are policy capable. With this mechanism, the INTEGRITY object is carried inside RSVP messages. This is further discussed in Section 5.1. The second mechanism relies on the INTEGRITY object within the POLICY_DATA object to guarantee integrity between RSVP Policy Enforcement Points (PEPs) that are not RSVP neighbors. This is further discussed in Section 5.2. Finally, IPsec mechanisms can be applied to the protection of RSVP. This is further discussed in Section 5.3. 5.1. Use of RSVP Authentication between RSVP neighbors RSVP authentication can be used between RSVP neighbors that are policy capable. RSVP Authentication (defined in [RFC2747] and [RFC3097]) SHOULD be supported by an implementation of the present document. With RSVP authentication, the RSVP neighbors use shared keys to compute the cryptographic signature of the RSVP message. [I-D.ietf-tsvwg-rsvp-security-groupkeying] discusses key types, key provisioning methods as well as their respective applicability. 5.2. Use of INTEGRITY object within the POLICY_DATA object The INTEGRITY object within the POLICY_DATA object can be used to guarantee integrity between non-neighboring RSVP PEPs. This is Le Faucheur, et al. Expires November 27, 2010 [Page 14] Internet-Draft RSVP Multiple Preemption Priorities May 2010 useful only when some RSVP nodes are Policy Ignorant Nodes (PINs). The INTEGRITY object within the POLICY_DATA object MAY be supported by an implementation of the present document. Details for computation of the content of the INTEGRITY object can be found in Appendix B of [RFC2750]. This states that the Policy Decision Point (PDP), at its discretion, and based on destination PEP/PDP or other criteria, selects an Authentication Key and the hash algorithm to be used. Keys to be used between PDPs can be distributed manually or via standard key management protocol for secure key distribution. Note that where non-RSVP hops may exist in between RSVP hops, as well as where RSVP capable Policy Ignorant Nodes (PINs) may exist in between PEPs, it may be difficult for the PDP to determine what is the destination PDP for a POLICY_DATA object contained in some RSVP messages (such as a Path message). This is because in those cases the next PEP is not known at the time of forwarding the message. In this situation, key shared across multiple PDPs may be used. This is conceptually similar to the use of key shared across multiple RSVP neighbors discussed in [I-D.ietf-tsvwg-rsvp-security-groupkeying]. We observe also that this issue may not exist in some deployment scenarios where a single (or low number of) PDP is used to control all the PEPs of a region (such as an administrative domain). In such scenarios, it may be easy for a PDP to determine what is the next hop PDP, even when the next hop PEP is not known, simply by determining what is the next region that will be traversed (say based on the destination address). 5.3. Use of IPsec for Security Protection of RSVP [I-D.ietf-tsvwg-rsvp-security-groupkeying] also discusses applicability of IPsec mechanisms ([RFC4302], [RFC4303]) and associated key provisioning methods for security protection of RSVP. IPsec protection of RSVP MAY be supported by an implementation of the present document. Le Faucheur, et al. Expires November 27, 2010 [Page 15] Internet-Draft RSVP Multiple Preemption Priorities May 2010 6. IANA Considerations As specified in [RFC2750], Standard RSVP Policy Elements (P-type values) are to be assigned by IANA as per "IETF Consensus" policy following the policies outlined in [RFC2434] (this policy is now called "IETF Review" as per [RFC5226]) . IANA needs to allocate one P-Type from the Standard RSVP Policy Element range to the Multiple Preemption Priority Policy Element. Le Faucheur, et al. Expires November 27, 2010 [Page 16] Internet-Draft RSVP Multiple Preemption Priorities May 2010 7. Acknowledgments This document benefited from discussions with Subha Dhesikan and James Polk. Le Faucheur, et al. Expires November 27, 2010 [Page 17] Internet-Draft RSVP Multiple Preemption Priorities May 2010 8. References 8.1. Normative References [I-D.polk-tsvwg-intserv-multiple-tspec] Polk, J. and S. Dhesikan, "Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1", draft-polk-tsvwg-intserv-multiple-tspec-03 (work in progress), March 2010. [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999. [RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic Authentication", RFC 2747, January 2000. [RFC2750] Herzog, S., "RSVP Extensions for Policy Control", RFC 2750, January 2000. [RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic Authentication -- Updated Message Type Value", RFC 3097, April 2001. Le Faucheur, et al. Expires November 27, 2010 [Page 18] Internet-Draft RSVP Multiple Preemption Priorities May 2010 [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 8.2. Informative References [I-D.ietf-avt-ecn-for-rtp] Westerlund, M., Johansson, I., Perkins, C., and K. Carlberg, "Explicit Congestion Notification (ECN) for RTP over UDP", draft-ietf-avt-ecn-for-rtp-01 (work in progress), March 2010. [I-D.ietf-intarea-router-alert-considerations] Faucheur, F., "IP Router Alert Considerations and Usage", draft-ietf-intarea-router-alert-considerations-00 (work in progress), March 2010. [I-D.ietf-tsvwg-rsvp-security-groupkeying] Behringer, M. and F. Faucheur, "Applicability of Keying Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in progress), June 2009. [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework for Policy-based Admission Control", RFC 2753, January 2000. [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. Le Faucheur, et al. Expires November 27, 2010 [Page 19] Internet-Draft RSVP Multiple Preemption Priorities May 2010 Authors' Addresses Francois Le Faucheur Priority Cisco Systems Greenside, 400 Avenue de Roumanille Sophia Antipolis 06410 France Phone: +33 4 97 23 26 19 Email: flefauch@cisco.com Arun Kudur Cisco Systems SEZ Unit, Cessna Business Park, Kadubeesanahalli Village Bangalore, Karnataka 560 103 India Email: akudur@cisco.com Ashok Narayanan Cisco Systems 1414 Massachusetts Avenue Boxborough 01719 USA Email: ashokn@cisco.com Le Faucheur, et al. Expires November 27, 2010 [Page 20]