idnits 2.17.1 draft-ietf-mboned-geo-distribution-control-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 6, 2014) is 3730 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Jeng 3 Internet-Draft AT&T 4 Intended status: Standards Track J. Haas 5 Expires: August 10, 2014 Y. Rekhter 6 J. Zhang 7 Juniper Networks 8 February 6, 2014 10 Multicast Geo-Distribution Control 11 draft-ietf-mboned-geo-distribution-control-00 13 Abstract 15 Consider a content provider that wants to deliver a particular 16 content to a set of customers/subscribers, where the provider and the 17 subscribers are connected by an IP service provider. This document 18 covers two areas needed to accomplish this: 20 1. Providing the content provider with the information of whether it 21 can use the multicast connectivity service provided by the IP 22 service provider to deliver a particular content to a particular 23 set of subscribers, and 25 2. Providing the content provider with a mechanism to restrict 26 delivery of a given content to a particular set of the 27 subscribers. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on August 10, 2014. 46 Copyright Notice 47 Copyright (c) 2014 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Specification of Requirements . . . . . . . . . . . . . . . . . 3 63 1.1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Multicast Content Distribution Zones . . . . . . . . . . . 4 65 1.3. A Brief Overview of Multicast Distribution 66 Reachability Signaling . . . . . . . . . . . . . . . . . . 4 67 1.4. A Brief Overview of Multicast Distribution Control 68 Signaling . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 1.4.1. An example of configuration on ERs . . . . . . . . . . 5 70 2. Overview of Operations . . . . . . . . . . . . . . . . . . . . 6 71 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 72 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 73 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 74 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 75 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7 76 6.2. Informative References . . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 79 1. Specification of Requirements 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in RFC 2119 [RFC2119]. 85 1.1. Introduction 87 Consider a content provider that wants to deliver a particular 88 content to a set of customers/subscribers, where the provider and the 89 subscribers are connected by an IP service provider. This document 90 covers two areas needed to accomplish this: 92 1. Providing the content provider with the information of whether it 93 can use the multicast connectivity service provided by the IP 94 service provider to deliver a particular content to a particular 95 set of subscribers, and 97 2. Providing the content provider with a mechanism to restrict 98 delivery of a given content to a particular set of the 99 subscribers. 101 For the purpose of this document we assume that a content provider 102 consists of one or more Content Servers, and one or more Content 103 Distribution Controllers. While this document assumes communication 104 between Content Servers and Content Distribution Controllers, the 105 procedures for implementing such communication is outside the scope 106 of this document. 108 Content Servers are connected to one or more IP service providers 109 (ISP) that can offer both multicast and unicast connectivity service 110 to the subscribers of the content provider. The content provider 111 uses this ISP(s) to deliver content to its subscribers. 113 Subscribers are connected to the Edge Routers (ERs) of the ISP. Note 114 that the multicast connectivity service provided by the ISP extends 115 all the way to the ERs. Such service could be provided by either 116 deploying IP multicast natively, or with some tunneling mechanism 117 like AMT, or by a combination of both within the ISP. However, 118 between the ERs and the subscribers there may, or may not be 119 multicast connectivity. 121 In the case where a particular subscriber of a given content provider 122 does not have multicast connectivity to its ER, the content provider 123 would use IP unicast service provided by the ISP to transmit the 124 particular content to that subscriber. 126 A subscriber may want to access a particular content that is not 127 available to that subscriber due to policy reasons. When that 128 subscriber would have received that content via unicast connectivity, 129 the Content Distribution Controller, or the Content Servers, or both 130 may enforce the policy to not deliver the content. However, when the 131 content would be delivered via multicast connectivity it may be 132 possible for the subscriber to receive the content by illicitly 133 participating in the multicast signaling for that content. 135 To prevent a subversion of the intent of this content delivery 136 policy, a mechanism is provided to make this policy available to 137 devices participating in multicast signaling. 139 1.2. Multicast Content Distribution Zones 141 For each item of content provided by a content provider, the content 142 provider maintains a list of subscribers who are either excluded or 143 allowed to receive the content. For the purpose of maintaining this 144 list this document assumes that subscribers are grouped into "zones" 145 based on IP addresses, so that exclusion/inclusion uniformly applies 146 to all the subscribers within a given zone. Procedures by which 147 subscribers are grouped into zones are outside the scope of this 148 document. However, this document assumes that this grouping is done 149 consistently by both the content provider and the ISP(s) that the 150 content provider uses for delivering its content. 152 One example of an implementation of such a zone is based on the 153 geographic location of the subscribers. Such zones may be used to 154 implement broadcast "blackout" of some content such as a sporting 155 event that may not be allowed to air in certain regions due to 156 regulatory reasons. 158 1.3. A Brief Overview of Multicast Distribution Reachability Signaling 160 Content providers and Content Distribution Controllers need to know 161 the transport mechanism that a subscriber can use to receive some 162 content. Since not all subscribers may be capable of receiving 163 content via IP multicast, Multicast Distribution Reachability 164 Signaling [MDRS] is used to permit the subscriber's ISP to provide 165 this information. 167 MDRS permits advertises a BGP prefix with a new SAFI, MCAST-REACH, to 168 indicate subscribers in the accompanying AFI of the MCAST-REACH SAFI 169 can receive multicast traffic. 171 Please see the MDRS document for more details. 173 1.4. A Brief Overview of Multicast Distribution Control Signaling 175 A content provider or a service provider may need to enforce policies 176 to exclude access to an item of content that is delivered by IP 177 multicast. Multicast Distribution Control Signaling [MDCS] permits 178 this such enforcement to be distributed as BGP flowspec filters with 179 a new SAFI, MCAST-FLOWSPEC. This filters are used by the multicast 180 control plane to determine whether access to multicast content may be 181 made available to downstream routers, including ERs. 183 These flowspec filters are distributed in BGP with Route Targets 184 [RFC4360] that identify the include or exclude policy for a zone. 185 Multicast routers receiving these filters maintain an ordered list of 186 these Route Target policies to install the filters. The multicast 187 control plane then makes use of the filter database to implement the 188 desired policy. 190 1.4.1. An example of configuration on ERs 192 Consider an ER in Manhattan that has a port that is provisioned with 193 the following import RTs: 195 198 When the ER receives a Flow Spec route with RTs, the ER first try to match "include- 200 manhattan" or "exclude-manhattan" (the first ones on the list) - and 201 the result is "include-manhattan". Therefore, the (S, G) carried in 202 the Flow Spec route is allowed on that port of the ER. 204 Consider another ER in Boston that has a port that is provisioned 205 with the following import RTs: 207 210 The above mentioned Flow Spec route will be imported (due to the 211 include-usa RT), and will result in the (S, G) carried in the flow 212 Spec route to be allowed on that port of the ER. 214 Now consider a different Flow Spec route with the RTs. The (S, G) carried 216 in the route will be disallowed in Manhattan, allowed in Boston, and 217 allowed in Queens (as the route will match the "include-nyc" RT). 219 2. Overview of Operations 221 An ISP, using the procedures described in Multicast Distribution 222 Reachability Signaling [MDRS], provides a content provider, and 223 specifically Content Distribution Controller(s) of that content 224 provider, with the information of whether a particular subscriber of 225 that content provider has multicast connectivity to an ER of that ISP 226 with the information of whether a particular group of subscribers can 227 receive multicast content. 229 To enforce the exclusion/inclusion policies, the content provider 230 uses procedures described in Multicast Distribution Control Signaling 231 [MDCS]. 233 For each content provided by a content provider, the content provider 234 selects a particular multicast channel (S, G) for distributing this 235 content using multicast connectivity service. Procedures by which 236 the content provider selects a particular multicast channel, and 237 maintains the mapping are outside the scope of this document. 239 Subscribers are connected to the Edge Routers (ERs) of the ISP. Note 240 that when multicast connectivity service provided is by the ISP, that 241 service extends all the way to the ERs. Such service could be 242 provided by either deploying IP multicast natively, or with some 243 tunneling mechanism like AMT, or a combination of both within the 244 ISP. However, between the ERs and the subscribers there may, or may 245 not be multicast connectivity. 247 When a subscriber wants to receive the particular content from its 248 content provider, the subscriber issues a request for this content to 249 the Content Distribution Controller of the provider. When the 250 Content Distribution Controller receives the request, the Content 251 Distribution Controller uses the information carried in the request 252 (e.g., IP address of the subscriber) to determine the zone of the 253 subscriber, and based on that zone to determine whether the 254 subscriber can receive this content. 256 If the Content Distribution Controller determines that the subscriber 257 can receive the content, then based on the information provided by 258 the multicast distribution reachability signaling the Content 259 Distribution Controller determines whether the subscriber can receive 260 this content using multicast connectivity service, and if yes, then 261 returns to the subscriber the multicast channel selected for 262 distributing the content. 264 If the Content Distribution Controller determines that the subscriber 265 can receive the content, but can not receive the content using 266 multicast connectivity service, the Content Distribution Controller 267 returns to the subscriber the information needed to receive this 268 content using unicast connectivity service. 270 If the content would have been delivered to the subscriber via 271 multicast connectivity, but the Content Distribution Controller had 272 determined the subscriber was not permited access to this content, 273 then this policy may need to be enforced by the Edge Routers or 274 upstream multicast routers to prevent illicit access of this content. 275 This policy is enforced by utilizing filtering information 276 distributed using Multicast Distribution Control Signaling [MDCS]. 278 Specification of the procedures for communication between subscribers 279 and Content Distribution Controllers are outside the scope of this 280 document. 282 3. IANA Considerations 284 This document introduces no IANA Considerations. 286 4. Security Considerations 288 TBD 290 5. Acknowledgements 292 The authors would like to thank Han Nguyen for his contributions to 293 this document. 295 6. References 297 6.1. Normative References 299 [MDCS] Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast 300 Distribution Control Signaling", 301 draft-ietf-idr-mdcs-00.txt (work in progress), 2014. 303 [MDRS] Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast 304 Distribution Reachability Signaling", 305 draft-ietf-idr-mdrs-00.txt (work in progress), 2014. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 6.2. Informative References 312 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 313 Communities Attribute", RFC 4360, February 2006. 315 Authors' Addresses 317 Huajin Jeng 318 AT&T 320 Email: hj2387@att.com 322 Jeffrey Haas 323 Juniper Networks 324 1194 N. Mathida Ave. 325 Sunnyvale, CA 94089 326 US 328 Email: jhaas@juniper.net 330 Yakov Rekhter 331 Juniper Networks 332 1194 N. Mathida Ave. 333 Sunnyvale, CA 94089 334 US 336 Email: yakov@juniper.net 338 Jeffrey (Zhaohui) Zhang 339 Juniper Networks 340 1194 N. Mathida Ave. 341 Sunnyvale, CA 94089 342 US 344 Email: zzhang@juniper.net