One document matched: draft-lefaucheur-tsvwg-rsvp-multiple-preemption-01.txt
Differences from draft-lefaucheur-tsvwg-rsvp-multiple-preemption-00.txt
TSVWG F. Le Faucheur
Internet-Draft A. Kudur
Intended status: Standards Track A. Narayanan
Expires: April 29, 2010 Cisco
October 26, 2009
Multiple Preemption Priority Policy Element for RSVP
draft-lefaucheur-tsvwg-rsvp-multiple-preemption-01.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 April 29, 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 April 29, 2010 [Page 1]
Internet-Draft RSVP Multiple Preemption Priorities October 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 . . . . . . . . . . . . . . . . . . . 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 April 29, 2010 [Page 2]
Internet-Draft RSVP Multiple Preemption Priorities October 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. 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.westerlund-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 April 29, 2010 [Page 3]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
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 April 29, 2010 [Page 4]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 5]
Internet-Draft RSVP Multiple Preemption Priorities October 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 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 April 29, 2010 [Page 6]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 7]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 8]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 9]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 10]
Internet-Draft RSVP Multiple Preemption Priorities October 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. 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 April 29, 2010 [Page 11]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
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 April 29, 2010 [Page 12]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
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 April 29, 2010 [Page 13]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
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.rahman-rtg-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 April 29, 2010 [Page 14]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
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 April 29, 2010 [Page 15]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 16]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
7. Acknowledgments
This document benefited from discussions with Subha Dhesikan and
James Polk.
Le Faucheur, et al. Expires April 29, 2010 [Page 17]
Internet-Draft RSVP Multiple Preemption Priorities October 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-01 (work in
progress), July 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.
[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.
[RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element",
Le Faucheur, et al. Expires April 29, 2010 [Page 18]
Internet-Draft RSVP Multiple Preemption Priorities October 2009
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-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.
[I-D.rahman-rtg-router-alert-considerations]
Faucheur, F., "IP Router Alert Considerations and Usage",
draft-rahman-rtg-router-alert-considerations-02 (work in
progress), July 2009.
[I-D.westerlund-avt-ecn-for-rtp]
Westerlund, M., Johansson, I., Perkins, C., and K.
Carlberg, "Explicit Congestion Notification (ECN) for RTP
over UDP", draft-westerlund-avt-ecn-for-rtp-01 (work in
progress), October 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 April 29, 2010 [Page 19]
Internet-Draft RSVP Multiple Preemption Priorities October 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 April 29, 2010 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 04:22:12 |