TSVWG G. Lavers Internet-Draft Cisco Intended status: Informational K. Webb Bailey Expires: September 23, 2010 Wells Fargo March 22, 2010 RSVP Usage in Enterprise Networks draft-lavers-rsvp-usage-00.txt Abstract This document presents a number of resource control requirements that enterprise network administrators face. It also discusses how RSVP is being used, or considered, in order to address these requirements. This document is offered as input to the IETF 77 RSVP mini-BOF. The authors recommend that the IETF continues supporting RSVP as a Standards Track protocol and continue facilitating development of necessary RSVP extensions in the Standards Track. 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 September 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Lavers & Webb Bailey Expires September 23, 2010 [Page 1] Internet-Draft RSVP Enterprise Usage March 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Lavers & Webb Bailey Expires September 23, 2010 [Page 2] Internet-Draft RSVP Enterprise Usage March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Resource Control Requirements and RSVP Usage . . . . . . . . . 5 2.1. Growth in Rich Media Applications . . . . . . . . . . . . 5 2.2. Over-Provisioning not always possible . . . . . . . . . . 5 2.3. Complex WAN/MAN topology . . . . . . . . . . . . . . . . . 6 2.4. Policy-based Resource Allocation . . . . . . . . . . . . . 6 2.5. Dynamic Rate Adjustment of Real-Time applications . . . . 7 3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Lavers & Webb Bailey Expires September 23, 2010 [Page 3] Internet-Draft RSVP Enterprise Usage March 2010 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 main IETF protocol for these resource reservations is RSVP, specified in [RFC2205]. The authors of the present document recommend that the IETF continues supporting RSVP as a Standards Track protocol and continue facilitating development of the necessary RSVP extensions in the Standards Track. Lavers & Webb Bailey Expires September 23, 2010 [Page 4] Internet-Draft RSVP Enterprise Usage March 2010 2. Resource Control Requirements and RSVP Usage The growth of rich media applications and the evolution of the enterprise networks have placed challenging demands in the area of resource control. These challenges and the rationale of why RSVP serves these scenarios well are explained in this section. 2.1. Growth in Rich Media Applications There is an increasing use of mixed multi-media (voice, video, and data) applications and systems being deployed within the Enterprise. In addition, high quality video conferencing is becoming more prevalent in todayis enterprises. While it is clear that the current use of DiffServ based QoS is necessary, it is not sufficient in addressing the full support of this demands of todayis multi-media traffic. In particular, the voice and video traffic is generally provisioned in priority or other fixed-bandwidth queues. These queues require an admission control mechanism without which any oversubscription would result in packets being randomly dropped from any of the sessions/streams traversing the DiffServ queues. This would lower the quality of the very traffic that we were trying to protect and impact user experience. RSVP, as defined in [RFC2205], is an on-path explicit signaling resource reservation mechanism. This mechanism not only allows admission control based on bandwidth to occur in each of the RSVP- enabled hops along the path but it also supports application or user based admission control. This is described in [RFC2208]. RSVP in an IntServ architecture also ensures that Resource Reservation mechanism is in sync with the QoS applied along the same hop. Thus it addresses the need for the growing rich media application in the enterprise. 2.2. Over-Provisioning not always possible While Over-Provisioning may sound theoretically possible, in practice it is very difficult to rely on over-provisioning everywhere in the network 100% of the time (i.e. during all possible failure scenarios) for the following reasons: o It is also not possible to over-provision the Enterprise WAN network to match the peak voice and video requirement as the usage of rich media applications is not only growing in almost all enterprises but is doing so in an unpredictable manner. Hence, a constant adjustment in the network to overprovision is necessary but impractical to do so. Lavers & Webb Bailey Expires September 23, 2010 [Page 5] Internet-Draft RSVP Enterprise Usage March 2010 o The cost of over provisioning some links (eg transcontinental) is prohibitively high and preclude sheer over provisioning. o There is economical pressure to do right-provisioning and not over-provisioning. o The Enterprise WAN network core connectivity is built with arbitrary meshing and where the corresponding Diffserv classes cannot simply be assumed to be always over-provisioned compared to the peak load of voice and video. If an enterprise cannot rely on the provisioned capacity to meet all their needs then there is a need for an admission control system such that the enterprises can handle the over-subscription in a non- arbitrary and a proactive manner. When sufficient capacity is not available, RSVP explicitly notifies the application and this allows the application to handle the reservation failure in many ways including re-routing the traffic through other means, prioritizing some traffic over others and issuing a busy tone. 2.3. Complex WAN/MAN topology Due to the complex WAN/MAN topology and the fact that there may be Multiple call/session management systems in use, it is difficult to depend on a static or off-path bandwidth-counting QoS mechanism. These mechanisms do not respond well to real-time network events and do not always maintain an accurate representation of the multimedia traffic flows originating from multiple systems. Enterprise branches sometimes have dual WAN uplinks and where the secondary link cannot be over-provisioned. This scenario is challenging to a static or an off-path QoS solution. RSVP serves well in this scenario as each of the links can be RSVP enabled and the admission control will take into account the capacity of the link and the current traffic demands prior to guaranteeing the bandwidth for any request. Thus, complex WAN/MAN topology and/or multiple call systems can be deployed in any enterprise without the above mentioned concerns. 2.4. Policy-based Resource Allocation Enterprise resources cannot always be over-provisioned to satisfy unbounded demand and so resources need to proportioned in accordance to business need. For example, allocate fractions of the link in terms of bandwidth to be used by specific applications, application- types or user-classes. This gives rise to a requirement that the resource control system should be able to match resources to business Lavers & Webb Bailey Expires September 23, 2010 [Page 6] Internet-Draft RSVP Enterprise Usage March 2010 need in a dynamic and a scalable fashion. [RFC2872] and [RFC3181] allow policy elements to accompany reservation requests to enable the reservation process to take into account business need. Priority can be attached to reservations based on user, user groups, role or other attributes. This allows Enterprises to handle unbounded demand nicely. 2.5. Dynamic Rate Adjustment of Real-Time applications As discussed in [I-D.lefaucheur-tsvwg-rsvp-multiple-preemption] and [I-D.polk-tsvwg-intserv-multiple-tspec]: "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 () 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." Extensions such as proposed in [I-D.lefaucheur-tsvwg-rsvp-multiple-preemption] and Lavers & Webb Bailey Expires September 23, 2010 [Page 7] Internet-Draft RSVP Enterprise Usage March 2010 [I-D.polk-tsvwg-intserv-multiple-tspec] are necessary to support the evolution of applications. RSVP is based on explicit on-path signaling and therefore it allows upstream systems and applications to take corrective action, such as routing the session/stream across a different transport, reducing the bandwidth requirement of the session, or allowing the session to traverse the transport as Best-Effort traffic. Lavers & Webb Bailey Expires September 23, 2010 [Page 8] Internet-Draft RSVP Enterprise Usage March 2010 3. Recommendation Today's enterprises have to address some of the above scenarios and because RSVP is well poised to address the same as the main IETF protocol for on-path resource reservation, the authors of the present document recommend that the IETF continues supporting RSVP as a Standards Track protocol and continue facilitating development of the necessary RSVP extensions in the Standards Track. This will ensure that on-path resource control solutions can be specified and deployed in enterprise networks with the benefits of the full IETF technical expertise and with the benefits of multi- vendor interoperability. Lavers & Webb Bailey Expires September 23, 2010 [Page 9] Internet-Draft RSVP Enterprise Usage March 2010 4. Security Considerations Not discussed in this version of teh document. Lavers & Webb Bailey Expires September 23, 2010 [Page 10] Internet-Draft RSVP Enterprise Usage March 2010 5. IANA Considerations None. Lavers & Webb Bailey Expires September 23, 2010 [Page 11] Internet-Draft RSVP Enterprise Usage March 2010 6. References 6.1. Normative References [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2208] Mankin, A., Baker, F., Braden, B., Bradner, S., O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, "Resource ReSerVation Protocol (RSVP) Version 1 Applicability Statement Some Guidelines on Deployment", RFC 2208, September 1997. [RFC2872] Bernet, Y. and R. Pabbati, "Application and Sub Application Identity Policy Element for Use with RSVP", RFC 2872, June 2000. [RFC3181] Herzog, S., "Signaled Preemption Priority Policy Element", RFC 3181, October 2001. 6.2. Informative References [I-D.lefaucheur-tsvwg-rsvp-multiple-preemption] Faucheur, F., Kudur, A., and A. Narayanan, "Multiple Preemption Priority Policy Element for RSVP", draft-lefaucheur-tsvwg-rsvp-multiple-preemption-01 (work in progress), October 2009. [I-D.polk-tsvwg-intserv-multiple-tspec] Polk, J. and S. Dhesikan, "Integrated Services (IntServ) Extension to Allow Signaling of Multiple Traffic Specifications and Multiple Flow Specifications in RSVPv1", draft-polk-tsvwg-intserv-multiple-tspec-03 (work in progress), March 2010. [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-02 (work in progress), October 2009. [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 Lavers & Webb Bailey Expires September 23, 2010 [Page 12] Internet-Draft RSVP Enterprise Usage March 2010 Applications", STD 64, RFC 3550, July 2003. Lavers & Webb Bailey Expires September 23, 2010 [Page 13] Internet-Draft RSVP Enterprise Usage March 2010 Authors' Addresses Glen Lavers Cisco Systems 5400 Meadows Road LAKE OSWEGO OREGON 97035 USA Phone: Email: glavers@cisco.com Karen Webb Bailey Wells Fargo 1525 W WT Harris Charlotte NC 28262 USA Phone: Email: karen.bailey3@wellsfargo.com Lavers & Webb Bailey Expires September 23, 2010 [Page 14]