Network Working Group                                        Huajin Jeng
Internet Draft                                                      AT&T
Intended status: Standards Track
Expires: June 2013                                             Jeff Haas
                                                        Juniper Networks

                                                           Yakov Rekhter
                                                        Juniper Networks

                                                 Jeffrey (Zhaohui) Zhang
                                                        Juniper Networks







                                                        December 31 2012


                   Multicast Geo-Distribution Control


             draft-rekhter-geo-distribution-control-02.txt

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.






Jeng                                                            [Page 1]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


Copyright Notice

   Copyright (c) 2011 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.


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.
























Jeng                                                            [Page 2]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


Table of Contents

 1          Specification of requirements  .........................   3
 2          Introduction  ..........................................   3
 3          Overview of Operations  ................................   4
 4          Multicast Distribution Reachability Signaling  .........   5
 5          Multicast Distribution Control Signaling  ..............   6
 5.1        An example of configuration on ERs  ....................   9
 6          IANA Considerations  ...................................  10
 7          Security Considerations  ...............................  10
 8          Acknowledgements  ......................................  10
 9          References  ............................................  10
 9.1        Normative References  ..................................  10
 9.2        Informative References  ................................  10
10          Authors' Addresses  ....................................  11






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 [RFC2119].


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




Jeng                                                            [Page 3]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


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


3. Overview of Operations

   An ISP, using the procedures described in Section "Multicast
   Distribution Reachability Signaling", 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.

   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", 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 Section "Multicast Distribution Control



Jeng                                                            [Page 4]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


   Signaling".

   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. Mapping between a
   particular content and the multicast channel used for distributing
   this content is maintained by both Content Server(s) and Content
   Distribution Controller(s) of the content provider. Procedures by
   which the content provider selects a particular multicast channel,
   and maintains the mapping are outside the scope of this document.

   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.

   Specification of the procedures for communication between subscribers
   and Content Distribution Controllers are outside the scope of this
   document.


4. Multicast Distribution Reachability Signaling

   Multicast distribution reachability signaling is responsible for
   giving a content provider, and specifically Content Distribution
   Controller(s) of the content provider the information of whether a
   particular subscriber of that content provider has multicast
   connectivity to an ER of an ISP that the content provider uses for
   distributing its content.




Jeng                                                            [Page 5]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


   This document assumes that each ER can determine the multicast
   reachability status for each of the subscriber connected to that ER.
   Procedures by which an ER accomplishes this are outside the scope of
   this document.

   To indicate whether a given ER has multicast reachability to a
   subscriber (be that either a native multicast or AMT) this document
   uses BGP as follows. An ER originates into IBGP routes for the
   subscribers connected to that ER for which the ER has multicast
   reachability. These routes are carried using BGP multi-protocol
   capabilities [RFC4760] with AFI 1 or 2, and MCAST-REACH SAFI. The
   NLRI field in the MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these
   routes contains subscribers' IP addresses encoded as IP address
   prefixes. The value of the AFI field in the
   MP_REACH_NLRI/MP_UNREACH_NLRI attribute of these routes determines
   whether subscribers' addresses are IPv4 or IPv6 (AFI 1 indicates IPv4
   addresses, AFI 2 indicates IPv6 addresses).

   A Content Distribution Controller, when it receives such routes, uses
   them to determine whether the content could be delivered to the
   subscribers via the ISP who owns the ERs using the multicast
   connectivity service provided by the ISP.

   To constrain the flow of BGP routes that carry multicast distribution
   reachability information such routes carry a particular Route Target
   (RT) Extended Community [RFC4360], and Content Distribution
   Controller(s) are provisioned to import routes with such RT.

   RTs carried by routes with AFI 1 and MCAST-REACH SAFI SHOULD NOT be
   re-used by routes with any other AFI and/or SAFI. Likewise, RTs
   carried by routes with AFI 2 and MCAST-REACH SAFI SHOULD NOT be re-
   used by routes with any other AFI and/or SAFI.

   To facilitate such constrained distribution of multicast distribution
   reachability information one MAY use Route Target Constrains
   [RFC4684].


5. Multicast Distribution Control Signaling

   Multicast distribution control signaling is intended to enforce
   exclusion/inclusion policies of a content provider, and specifically
   to prevent a subscriber from accessing a particular multicast channel
   carrying a particular content provided by the content provider if the
   subscriber obtained the information about this channel through some
   illegitimate means.

   Multicast distribution control signaling for a particular content is



Jeng                                                            [Page 6]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


   originated by Content Distribution Controller(s), and uses BGP Flow
   Spec [RFC5575] as follows.

   For a particular content carried over a particular (S, G) multicast
   flow the Content Distribution Controller responsible for that content
   originates a BGP Flow Spec route. This route is carried using BGP
   multi-protocol capabilities [RFC4760] with AFI 1 (for IPv4) or 2 (for
   IPv6), and MCAST-FLOWSPEC SAFI. The NLRI of the route carries S in
   the Source Prefix component (with length of 32 for IPv4 or 128 for
   IPv6), and G in the Destination Prefix component (with length of 32
   for IPv4 of 128 for IPv6).

   This route is ultimately propagated to the ER of the ISP connected to
   the content provider.

   An ER that receives BGP Flow Spec routes carrying the multicast
   distribution control information applies it to PIM and/or IGMP
   messages the ER receives from the subscribers connected to that ER.
   Specifically, the ER, based on the information received in the BGP
   Flow Spec routes, decides whether to accept (or reject) a particular
   PIM or IGMP Join received on one of its subscriber's ports, as
   follows.

   Associated with each zone are two sets of RTs - one that controls
   inclusion, and another than controls exclusion. This document assumes
   that a content provider and the ISP(s) connected to that content
   provider maintain consistent information about the RTs associated
   with each zone. Procedures to accomplish this are outside the scope
   of this document.

   As a Content Distribution Controller originates a BGP Flow Spec route
   for a particular (S, G) multicast flow, such a route will carry one
   or more RTs, which will ultimately control inclusion/exclusion of
   that flow on individual ports of ERs that receive this route.

   Each subscriber port on an ER is associated with one or more zones.
   For each zone that a port belongs to, the port is provisioned with
   two sets of RTs associated with that zone - the inclusion set is for
   allowing to accept PIM or IGMP Join for some content (or to be more
   precise for the (S, G) flow that carries that content), and the
   exclusion set is for disallowing to accept PIM or IGMP Joins for some
   other content. All those RTs (of all subscribers ports) control
   import of BGP Flow Spec routes by the ER.

   If the RTs carried by a given BGP Flow Spec route carrying multicast
   distribution control signaling match the inclusion set of RTs
   associated with a given port on an ER, then PIM or IGMP Joins for the
   (S, G) carried in the route and received from the subscriber(s)



Jeng                                                            [Page 7]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


   connected to that port SHOULD be accepted by the ER. If the RTs
   carried by the route match the exclusion set, then PIM or IGMP Joins
   for the (S, G) carried in the route MUST NOT be accepted when
   received from the subscriber(s) connected to that port.

   Each subscriber port on an ER is provisioned with the default
   inclusion/exclusion policy that controls acceptance (or rejection) of
   PIM or IGMP Join messages in the absence of any multicast
   distribution control signaling. In the former case, in the absence of
   any multicast distribution signaling, subscribers connected to that
   port may receive any multicast flow. In the latter case, in the
   absence of any multicast distribution control signaling, subscribers
   connected to that port may receive no multicast flows.  BGP Flow Spec
   routes that carry multicast distribution control signaling modify
   such default behavior.

   Once a Content Distribution Controller determines that a particular
   (S, G) multicast stream no longer used to carry a particular content,
   the Content Distribution Controller withdraws the BGP Flow Spec route
   that carries multicast distribution control information for that
   content.

   Note that while [RFC5575] uses the information carried in BGP Flow
   Spec routes for the purpose of Data Plane filtering, this document
   uses this information for the purpose of filtering multicast Control
   Plane traffic (PIM or IGMP).

   To constrain the distribution of BGP Flow Spec routes that carry
   multicast distribution control information to only the relevant ERs,
   the ERs MAY originate Route Target Constraint (RTC) routes that carry
   the RTs that control import of the BGP Flow Spec routes on these ERs.

   To constrain the import of these RTC routes to only the Content
   Distribution Controllers, the Content Distribution Controllers are
   configured with one or more RTs. These RTs control import by the
   Content Distribution Controller(s) of the RTC routes originated by
   the ERs. Furthermore, the Content Distribution Controllers MAY
   themselves originate RTC routes that carry the import RT(s)
   configured on these Content Distribution Controllers, and that
   control import of RTC routes by these Content Distribution
   Controllers.

   This document assumes that if a given content provider has multiple
   Content Distribution Controllers, then all of these Controllers are
   provisioned with the same RT(s) that control import of the RTC routes
   originated by the ERs.  Furthermore, this document assumes that if a
   given ISP is providing (multicast) connectivity service to more than
   one content provider, then the RTC routes originated by any of the



Jeng                                                            [Page 8]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


   ERs of that ISP MUST carry the set union of the import RTs used by
   the Content Distribution Controllers of all of these content
   providers.

   RTs carried by routes with AFI 1 and MCAST-FLOWSPEC SAFI SHOULD NOT
   be re-used by routes with any other AFI and/or SAFI. Likewise, RTs
   carried by routes wiht AFI 2 and MCAST-FLOWSPEC SAFI SHOULD NOT be
   re-used by routes with any other AFI and/or SAFI. Furthermore, RTs
   carried by routes with AFI 1 and SAFI 132 (AFI/SAFI used by RTC
   routes) SHOULD NOT be re-used by routes with any other AFI and/or
   SAFI.

   Note that while [RFC4684] uses RTC routes to constrain distribution
   of VPN-IP routes [RFC4364], this document uses RTC routes to
   constrain distribution of BGP Flow Spec routes, and also to
   (recursively) constrain distribution of RTC routes themselves.


5.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
   wiht the following import RTs:

     <include-brookline, exclude-brookline, 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                                                            [Page 9]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


6. IANA Considerations

   This document defines two new SAFIs - MCAST-REACH and MCAST-FLOWSPEC.


7. Security Considerations

   TBD.


8. Acknowledgements

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


9. References

9.1. Normative References

   [RFC2119] "Key words for use in RFCs to Indicate Requirement
   Levels.", Bradner, March 1997

   [RFC5575] "Dissemination of Flow Specification Rules", P. Marques, et
   al., August 2009

   [RFC4760] Bates, T., Rekhter, Y., Chandra, R., and D. Katz,
   "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.

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



9.2. Informative References

   [RFC4364] E. Rosen, Y. Rekhter, "BGP/MPLS IP Virtual Private Networks
   (VPNs)", RFC4364, February 2006

   [RFC4684] Pedro Marques, et al., "Constrained Route Distribution for
   Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
   Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC4684,
   November 2006








Jeng                                                           [Page 10]


Internet Draftdraft-rekhter-geo-distribution-control-02.txtDecember 2012


10. Authors' Addresses

   Huajin Jeng
   AT&T
   e-mail: hj2387@att.com

   Jeff Haas
   Juniper Networks
   Email: jhaas@juniper.net

   Yakov Rekhter
   Juniper Networks
   Email: yakov@juniper.net

   Jeffrey (Zhaohui) Zhang
   Juniper Networks
   Email: zzhang@juniper.net


































Jeng                                                           [Page 11]