Internet DRAFT - draft-ietf-mboned-geo-distribution-control

draft-ietf-mboned-geo-distribution-control






Internet Engineering Task Force                                  H. Jeng
Internet-Draft                                                      AT&T
Intended status: Standards Track                                 J. Haas
Expires: August 10, 2014                                      Y. Rekhter
                                                                J. Zhang
                                                        Juniper Networks
                                                        February 6, 2014


                   Multicast Geo-Distribution Control
             draft-ietf-mboned-geo-distribution-control-00

Abstract

   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.


Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on August 10, 2014.

Copyright Notice




Jeng, et al.             Expires August 10, 2014                [Page 1]

Internet-Draft     Multicast Geo Distribution Control      February 2014


   Copyright (c) 2014 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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 Simplified BSD License.


Table of Contents

   1.  Specification of Requirements . . . . . . . . . . . . . . . . . 3
     1.1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . 3
     1.2.  Multicast Content Distribution Zones  . . . . . . . . . . . 4
     1.3.  A Brief Overview of Multicast Distribution
           Reachability Signaling  . . . . . . . . . . . . . . . . . . 4
     1.4.  A Brief Overview of Multicast Distribution Control
           Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5
       1.4.1.  An example of configuration on ERs  . . . . . . . . . . 5
   2.  Overview of Operations  . . . . . . . . . . . . . . . . . . . . 6
   3.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   6.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     6.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     6.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8



















Jeng, et al.             Expires August 10, 2014                [Page 2]

Internet-Draft     Multicast Geo Distribution Control      February 2014


1.  Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 providers
   (ISP) that can offer both multicast and unicast connectivity service
   to the subscribers of the content provider.  The 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



Jeng, et al.             Expires August 10, 2014                [Page 3]

Internet-Draft     Multicast Geo Distribution Control      February 2014


   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.  Multicast Content Distribution Zones

   For each item of 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.

   One example of an implementation of such a zone is based on the
   geographic location of the subscribers.  Such zones may be used to
   implement broadcast "blackout" of some content such as a sporting
   event that may not be allowed to air in certain regions due to
   regulatory reasons.

1.3.  A Brief Overview of Multicast Distribution Reachability Signaling

   Content providers and Content Distribution Controllers need to know
   the transport mechanism that a subscriber can use to receive some
   content.  Since not all subscribers may be capable of receiving
   content via IP multicast, Multicast Distribution Reachability
   Signaling [MDRS] is used to permit the subscriber's ISP to provide
   this information.

   MDRS permits advertises a BGP prefix with a new SAFI, MCAST-REACH, to
   indicate subscribers in the accompanying AFI of the MCAST-REACH SAFI
   can receive multicast traffic.

   Please see the MDRS document for more details.






Jeng, et al.             Expires August 10, 2014                [Page 4]

Internet-Draft     Multicast Geo Distribution Control      February 2014


1.4.  A Brief Overview of Multicast Distribution Control Signaling

   A content provider or a service provider may need to enforce policies
   to exclude access to an item of content that is delivered by IP
   multicast.  Multicast Distribution Control Signaling [MDCS] permits
   this such enforcement to be distributed as BGP flowspec filters with
   a new SAFI, MCAST-FLOWSPEC.  This filters are used by the multicast
   control plane to determine whether access to multicast content may be
   made available to downstream routers, including ERs.

   These flowspec filters are distributed in BGP with Route Targets
   [RFC4360] that identify the include or exclude policy for a zone.
   Multicast routers receiving these filters maintain an ordered list of
   these Route Target policies to install the filters.  The multicast
   control plane then makes use of the filter database to implement the
   desired policy.

1.4.1.  An example of configuration on ERs

   Consider an ER in Manhattan that has a port that is provisioned with
   the following import RTs:

         <include-manhattan, exclude-manhattan, include-nyc, exclude-
         nyc, include-east, exclude-east, include-usa, exclude-usa>

   When the ER receives a Flow Spec route with <exclude-nyc, include-
   manhattan, include-usa> RTs, the ER first try to match "include-
   manhattan" or "exclude-manhattan" (the first ones on the list) - and
   the result is "include-manhattan".  Therefore, the (S, G) carried in
   the Flow Spec route is allowed on that port of the ER.

   Consider another ER in Boston that has a port that is provisioned
   with the following import RTs:

         <include-cambridge, exclude-cambridge, include-bos, exclude-
         bos, include-east, exclude-east, include-usa, exclude-usa>

   The above mentioned Flow Spec route will be imported (due to the
   include-usa RT), and will result in the (S, G) carried in the flow
   Spec route to be allowed on that port of the ER.

   Now consider a different Flow Spec route with the <exclude-usa,
   include-bos, include-nyc, exclude-manhattan> RTs.  The (S, G) carried
   in the route will be disallowed in Manhattan, allowed in Boston, and
   allowed in Queens (as the route will match the "include-nyc" RT).






Jeng, et al.             Expires August 10, 2014                [Page 5]

Internet-Draft     Multicast Geo Distribution Control      February 2014


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.

   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



Jeng, et al.             Expires August 10, 2014                [Page 6]

Internet-Draft     Multicast Geo Distribution Control      February 2014


   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.


3.  IANA Considerations

   This document introduces no IANA Considerations.


4.  Security Considerations

   TBD


5.  Acknowledgements

   The authors would like to thank Han Nguyen for his contributions to
   this document.


6.  References

6.1.  Normative References

   [MDCS]     Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast
              Distribution Control Signaling",
              draft-ietf-idr-mdcs-00.txt (work in progress), 2014.

   [MDRS]     Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast
              Distribution Reachability Signaling",
              draft-ietf-idr-mdrs-00.txt (work in progress), 2014.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.





Jeng, et al.             Expires August 10, 2014                [Page 7]

Internet-Draft     Multicast Geo Distribution Control      February 2014


6.2.  Informative References

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, February 2006.


Authors' Addresses

   Huajin Jeng
   AT&T

   Email: hj2387@att.com


   Jeffrey Haas
   Juniper Networks
   1194 N. Mathida Ave.
   Sunnyvale, CA  94089
   US

   Email: jhaas@juniper.net


   Yakov Rekhter
   Juniper Networks
   1194 N. Mathida Ave.
   Sunnyvale, CA  94089
   US

   Email: yakov@juniper.net


   Jeffrey (Zhaohui) Zhang
   Juniper Networks
   1194 N. Mathida Ave.
   Sunnyvale, CA  94089
   US

   Email: zzhang@juniper.net












Jeng, et al.             Expires August 10, 2014                [Page 8]