idnits 2.17.1 draft-guillou-tsvwg-rsvp-vod-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 23, 2010) is 5147 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 299, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-tsvwg-rsvp-proxy-approaches-08 == Outdated reference: A later version (-11) exists of draft-ietf-tsvwg-rsvp-proxy-proto-10 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG A. Guillou 3 Internet-Draft SFR 4 Intended status: Informational March 23, 2010 5 Expires: September 23, 2010 7 RSVP for Triple-Play Video on Demand 8 draft-guillou-tsvwg-rsvp-vod-00.txt 10 Abstract 12 This document summarizes SFR resource control requirements associated 13 with the delivery of Triple Play Video on Demand services to 14 broadband residential users. It also describes the approach based on 15 RSVP for addressing those requirements. 17 Finally, this document recommends that the IETF continues maintenance 18 and extension of RSVP so that the industry can continue benefiting 19 from quality interoperable resource control solutions based on RSVP. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 23, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Resource Control Requirements For A Triple Play Video On 75 Demand Service . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. RSVP Deployment Approach for VoD Admission Control . . . . . . 6 77 4. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 9 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 80 7. Normative References . . . . . . . . . . . . . . . . . . . . . 12 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 1. Introduction 85 SFR is the second largest telecommunications operator in France, 86 operating both a mobile and a wireline network. In particular, 4 87 millions homes are attached to the broadband residential service. 88 The broadband service portfolio includes a triple play service 89 (Internet, Video/TV, telephony) with free and paying Video on Demand 90 (VoD) services. 92 Section 2 summarizes SFR resource control requirements associated 93 with the delivery of these VoD services. Section 3 describes the 94 approach based on RSVP for addressing those requirements. 96 Finally, Section 4 recommends that the IETF continues maintenance and 97 extension of RSVP so that the industry can continue benefiting from 98 quality interoperable resource control solutions based on RSVP. 100 This document is provided as an input to the IETF 77 RSVP-mini-BOF 101 and more generally to the IETF decision process regarding RSVP 102 standardisation. 104 2. Resource Control Requirements For A Triple Play Video On Demand 105 Service 107 Video and streaming traffic is growing continuously in a service 108 provider network. The corresponding bandwidth needed in the network 109 will increase more and more because of two different factors: 111 o The number of subscribers will increase because of the free Video 112 on Demand (VoD) and the broader offering in terms of paying VoD 114 o The bandwidth of the individual streams will increase because of 115 High Definition (HD) and maybe the 3D in the future. 117 We can divide the network in three parts: the backbone, the 118 aggregation ring and the access (DSLAM for example). 120 To control the maximum video load on the backbone, the best way is to 121 open more VoD POPs to be able to stream the flow closer to the 122 customer. 124 On the aggregation ring, to support network outage, we will make some 125 over-provisioning on most of the access, but it will not be possible 126 everywhere. In some cases, the cost of this over-provisioning will 127 be too expensive. Also, on the aggregation equipment, it will not 128 always be possible to increase the bandwidth at will because of the 129 equipment limitation. With the diffserv model, we have two problems. 130 If we put very high priority for the VoD traffic, in case of 131 saturation of a link (network outage, video surge due to a big event) 132 the VoD traffic could hog most, or all, of the bandwidth and make the 133 internet access totally unusable. On the other hand, if we put less 134 priority for the VoD stream, in the same situation, VoD quality will 135 not be enough for our customers and Internet access will still be 136 unusable. We do have an interest for RSVP on the aggregation ring 137 and on the IP edge to solve this problem. We will use RSVP to put a 138 limitation on the number of simultaneous VoD streams to always have 139 good quality and still keep an acceptable internet access. RSVP will 140 protect the quality of established VoD sessions and of the less 141 prioritised traffic by rejecting the additional excessive video 142 session attempts during unpredictable peaks, during link or node 143 failures, or combination of those factors. Another point of interest 144 in RSVP is to be able to use the Application ID to put different 145 limitation on different kind of streams. With this functionality, we 146 could be able to put a higher limitation on free VoD to save 147 bandwidth for paid VoD and, in some cases, pre-empt free VoD. 149 3. RSVP Deployment Approach for VoD Admission Control 151 As we describe in the previous section, we do not have to implement 152 RSVP on all the nodes. With the distribution of VoD POP they should 153 not be so many VoD streams going thru the backbone links so the over- 154 provisioning of the backbone will be enough to support peaks and 155 network outage. All that we want the backbones router to do is to 156 let the RSVP messages going thru transparently with no processing 157 (other than regular IP-based forwarding). 159 On the aggregation nodes, RSVP will be processed and reservations 160 should be done as described in[RFC2205]. RSVP is normally an end to 161 end reservation protocol, but allowing RSVP message to/from the end- 162 user raises some security problems. An effective way to protect the 163 network from an RSVP attack is to deny every RSVP messages from the 164 outside of the network. The RSVP receiver proxy functionality 165 ([I-D.ietf-tsvwg-rsvp-proxy-approaches], 166 [I-D.ietf-tsvwg-rsvp-proxy-proto]) is in this case the best way to 167 use RSVP without allow our customers to be part of the RSVP cloud. 169 In this model, we need to couple the RSVP reservation and the 170 corresponding RTSP stream. The best equipment to do so is the VoD 171 Pump. 173 |-------------| 174 | VoD SRM | 175 | | 176 //////////| |\\\\\\\\\\\\\\\\ 177 / |-------------| \ 178 / / \ 179 / / \ 180 / / \ 181 ****** ****** \ 182 * VoD* * VoD* \ 183 *Pump* *Pump* \ 184 ****** ****** \ 185 | | \ 186 *** |-| |-| *** *** ********** |-----| |---| 187 *r*-----|r|-----|r|----*r*--*r*--*RSVP *--|DSLAM|~~~~|STB|--TV 188 *** |-| |-| *** *** *Receiver* |-----| |---| 189 *Proxy * 190 ********** 191 <-Backbone--> 192 (non-RSVP) 193 <---Aggregation------> 194 (RSVP) 196 (1) **********************************> 197 ==========RSVP=======> 199 (2) *********************************************************> 200 =======................===========RSVP======> 202 SRM Session Resource Manager 204 *** |---| 205 *r* regular RSVP |STB| Set Top Box 206 *** router |---| 208 ****** 209 * VoD* RSVP capable VoD Pump 210 *Pump* 211 ****** 213 ***> VoD media flow 215 ==> segment of flow path protected by RSVP reservation 217 /\ VoD Application level signaling (e.g. RTSP) 219 Figure 1: RSVP Deployment for VoD 221 VoD service is operational in SFR (without RSVP) since 2007. The 222 RSVP solution is being validated and deployment strategies are being 223 defined. 225 While part of the aggregation nodes are capable of supporting RSVP 226 and RSVP Receiver Proxy, some nodes are not. This forces us to 227 consider the network in two different part: 229 o the RSVP-capable aggregation network: It will have a RSVP proxy 230 and then will be protected by RSVP admission control. 232 o The non-RSVP-capable aggregation network. It will not have RSVP 233 proxy and will not be protected by admission control 235 The implementation of the coupling between RSVP and RTSP on the VoD 236 streamer has to take care of this two topologies: we have to allow 237 the streamer to send his RTSP flow even if RSVP reservation is not 238 fully reserved on the path. Here is how VoD streamers will made the 239 link between RSVP and RTSP : 241 o When the streamer receive an RTSP SETUP, it will start the RTSP 242 streaming and send his RSVP PATH message 244 o If the streamer receives an RSVP RESV message, it means that the 245 path is protect by RSVP and the streamer keep its RTSP stream and 246 its RSVP context 248 o If the RSVP timer expired, it means that the path is not is 249 protected by RSVP so the streamer tear down its RSVP context but 250 keep its RTSP session 252 o If the streamer receives an RSVP ERROR message, it means that path 253 is protected by RSVP but there is not enough bandwidth so the 254 streamer tears down its RSVP session and its RTSP session. 256 This kind of behavior of the RSVP streamer also allows us to deploy 257 RSVP on the network step by step with no impact on the customer 258 quality. 260 4. Recommendation 262 SFR will deploy the RSVP admission control to protect the VoD streams 263 of its residential broadband customers. Therefore, it will be 264 beneficial to SFR if the IETF keeps working on open RSVP-based 265 solutions benefiting from different industry experts to unsure good 266 interoperability between different vendors. 268 5. Security Considerations 270 As explained in Section 3, opening our control plane to an on-path 271 admission control protocol raises some security concerns. Without 272 proper security measures, we can not control that a reservation is 273 really made for a VoD flow, and we expose ourselves to an attack on 274 our control plane. To solve this problem, we will filter all RSVP 275 messages from untrusted network (peering, transit, customer) and rely 276 on RSVP receiver proxy on the interface facing the DSLAM and the 277 customers that need RSVP protected VoD flows. On each router where 278 RSVP is enabled, we will also activate pacing and rate limiting of 279 RSVP messages to protect the CPU of the node. 281 6. IANA Considerations 283 Not applicable 285 7. Normative References 287 [I-D.ietf-tsvwg-rsvp-proxy-approaches] 288 Faucheur, F., Guillou, A., Manner, J., and D. Wing, "RSVP 289 Proxy Approaches", 290 draft-ietf-tsvwg-rsvp-proxy-approaches-08 (work in 291 progress), October 2009. 293 [I-D.ietf-tsvwg-rsvp-proxy-proto] 294 Faucheur, F., Guillou, A., Manner, J., Malik, H., and A. 295 Narayanan, "RSVP Extensions for Path-Triggered RSVP 296 Receiver Proxy", draft-ietf-tsvwg-rsvp-proxy-proto-10 297 (work in progress), October 2009. 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, March 1997. 302 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 303 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 304 Functional Specification", RFC 2205, September 1997. 306 Author's Address 308 Allan Guillou 309 40-42 Quai du Point du Jour 310 Boulogne-Billancourt, 92659 311 France 313 Email: allan.guillou@neufcegetel.fr