One document matched: draft-lefaucheur-tsvwg-rsvp-multiple-preemption-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 04:24:24 |