TSVWG A. Narayanan
Internet-Draft F. Le Faucheur
Intended status: Standards Track S. Dhesikan
Expires: January 6, 2010 Cisco
July 05, 2009
RSVP Extensions for Flexible Resource Sharing
draft-narayanan-tsvwg-rsvp-resource-sharing-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 6, 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.
Narayanan, et al. Expires January 6, 2010 [Page 1]
Internet-Draft RSVP Resource Sharing Extensions July 2009
Abstract
RSVP signaling can be used to make end-to-end resource reservations
in an IP network in order to guarantee the QoS required by certain
flows. ...
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. RSVP Extensions for Flexible Resource Sharing . . . . . . . . 6
3.1. RSVP Object Definitions . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Narayanan, et al. Expires January 6, 2010 [Page 2]
Internet-Draft RSVP Resource Sharing Extensions July 2009
1. Introduction
The RSVP Resource Reservation Protocol [RFC2205] specifies a
mechanism to reserve resources for signalled flows that require QoS
from the network. One of the features of RSVP is the ability to
share resources between separate flows. The scope of flows between
which resources can be shared is currently defined by the SESSION
object. This object contains the destination L3+L4 transport address
of the data flow. This means that RSVP currently allows sharing of
resources between flows with different source transport address but
sharing the same destination transport. This is useful for multicast
scenarios, for example when multiple sources can transmit for the
same multicast application but only one source ever transmit at a
given time: it is then desirable to share the resource across flows
from teh multiple senders on all common links. However, RSVP cannot
today share resources between flows with different destination L3+L4
transport addresses. There are certain cases where it is desirable
to share resources between two flows with different destination L3+L4
transport addresses. Two examples are given below.
o Voice Call-Waiting: A bidirectional voice call between two
endpoints A and B is signalled using two separate unidirectional
RSVP reservations for the flows A->B and B->A. If endpoint A
wishes to put the A-B call on hold and join a separate A-C call,
it is desirable that network resources on common links be shared
between the A-B and A-C calls. The B->A and C->A subflows of the
call can share resources using existing RSVP sharing mechanisms,
but only if they use the same destination L3+L4 addressing.
However, there is no way in RSVP today to share the resources
between the A->B and A->C subflows of the call since by definition
the RSVP reservations for these subflows must have different L3
addresses in the SESSION objects.
o Voice Shared Line: A single number that rings multiple endpoints
(which may be geographically diverse), such as phone lines on a
manager's desk and their assistant. A VoIP system that models
these calls as multiple P2P unicast pre-ring reservations would
result in significantly overcounting bandwidth on shared links,
since today unicast reservations to different endpoints cannot
share bandwidth.
o Symmetric NAT: RSVP permits sharing of resources between multiple
flows addressed to the same destination D, even from different
senders S1 and S2. However, if D is behind a NAT operating in
symmetric mode[RFC3489], it is possible that the destination L4
transport addresses of the flows S1->D and S2->D may be different
outside the NAT. In this case, these flows cannot share resources
using RSVP today, since the SESSION objects for these two flows
Narayanan, et al. Expires January 6, 2010 [Page 3]
Internet-Draft RSVP Resource Sharing Extensions July 2009
outside the NAT would have different L4 transport addresses.
The fundamental problem seen here is due to overloading of the
semantics of the SESSION object. Specifically, the SESSION object as
defined in RFC2205 has three separate functions:
1. To function as a unique key
2. To specify the destination L3+L4 address of the stream
3. To define the set of flows that may share resources
As specified today, the SESSION object must provide all of these
functions. As RSVP is extended to support additional functionality,
this combination of functionality imposes undesirable constraints.
This has already been seen during the development of MPLS/TE
[RFC3209], where the SESSION object only specifies the destination L3
address of the flow, plus a sender-selected Tunnel ID. Since this is
insufficient to guarantee key uniqueness, a further Extended Tunnel
ID was added. As described in the examples above, requiring flows
that share resources to also share their destination L3+L4 address is
also imposing undesirable constraints.
This document describes a mechanism to separate the definition of
flows that can share resources, from flows that share a destination
L3+L4 address. A new Resource Sharing ID object is defined which
specifies the scope of resource sharing, independent of the contents
of the SESSION object. By separating the scope definition of
resource sharing from the SESSION object, the constraints described
above are removed and teh sharing scenarios of interest can be
supported.
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].
Narayanan, et al. Expires January 6, 2010 [Page 4]
Internet-Draft RSVP Resource Sharing Extensions July 2009
2. Terminology
The following terminology i
Narayanan, et al. Expires January 6, 2010 [Page 5]
Internet-Draft RSVP Resource Sharing Extensions July 2009
3. RSVP Extensions for Flexible Resource Sharing
This section describes extensions to existing RSVP procedures to
support flexible resource sharing between reservations. All these
rules apply to routers that support the resource sharing extensions
described here.
We define a new optional Resource Sharing ID (RSID) object to be
carried in RSVP signaling messages. In summary, different signaled
RSVP flows that carry the same RSID object will share resources,
regardless of the contents of their SESSION objects. The RSID is
carried in the flow-descriptor section of the Resv message. The
RSID, if present, is associated with the preceding FILTER_SPEC. No
more than one RSID may follow each FILTER_SPEC. The flow descriptor
may include other per-filter objects (like RECORD_ROUTE);
implementations MUST accept the RSID in any order relative to these
objects, as long as they are associated with the same FILTER_SPEC.
The RSID MAY be inserted by the RSVP endpoint generating the message,
and all RSVP routers MUST forward it unmodified with the associated
FILTER_SPEC.
<Resv Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <RESV_CONFIRM> ] [ <SCOPE> ]
[ <POLICY_DATA> ... ]
<STYLE> <flow descriptor list>
<flow descriptor list> ::= empty
| <FF flow descriptor list>
| <SE flow descriptor>
| <WF flow descriptor>
<FF flow descriptor list> ::= <FLOWSPEC> <FILTER_SPEC>
| <FF flow descriptor list>
<FF flow descriptor>
<FF flow descriptor> ::= [ <FLOWSPEC> ] <FILTER_SPEC>
<SE flow descriptor> ::= <FLOWSPEC> <SE filter spec list>
<SE filter spec list> ::= <SE filter spec>
| <SE filter spec list> <SE filter spec>
<SE filter spec> ::= <FILTER_SPEC> [ <RSID> ]
<WF flow descriptor> ::= <FLOWSPEC> [ <RSID> ]
Narayanan, et al. Expires January 6, 2010 [Page 6]
Internet-Draft RSVP Resource Sharing Extensions July 2009
The RSID MAY also be included in a Path message, as part of the
sender descriptor. However, any RSID in a Path message is purely
advisory to the receiver and SHOULD be ignored by all RSVP routers.
A receiver proxy as defined in
[I-D.ietf-tsvwg-rsvp-proxy-approaches], SHOULD reflect any RSID
received in a Path, in the Resv generated in response to that Path.
This MAY be overridden by local policy on the receiver proxy.
<Path Message> ::= <Common Header> [ <INTEGRITY> ]
<SESSION> <RSVP_HOP>
<TIME_VALUES>
[ <EXPLICIT_ROUTE> ]
<LABEL_REQUEST>
[ <SESSION_ATTRIBUTE> ]
[ <POLICY_DATA> ... ]
<sender descriptor>
<sender descriptor> ::= <SENDER_TEMPLATE> <SENDER_TSPEC>
[ <ADSPEC> ] [ <RSID> ]
RSVP routers MUST share resources across flows (defined by <SESSION,
FILTER_SPEC> pairs) that are signalled with the same RSID in the Resv
message. Two different RSVP reservations with different SESSION
objects may contain the same RSID in their flow descriptors; when
admitting the second reservation, the RSVP router MUST recognize that
the RSID is the same as an existing reservation, and MUST share
resources across these two reservations when admitting the second
one. RSVP routers MUST NOT share resources between a flow signaled
with an RSID an a flow signaled without an RSID. With this
exception, the existing reservation sharing rules described in
[RFC2205] continue to apply for all flows signaled without RSID
objects. Therefore, flows signaled without RSID objects will share
bandwidth as per the rules of [RFC2205].
The style of a reservation, as denoted by the STYLE object, continues
to function as per [RFC2205], as an indicator of reservation sharing.
Specifically, reservations signaled using a Distinct style (Fixed-
Filter) MUST NOT share resources. Therefore, the RSID MUST NOT be
included in any Resv message which contains a STYLE object of Fixed-
Filter. If a RSVP router receives a Resv with a STYLE object
indicating Fixed-Filter as well as a flow descriptor containing a
RSID, the RSVP router MUST reject this message and generate a
ResvError with error code {Resource Sharing Error, Style Incompatible
With RSID Object}. For reservations signaled using one of the Shared
styles, the RSID may be used to join together reservations that would
Narayanan, et al. Expires January 6, 2010 [Page 7]
Internet-Draft RSVP Resource Sharing Extensions July 2009
ordinarily not have shared resources (e.g. SE or WF-style
reservations with different SESSION objects but same RSID), or split
apart reservations that would otherwise have shared resources (e.g.
SE-style reservations with the same SESSION, but different
FILTER_SPEC and RSID objects).
When processing a Resv received with a RSID, a router looks for other
installed reservations with the same RSID, irrespective of SESSION
object. If such reservations are found, the new reservation is
merged with those existing installed reservations, using the
reservation merging techniques already described in [RFC2205]:
o If the new incoming reservation caused any component of the merged
FLOWSPEC to change, the new merged reservation MUST be readmitted
immediately.
o If readmission succeeds, the reservations are forwarded upstream.
o If readmission fails, the router MUST reject the incoming Resv and
generate a ResvError of the same type as it would ordinarily
generate if readmission was triggered in a different way (e.g.
signaled bandwidth change). A failed readmission attempt MUST NOT
remove existing resources allocated to existing reservations
For SE-style reservations, RSVP state pertaining to a single flow (as
defined by a <SESSION, FILTER_SPEC> pair) MUST NOT have two
conflicting RSID objects. If a RSVP router receives a Resv message
pertaining to a <SESSION, FILTER_SPEC> which corresponds to
previously installed state, the router MUST compare the NHOP of this
message to the NHOP of the previously installed reservation state.
o If these NHOPs are different, the router MUST reject the new Resv
and generate a ResvError of the form {Admission Control Failure,
RSID Mismatch}, defined below. The existing reservation MUST be
left in place.
o If the NHOPs are the same, the reservation MUST be readmitted
immediately with the new RSID.
Note that the presence of the RSID only controls which reservations
may share resources, not _how_ these resources are shared. The
method of computing the size and parameters of a pool of shared
reservations remains unchanged (e.g. for IntServ-style FLOWSPECs, the
merged FLOWSPEC is computed by taking the envelope of each term of
the individual FLOWSPECs). RSVP routers continue to support their
current mechanisms for actually sharing resources, such as a shared
packet queue; the presence of the RSID only alters the set of
reservations that use the shared queue. If an implementation is
Narayanan, et al. Expires January 6, 2010 [Page 8]
Internet-Draft RSVP Resource Sharing Extensions July 2009
unable to program its traffic control subsystem to share resources
between a set of reservations with the same RSID (for example, a
classifier which cannot direct flows with different destination IP
addresses into the same queue), the implementation MUST reject the
reservation and issue a ResvError with error code {Traffic Control
Error, Service conflict}.
The use of RSID is supported for WF style reservations. The rules
described above apply, with the flow being defined only by the
<SESSION> object. Therefore, RSID can only be used to share
resources between reservations with different SESSION objects. Also,
the rule preventing conflicting RSID objects now applies for RSVP
state with the same SESSION only.
The use of RSID is fully supported for multicast reservations.
3.1. RSVP Object Definitions
We specify a new Resource Sharing ID object as described above. The
class number of this object will be of the form 11bbbbbb, so RSVP
implementations that do not support the extensions defined in the
present document will ignore and forward this object unmodified.
o RESOURCE SHARING ID: Class = TBA, C-Type = 1
+-------------+-------------+-------------+-------------+
| |
. .
. Resource Sharing ID (variable length) .
. .
| |
+-------------+-------------+-------------+-------------+
The RSID object contains a Resource Sharing ID conditioning sharing
of resources as specified above. Its length is variable, and is
conveyed to the RSVP implementation receiving the RSID object inside
the corresponding RSVP object header.
It is the responsibility of the entity(ies) that allocate(s) the
Resource Sharing IDs to ensure that those will result in the desired
resource sharing across all flows. When there are multiple entities
allocating Resource Sharing IDs, then it is the responsibility of
each allocating entitity to ensure its allocated RSIDs will not
unintentionally collide with RSIDs allocated by other entities for
other flows. Some examples of how implementations can avoid RSID
collision and achieve proper RSID allocation are:
Narayanan, et al. Expires January 6, 2010 [Page 9]
Internet-Draft RSVP Resource Sharing Extensions July 2009
o By composing the RSID out of a context selector (such as the
globally unique IP address of the allocating node), combined with
a locally allocated ID.
o By using a UUID allocation mechanism (such as is specified in
[RFC4122])
o By using internal application level allocation or signaling
mechanisms
RSVP midpoints MUST treat the contents of the RSID object as opaque.
The only operation that RSVP midpoints perform on the RSID is an
equality test with other RSIDs. Two RSIDs are equal if and only if :
o they have the same object length specified in the RSVP object
header, AND
o a bytewise comparison of both RSIDs, up to the object length
specified in the RSVP object header, yields an equal result.
Narayanan, et al. Expires January 6, 2010 [Page 10]
Internet-Draft RSVP Resource Sharing Extensions July 2009
4. Security Considerations
Existing RSVP security concerns and mechanisms apply here. In
particular, the RSID imposes no new security considerations from the
perspective of trusted/untrusted RSVP neighbors, since it does not
alter message processing rules. Neighbor authentication and message
integrity rules remain unchanged and MUST NOT be affected by the
presence of RSID objects in messages.
One possible additional concern with the RSID is the ability for one
endpoint to share bandwidth with a different reservation. Two
potential issues with this are:
o A flow could piggyback on a different reservation and therefore
get service that is available to the other flow but should not be
available to this one. It should be noted that determining
allowable services offered to a reservation request is done by
examining other parts of the signaled message, such as policy
objects, credentials, and application ID (). RSVP implementations
MUST continue to implement their current policy enforcement rules
for messages that contain RSID objects.
o A flow could merge with another flow and attempt to deny it
service by requesting an unreasonably large amount of bandwidth.
This is similar to the "Killer Reservation" problems outlined in
[RFC2205]. The same solutions described therein apply to flows
which are merged with RSID.
Narayanan, et al. Expires January 6, 2010 [Page 11]
Internet-Draft RSVP Resource Sharing Extensions July 2009
5. IANA Considerations
IANA is requested to assign a new class number of the form 11bbbbbb
for the RESOURCE SHARING ID object.
IANA is also requested (see Section 3) to assign a new Error Subcode
under the Admission Control Failure code (1) for "RSID Mismatch".
Also, a new Error Code :
o "RSID Mismatch"
o "Style Incompatible With RSID Object".
Narayanan, et al. Expires January 6, 2010 [Page 12]
Internet-Draft RSVP Resource Sharing Extensions July 2009
6. Acknowledgments
This document benefited from
Narayanan, et al. Expires January 6, 2010 [Page 13]
Internet-Draft RSVP Resource Sharing Extensions July 2009
7. References
7.1. Normative References
[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.
[RFC2747] Baker, F., Lindell, B., and M. Talwar, "RSVP Cryptographic
Authentication", RFC 2747, January 2000.
[RFC3097] Braden, R. and L. Zhang, "RSVP Cryptographic
Authentication -- Updated Message Type Value", RFC 3097,
April 2001.
[RFC3182] Yadav, S., Yavatkar, R., Pabbati, R., Ford, P., Moore, T.,
Herzog, S., and R. Hess, "Identity Representation for
RSVP", RFC 3182, October 2001.
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489,
March 2003.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005.
7.2. Informative References
[I-D.ietf-tsvwg-rsvp-proxy-approaches]
Faucheur, F., Manner, J., Wing, D., and L. Faucheur, "RSVP
Proxy Approaches",
draft-ietf-tsvwg-rsvp-proxy-approaches-07 (work in
progress), May 2009.
[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.
Narayanan, et al. Expires January 6, 2010 [Page 14]
Internet-Draft RSVP Resource Sharing Extensions July 2009
Authors' Addresses
Ashok Narayanan
Cisco Systems
300 Beaver Brook Road
Boxborough, MAS 01719
United States
Email: ashokn@cisco.com
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
Subha Dhesikan
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134
United States
Email: sdhesika@cisco.com
Narayanan, et al. Expires January 6, 2010 [Page 15]