TSVWG F. Le Faucheur Internet-Draft A. Kudur Intended status: Standards Track A. Narayanan Expires: January 4, 2010 Cisco July 3, 2009 Multiple Preemption Priority Policy Element for RSVP draft-lefaucheur-tsvwg-rsvp-multiple-preemption-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 4, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Le Faucheur, et al. Expires January 4, 2010 [Page 1] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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. 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 . . . . . . . . . . . . . . . . . . . 13 5.1. Use of RSVP Authentication between RSVP neighbors . . . . 13 5.2. Use of INTEGRITY object within the POLICY_DATA object . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Le Faucheur, et al. Expires January 4, 2010 [Page 2] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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. 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. Thus, network resource reservation mechanisms such as RSVP ( [RFC2205]) can provide a lot of value to real time applications by facilitating dynamic encoding/ bandwidth adjustment. 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, extensions to RSVP/ Intserv are required to 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 Le Faucheur, et al. Expires January 4, 2010 [Page 3] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 January 4, 2010 [Page 4] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 January 4, 2010 [Page 5] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 teh 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 January 4, 2010 [Page 6] Internet-Draft RSVP Multiple Preemption Priorities July 2009 +----------+ | 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 January 4, 2010 [Page 7] Internet-Draft RSVP Multiple Preemption Priorities July 2009 +----------+----------+ | 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 January 4, 2010 [Page 8] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 January 4, 2010 [Page 9] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 January 4, 2010 [Page 10] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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. 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 MULTI_FLOWSPEC object, then the extra sub- elements MUST be ignored. If there are fewer priorities 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 Le Faucheur, et al. Expires January 4, 2010 [Page 11] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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. It is important to note that 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 As mentioned above, each element of a MULTI_FLOWSPEC is associated with a single preempt and defend priority element from a Multiple Preemption Priority Policy Element. When merging multiple reservations, the two component FLOWSPECs are merged into a single FLOWSPEC, and the two component MULTI_FLOWSPECs are merged into a single MULTI_FLOWSPEC.The merged FLOWSPEC object is composed as per [RFC2205], by computing the envelope of all flow specification components. The merged MULTI_FLOWSPEC is composed by taking all the flow specification components from the individual MULTI_FLOWSPEC objects, in descending order of bandwidth. If the component Resv messages contain POLICY_DATA objects with Multiple Preemption Priority policy elements, the merged reservation MUST contain a Multiple Preemption Priority policy element. This element is composed by combining each of the individual preempt and defend priority sub-elements associated with each of the flow specification components in the merged MULTI_FLOWSPEC, in the same order. Le Faucheur, et al. Expires January 4, 2010 [Page 12] Internet-Draft RSVP Multiple Preemption Priorities July 2009 5. Security Considerations As this document defines extensions to RSVP, the security considerations of RSVP apply. Those are discussed in [RFC2205], [RFC4230] and [I-D.ietf-tsvwg-rsvp-security-groupkeying]. Approaches for addressing those concerns are discussed further below. A subset of RSVP messages are signaled with the Router Alert Option (RAO)([RFC2113],[RFC2711]). The security aspects and common practices around the use of the current IP Router Alert option and consequences on the use of IP Router Alert by applications such as RSVP are discussed in [I-D.rahman-rtg-router-alert-considerations]. The Multiple Preemption Priority Policy Element defined in this document are 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. 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. 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 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 Le Faucheur, et al. Expires January 4, 2010 [Page 13] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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). Le Faucheur, et al. Expires January 4, 2010 [Page 14] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 January 4, 2010 [Page 15] Internet-Draft RSVP Multiple Preemption Priorities July 2009 7. Acknowledgments This document benefited from discussions with Subha Dhesikan and James Polk. Le Faucheur, et al. Expires January 4, 2010 [Page 16] Internet-Draft RSVP Multiple Preemption Priorities July 2009 8. References 8.1. Normative References [I-D.polk-tsvwg-intserv-multiple-tspec] Polk, J. and S. Dhesikan, "Integrated Services (IntServ) Extension to Allow Multiple TSPECs", draft-polk-tsvwg-intserv-multiple-tspec-00 (work in progress), March 2009. [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. [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. [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. [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-tsvwg-rsvp-security-groupkeying] Behringer, M. and F. Faucheur, "Applicability of Keying Le Faucheur, et al. Expires January 4, 2010 [Page 17] Internet-Draft RSVP Multiple Preemption Priorities July 2009 Methods for RSVP Security", draft-ietf-tsvwg-rsvp-security-groupkeying-05 (work in progress), June 2009. [I-D.rahman-rtg-router-alert-considerations] Faucheur, F., "IP Router Alert Considerations and Usage", draft-rahman-rtg-router-alert-considerations-01 (work in progress), March 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. [RFC4230] Tschofenig, H. and R. Graveman, "RSVP Security Properties", RFC 4230, December 2005. Le Faucheur, et al. Expires January 4, 2010 [Page 18] Internet-Draft RSVP Multiple Preemption Priorities July 2009 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 January 4, 2010 [Page 19]