[opendtv] Re: IETF mboned working group on (TV) content distribution
- From: Craig Birkmaier <craig@xxxxxxxxxxxxx>
- To: "opendtv@xxxxxxxxxxxxx" <opendtv@xxxxxxxxxxxxx>
- Date: Fri, 17 Jan 2014 08:10:35 -0500
Thanks Bert!
This is informative. I will admit that it is not clear to me why IP multicasts
cannot be relied upon from large portals through the WAN to the ISPs. But it is
obvious that edge servers will be needed if the Internet is to scale up to
deliver TV to the masses, so it may not matter; the ISPs will need to deal with
this issue.
It is also obvious that the mboned group has been tasked with making all of
this work with full access control by the content providers who colocate
servers. Whether this is intended to continue leveraging the MVPD bundles for
authorization, or will lead to smaller bundles of programming controlled by
paid apps remains to be seen...
Regards
Craig
> On Jan 16, 2014, at 4:52 PM, "Manfredi, Albert E"
> <albert.e.manfredi@xxxxxxxxxx> wrote:
>
> How timely of them. Just now, I received an e-mail asking whether the mboned
> working group supports this IETF working group draft.
>
> http://tools.ietf.org/id/draft-rekhter-geo-distribution-control-03.txt
>
> I thought Craig might be interested in what is being addressed. It's a short
> and sweet Internet Draft.
>
> Note that this is the mboned wg, so its interests lie in multicast delivery.
> This document shows how IP multicast typically only spans the network of a
> given ISP, in a given location. It's not usually Internet-wide by any means.
> And it may also not be available at all, in a given local ISP network.
>
> The document also explains that the server or servers of a given content
> owner is/are located inside the ISP's network, in a specific geo location.
> Content to each of these servers can be distributed by the owner in many
> different ways, and that's not the topic of this Internet Draft.
>
> When multicast is available in that ISP's lcal network, if the content owner
> wants to block certain end users from receiving the multicast content, then
> this document says to check the customer's packets when this customer signals
> to join the multicast group, and compare against a list of approved
> customers. All of this being under the control of the content owner, whether
> unicast or multicast.
>
> Nothing here is earth-shattering, but I think it should help to clarify how
> these TV distribution networks are architected, and what the content owner,
> vs the ISP, controls. In particular, the servers, controlled by individual
> content owners, that would be distributed throughout ISP networks in every
> market, and have a say as to who is allowed to watch what.
>
> It's all in the hands of the content owner. If instead it were in others'
> hands, the net would potentially not be neutral.
>
> Bert
>
> -----------------------------
> 1.1. Introduction
>
> Consider a content provider that wants to deliver a particular
> content to a set of customers/subscribers, where the provider and the
> subscribers are connected by an IP service provider. This document
> covers two areas needed to accomplish this:
>
> 1. Providing the content provider with the information of whether it
> can use the multicast connectivity service provided by the IP
> service provider to deliver a particular content to a particular
> set of subscribers, and
>
> 2. Providing the content provider with a mechanism to restrict
> delivery of a given content to a particular set of the
> subscribers.
>
> For the purpose of this document we assume that a content provider
> consists of one or more Content Servers, and one or more Content
> Distribution Controllers. While this document assumes communication
> between Content Servers and Content Distribution Controllers, the
> procedures for implementing such communication is outside the scope
> of this document.
>
> Content Servers are connected to one or more IP service provider
> (ISP) that can offer both multicast and unicast connectivity service
> to the subscribers of the content provider. Content provider uses
> this ISP(s) to deliver content to its subscribers.
>
> Subscribers are connected to the Edge Routers (ERs) of the ISP. Note
> that the multicast connectivity service provided by the ISP extends
> all the way to the ERs. Such service could be provided by either
> deploying IP multicast natively, or with some tunneling mechanism
> like AMT, or by a combination of both within the ISP. However,
> between the ERs and the subscribers there may, or may not be
> multicast connectivity.
>
> In the case where a particular subscriber of a given content provider
> does not have multicast connectivity to its ER, the content provider
> would use IP unicast service provided by the ISP to transmit the
> particular content to that subscriber.
>
> A subscriber may want to access a particular content that is not
> available to that subscriber due to policy reasons. When that
> subscriber would have received that content via unicast connectivity,
> the Content Distribution Controller, or the Content Servers, or both
> may enforce the policy to not deliver the content. However, when the
> content would be delivered via multicast connectivity it may be
> possible for the subscriber to receive the content by illicitly
> participating in the multicast signaling for that content.
>
> To prevent a subversion of the intent of this content delivery
> policy, a mechanism is provided to make this policy available to
> devices participating in multicast signaling.
>
> 1.2. Overview of Operations
>
> An ISP, using the procedures described in Multicast Distribution
> Reachability Signaling [MDRS], provides a content provider, and
> specifically Content Distribution Controller(s) of that content
> provider, with the information of whether a particular subscriber of
> that content provider has multicast connectivity to an ER of that ISP
> with the information of whether a particular group of subscribers can
> receive multicast content.
>
> For each content provided by a content provider, the content provider
> maintains a list of subscribers who are either excluded or allowed to
> receive the content. For the purpose of maintaining this list this
> document assumes that subscribers are grouped into "zones" based on
> IP addresses, so that exclusion/inclusion uniformly applies to all
> the subscribers within a given zone. Procedures by which subscribers
> are grouped into zones are outside the scope of this document.
> However, this document assumes that this grouping is done
> consistently by both the content provider and the ISP(s) that the
> content provider uses for delivering its content.
>
> To enforce the exclusion/inclusion policies, the content provider
> uses procedures described in Multicast Distribution Control Signaling
> [MDCS].
>
> For each content provided by a content provider, the content provider
> selects a particular multicast channel (S, G) for distributing this
> content using multicast connectivity service. Procedures by which
> the content provider selects a particular multicast channel, and
> maintains the mapping are outside the scope of this document.
>
> Subscribers are connected to the Edge Routers (ERs) of the ISP. Note
> that when multicast connectivity service provided is by the ISP, that
> service extends all the way to the ERs. Such service could be
> provided by either deploying IP multicast natively, or with some
> tunneling mechanism like AMT, or a combination of both within the
> ISP. However, between the ERs and the subscribers there may, or may
> not be multicast connectivity.
>
> When a subscriber wants to receive the particular content from its
> content provider, the subscriber issues a request for this content to
> the Content Distribution Controller of the provider. When the
> Content Distribution Controller receives the request, the Content
> Distribution Controller uses the information carried in the request
> (e.g., IP address of the subscriber) to determine the zone of the
> subscriber, and based on that zone to determine whether the
> subscriber can receive this content.
>
> If the Content Distribution Controller determines that the subscriber
> can receive the content, then based on the information provided by
> the multicast distribution reachability signaling the Content
> Distribution Controller determines whether the subscriber can receive
> this content using multicast connectivity service, and if yes, then
> returns to the subscriber the multicast channel selected for
> distributing the content.
>
> If the Content Distribution Controller determines that the subscriber
> can receive the content, but can not receive the content using
> multicast connectivity service, the Content Distribution Controller
> returns to the subscriber the information needed to receive this
> content using unicast connectivity service.
>
> If the content would have been delivered to the subscriber via
> multicast connectivity, but the Content Distribution Controller had
> determined the subscriber was not permited access to this content,
> then this policy may need to be enforced by the Edge Routers or
> upstream multicast routers to prevent illicit access of this content.
> This policy is enforced by utilizing filtering information
> distributed using Multicast Distribution Control Signaling [MDCS].
>
> Specification of the procedures for communication between subscribers
> and Content Distribution Controllers are outside the scope of this
> document.
>
>
>
> ----------------------------------------------------------------------
> You can UNSUBSCRIBE from the OpenDTV list in two ways:
>
> - Using the UNSUBSCRIBE command in your user configuration settings at
> FreeLists.org
>
> - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
> unsubscribe in the subject line.
>
----------------------------------------------------------------------
You can UNSUBSCRIBE from the OpenDTV list in two ways:
- Using the UNSUBSCRIBE command in your user configuration settings at
FreeLists.org
- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word
unsubscribe in the subject line.
Other related posts:
