TSVWG A. Narayanan Internet-Draft F. Le Faucheur Intended status: Standards Track S. Dhesikan Expires: April 28, 2010 Cisco October 25, 2009 RSVP Extensions for Flexible Resource Sharing draft-narayanan-tsvwg-rsvp-resource-sharing-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 28, 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 April 28, 2010 [Page 1] Internet-Draft RSVP Resource Sharing Extensions October 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 1.2. Changes since the previous version . . . . . . . . . . . . 4 2. RSVP Extensions for Flexible Resource Sharing . . . . . . . . 5 2.1. RSVP Object Definitions . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 6.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Narayanan, et al. Expires April 28, 2010 [Page 2] Internet-Draft RSVP Resource Sharing Extensions October 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 April 28, 2010 [Page 3] Internet-Draft RSVP Resource Sharing Extensions October 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]. 1.2. Changes since the previous version o Further definition of format of Resource Sharing ID object. o Editorial cleanups Narayanan, et al. Expires April 28, 2010 [Page 4] Internet-Draft RSVP Resource Sharing Extensions October 2009 2. 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. The proposed RBNF [RFC5511] for the Path and Resv messages with the new RSID is given below: Narayanan, et al. Expires April 28, 2010 [Page 5] Internet-Draft RSVP Resource Sharing Extensions October 2009 ::= [ ] [ ] [ ] [ ... ]