TSVWG A. Guillou Internet-Draft SFR Intended status: Informational March 23, 2010 Expires: September 23, 2010 RSVP for Triple-Play Video on Demand draft-guillou-tsvwg-rsvp-vod-00.txt Abstract This document summarizes SFR resource control requirements associated with the delivery of Triple Play Video on Demand services to broadband residential users. It also describes the approach based on RSVP for addressing those requirements. Finally, this document recommends that the IETF continues maintenance and extension of RSVP so that the industry can continue benefiting from quality interoperable resource control solutions based on RSVP. 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. Guillou Expires September 23, 2010 [Page 1] Internet-Draft RSVP for VoD 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. Guillou Expires September 23, 2010 [Page 2] Internet-Draft RSVP for VoD March 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Resource Control Requirements For A Triple Play Video On Demand Service . . . . . . . . . . . . . . . . . . . . . . . . 5 3. RSVP Deployment Approach for VoD Admission Control . . . . . . 6 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 Guillou Expires September 23, 2010 [Page 3] Internet-Draft RSVP for VoD March 2010 1. Introduction SFR is the second largest telecommunications operator in France, operating both a mobile and a wireline network. In particular, 4 millions homes are attached to the broadband residential service. The broadband service portfolio includes a triple play service (Internet, Video/TV, telephony) with free and paying Video on Demand (VoD) services. Section 2 summarizes SFR resource control requirements associated with the delivery of these VoD services. Section 3 describes the approach based on RSVP for addressing those requirements. Finally, Section 4 recommends that the IETF continues maintenance and extension of RSVP so that the industry can continue benefiting from quality interoperable resource control solutions based on RSVP. This document is provided as an input to the IETF 77 RSVP-mini-BOF and more generally to the IETF decision process regarding RSVP standardisation. Guillou Expires September 23, 2010 [Page 4] Internet-Draft RSVP for VoD March 2010 2. Resource Control Requirements For A Triple Play Video On Demand Service Video and streaming traffic is growing continuously in a service provider network. The corresponding bandwidth needed in the network will increase more and more because of two different factors: o The number of subscribers will increase because of the free Video on Demand (VoD) and the broader offering in terms of paying VoD o The bandwidth of the individual streams will increase because of High Definition (HD) and maybe the 3D in the future. We can divide the network in three parts: the backbone, the aggregation ring and the access (DSLAM for example). To control the maximum video load on the backbone, the best way is to open more VoD POPs to be able to stream the flow closer to the customer. On the aggregation ring, to support network outage, we will make some over-provisioning on most of the access, but it will not be possible everywhere. In some cases, the cost of this over-provisioning will be too expensive. Also, on the aggregation equipment, it will not always be possible to increase the bandwidth at will because of the equipment limitation. With the diffserv model, we have two problems. If we put very high priority for the VoD traffic, in case of saturation of a link (network outage, video surge due to a big event) the VoD traffic could hog most, or all, of the bandwidth and make the internet access totally unusable. On the other hand, if we put less priority for the VoD stream, in the same situation, VoD quality will not be enough for our customers and Internet access will still be unusable. We do have an interest for RSVP on the aggregation ring and on the IP edge to solve this problem. We will use RSVP to put a limitation on the number of simultaneous VoD streams to always have good quality and still keep an acceptable internet access. RSVP will protect the quality of established VoD sessions and of the less prioritised traffic by rejecting the additional excessive video session attempts during unpredictable peaks, during link or node failures, or combination of those factors. Another point of interest in RSVP is to be able to use the Application ID to put different limitation on different kind of streams. With this functionality, we could be able to put a higher limitation on free VoD to save bandwidth for paid VoD and, in some cases, pre-empt free VoD. Guillou Expires September 23, 2010 [Page 5] Internet-Draft RSVP for VoD March 2010 3. RSVP Deployment Approach for VoD Admission Control As we describe in the previous section, we do not have to implement RSVP on all the nodes. With the distribution of VoD POP they should not be so many VoD streams going thru the backbone links so the over- provisioning of the backbone will be enough to support peaks and network outage. All that we want the backbones router to do is to let the RSVP messages going thru transparently with no processing (other than regular IP-based forwarding). On the aggregation nodes, RSVP will be processed and reservations should be done as described in[RFC2205]. RSVP is normally an end to end reservation protocol, but allowing RSVP message to/from the end- user raises some security problems. An effective way to protect the network from an RSVP attack is to deny every RSVP messages from the outside of the network. The RSVP receiver proxy functionality ([I-D.ietf-tsvwg-rsvp-proxy-approaches], [I-D.ietf-tsvwg-rsvp-proxy-proto]) is in this case the best way to use RSVP without allow our customers to be part of the RSVP cloud. In this model, we need to couple the RSVP reservation and the corresponding RTSP stream. The best equipment to do so is the VoD Pump. Guillou Expires September 23, 2010 [Page 6] Internet-Draft RSVP for VoD March 2010 |-------------| | VoD SRM | | | //////////| |\\\\\\\\\\\\\\\\ / |-------------| \ / / \ / / \ / / \ ****** ****** \ * VoD* * VoD* \ *Pump* *Pump* \ ****** ****** \ | | \ *** |-| |-| *** *** ********** |-----| |---| *r*-----|r|-----|r|----*r*--*r*--*RSVP *--|DSLAM|~~~~|STB|--TV *** |-| |-| *** *** *Receiver* |-----| |---| *Proxy * ********** <-Backbone--> (non-RSVP) <---Aggregation------> (RSVP) (1) **********************************> ==========RSVP=======> (2) *********************************************************> =======................===========RSVP======> SRM Session Resource Manager *** |---| *r* regular RSVP |STB| Set Top Box *** router |---| ****** * VoD* RSVP capable VoD Pump *Pump* ****** ***> VoD media flow ==> segment of flow path protected by RSVP reservation /\ VoD Application level signaling (e.g. RTSP) Figure 1: RSVP Deployment for VoD Guillou Expires September 23, 2010 [Page 7] Internet-Draft RSVP for VoD March 2010 VoD service is operational in SFR (without RSVP) since 2007. The RSVP solution is being validated and deployment strategies are being defined. While part of the aggregation nodes are capable of supporting RSVP and RSVP Receiver Proxy, some nodes are not. This forces us to consider the network in two different part: o the RSVP-capable aggregation network: It will have a RSVP proxy and then will be protected by RSVP admission control. o The non-RSVP-capable aggregation network. It will not have RSVP proxy and will not be protected by admission control The implementation of the coupling between RSVP and RTSP on the VoD streamer has to take care of this two topologies: we have to allow the streamer to send his RTSP flow even if RSVP reservation is not fully reserved on the path. Here is how VoD streamers will made the link between RSVP and RTSP : o When the streamer receive an RTSP SETUP, it will start the RTSP streaming and send his RSVP PATH message o If the streamer receives an RSVP RESV message, it means that the path is protect by RSVP and the streamer keep its RTSP stream and its RSVP context o If the RSVP timer expired, it means that the path is not is protected by RSVP so the streamer tear down its RSVP context but keep its RTSP session o If the streamer receives an RSVP ERROR message, it means that path is protected by RSVP but there is not enough bandwidth so the streamer tears down its RSVP session and its RTSP session. This kind of behavior of the RSVP streamer also allows us to deploy RSVP on the network step by step with no impact on the customer quality. Guillou Expires September 23, 2010 [Page 8] Internet-Draft RSVP for VoD March 2010 4. Recommendation SFR will deploy the RSVP admission control to protect the VoD streams of its residential broadband customers. Therefore, it will be beneficial to SFR if the IETF keeps working on open RSVP-based solutions benefiting from different industry experts to unsure good interoperability between different vendors. Guillou Expires September 23, 2010 [Page 9] Internet-Draft RSVP for VoD March 2010 5. Security Considerations As explained in Section 3, opening our control plane to an on-path admission control protocol raises some security concerns. Without proper security measures, we can not control that a reservation is really made for a VoD flow, and we expose ourselves to an attack on our control plane. To solve this problem, we will filter all RSVP messages from untrusted network (peering, transit, customer) and rely on RSVP receiver proxy on the interface facing the DSLAM and the customers that need RSVP protected VoD flows. On each router where RSVP is enabled, we will also activate pacing and rate limiting of RSVP messages to protect the CPU of the node. Guillou Expires September 23, 2010 [Page 10] Internet-Draft RSVP for VoD March 2010 6. IANA Considerations Not applicable Guillou Expires September 23, 2010 [Page 11] Internet-Draft RSVP for VoD March 2010 7. Normative References [I-D.ietf-tsvwg-rsvp-proxy-approaches] Faucheur, F., Guillou, A., Manner, J., and D. Wing, "RSVP Proxy Approaches", draft-ietf-tsvwg-rsvp-proxy-approaches-08 (work in progress), October 2009. [I-D.ietf-tsvwg-rsvp-proxy-proto] Faucheur, F., Guillou, A., Manner, J., Malik, H., and A. Narayanan, "RSVP Extensions for Path-Triggered RSVP Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-10 (work in progress), October 2009. [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. Guillou Expires September 23, 2010 [Page 12] Internet-Draft RSVP for VoD March 2010 Author's Address Allan Guillou 40-42 Quai du Point du Jour Boulogne-Billancourt, 92659 France Email: allan.guillou@neufcegetel.fr Guillou Expires September 23, 2010 [Page 13]