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 8, 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.

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
    1.1.  Conventions Used in This Document
2.  Terminology
3.  RSVP Extensions for Flexible Resource Sharing
    3.1.  RSVP Object Definitions
4.  Security Considerations
5.  IANA Considerations
6.  Acknowledgments
7.  References
    7.1.  Normative References
    7.2.  Informative References
§  Authors' Addresses

1.  Introduction

The RSVP Resource Reservation Protocol [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) 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.

• 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.
• 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.
• 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] (Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, “STUN - Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” March 2003.), 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 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] (Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, “RSVP-TE: Extensions to RSVP for LSP Tunnels,” December 2001.), 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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

2.  Terminology

The following terminology i

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> ]

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] (Faucheur, F., Manner, J., Wing, D., and L. Faucheur, “RSVP Proxy Approaches,” March 2010.), 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] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.) 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] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.).

The style of a reservation, as denoted by the STYLE object, continues to function as per [RFC2205] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.), 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 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] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.):

• If the new incoming reservation caused any component of the merged FLOWSPEC to change, the new merged reservation MUST be readmitted immediately.
• If readmission succeeds, the reservations are forwarded upstream.
• 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.

• 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.
• 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 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:

• 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.
• By using a UUID allocation mechanism (such as is specified in [RFC4122] (Leach, P., Mealling, M., and R. Salz, “A Universally Unique IDentifier (UUID) URN Namespace,” July 2005.))
• 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 :

• they have the same object length specified in the RSVP object header, AND
• a bytewise comparison of both RSIDs, up to the object length specified in the RSVP object header, yields an equal result.

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:

• 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.
• 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] (Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, “Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification,” September 1997.). The same solutions described therein apply to flows which are merged with RSID.

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 (RSVP Extensions for Flexible Resource Sharing)) to assign a new Error Subcode under the Admission Control Failure code (1) for "RSID Mismatch". Also, a new Error Code :

• "RSID Mismatch"
• "Style Incompatible With RSID Object".

6.  Acknowledgments

This document benefited from

7.  References

7.1. Normative References

7.2. Informative References

Authors' Addresses