Internet DRAFT - draft-guillou-tsvwg-rsvp-vod
draft-guillou-tsvwg-rsvp-vod
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]
