idnits 2.17.1 draft-rekhter-geo-distribution-control-03.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 (July 14, 2013) is 3939 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) == Outdated reference: A later version (-01) exists of draft-rekhter-mdcs-00 == Outdated reference: A later version (-01) exists of draft-rekhter-mdrs-00 Summary: 0 errors (**), 0 flaws (~~), 4 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: January 15, 2014 Y. Rekhter 6 J. Zhang 7 Juniper Networks 8 July 14, 2013 10 Multicast Geo-Distribution Control 11 draft-rekhter-geo-distribution-control-03 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 January 15, 2014. 46 Copyright Notice 47 Copyright (c) 2013 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. Overview of Operations . . . . . . . . . . . . . . . . . . 4 65 2. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 66 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 67 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 68 5. Normative References . . . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 71 1. Specification of Requirements 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [RFC2119]. 77 1.1. Introduction 79 Consider a content provider that wants to deliver a particular 80 content to a set of customers/subscribers, where the provider and the 81 subscribers are connected by an IP service provider. This document 82 covers two areas needed to accomplish this: 84 1. Providing the content provider with the information of whether it 85 can use the multicast connectivity service provided by the IP 86 service provider to deliver a particular content to a particular 87 set of subscribers, and 89 2. Providing the content provider with a mechanism to restrict 90 delivery of a given content to a particular set of the 91 subscribers. 93 For the purpose of this document we assume that a content provider 94 consists of one or more Content Servers, and one or more Content 95 Distribution Controllers. While this document assumes communication 96 between Content Servers and Content Distribution Controllers, the 97 procedures for implementing such communication is outside the scope 98 of this document. 100 Content Servers are connected to one or more IP service provider 101 (ISP) that can offer both multicast and unicast connectivity service 102 to the subscribers of the content provider. Content provider uses 103 this ISP(s) to deliver content to its subscribers. 105 Subscribers are connected to the Edge Routers (ERs) of the ISP. Note 106 that the multicast connectivity service provided by the ISP extends 107 all the way to the ERs. Such service could be provided by either 108 deploying IP multicast natively, or with some tunneling mechanism 109 like AMT, or by a combination of both within the ISP. However, 110 between the ERs and the subscribers there may, or may not be 111 multicast connectivity. 113 In the case where a particular subscriber of a given content provider 114 does not have multicast connectivity to its ER, the content provider 115 would use IP unicast service provided by the ISP to transmit the 116 particular content to that subscriber. 118 A subscriber may want to access a particular content that is not 119 available to that subscriber due to policy reasons. When that 120 subscriber would have received that content via unicast connectivity, 121 the Content Distribution Controller, or the Content Servers, or both 122 may enforce the policy to not deliver the content. However, when the 123 content would be delivered via multicast connectivity it may be 124 possible for the subscriber to receive the content by illicitly 125 participating in the multicast signaling for that content. 127 To prevent a subversion of the intent of this content delivery 128 policy, a mechanism is provided to make this policy available to 129 devices participating in multicast signaling. 131 1.2. Overview of Operations 133 An ISP, using the procedures described in Multicast Distribution 134 Reachability Signaling [MDRS], provides a content provider, and 135 specifically Content Distribution Controller(s) of that content 136 provider, with the information of whether a particular subscriber of 137 that content provider has multicast connectivity to an ER of that ISP 138 with the information of whether a particular group of subscribers can 139 receive multicast content. 141 For each content provided by a content provider, the content provider 142 maintains a list of subscribers who are either excluded or allowed to 143 receive the content. For the purpose of maintaining this list this 144 document assumes that subscribers are grouped into "zones" based on 145 IP addresses, so that exclusion/inclusion uniformly applies to all 146 the subscribers within a given zone. Procedures by which subscribers 147 are grouped into zones are outside the scope of this document. 148 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 To enforce the exclusion/inclusion policies, the content provider 153 uses procedures described in Multicast Distribution Control Signaling 154 [MDCS]. 156 For each content provided by a content provider, the content provider 157 selects a particular multicast channel (S, G) for distributing this 158 content using multicast connectivity service. Procedures by which 159 the content provider selects a particular multicast channel, and 160 maintains the mapping are outside the scope of this document. 162 Subscribers are connected to the Edge Routers (ERs) of the ISP. Note 163 that when multicast connectivity service provided is by the ISP, that 164 service extends all the way to the ERs. Such service could be 165 provided by either deploying IP multicast natively, or with some 166 tunneling mechanism like AMT, or a combination of both within the 167 ISP. However, between the ERs and the subscribers there may, or may 168 not be multicast connectivity. 170 When a subscriber wants to receive the particular content from its 171 content provider, the subscriber issues a request for this content to 172 the Content Distribution Controller of the provider. When the 173 Content Distribution Controller receives the request, the Content 174 Distribution Controller uses the information carried in the request 175 (e.g., IP address of the subscriber) to determine the zone of the 176 subscriber, and based on that zone to determine whether the 177 subscriber can receive this content. 179 If the Content Distribution Controller determines that the subscriber 180 can receive the content, then based on the information provided by 181 the multicast distribution reachability signaling the Content 182 Distribution Controller determines whether the subscriber can receive 183 this content using multicast connectivity service, and if yes, then 184 returns to the subscriber the multicast channel selected for 185 distributing the content. 187 If the Content Distribution Controller determines that the subscriber 188 can receive the content, but can not receive the content using 189 multicast connectivity service, the Content Distribution Controller 190 returns to the subscriber the information needed to receive this 191 content using unicast connectivity service. 193 If the content would have been delivered to the subscriber via 194 multicast connectivity, but the Content Distribution Controller had 195 determined the subscriber was not permited access to this content, 196 then this policy may need to be enforced by the Edge Routers or 197 upstream multicast routers to prevent illicit access of this content. 198 This policy is enforced by utilizing filtering information 199 distributed using Multicast Distribution Control Signaling [MDCS]. 201 Specification of the procedures for communication between subscribers 202 and Content Distribution Controllers are outside the scope of this 203 document. 205 2. IANA Considerations 207 This document introduces no IANA Considerations. 209 3. Security Considerations 211 TBD 213 4. Acknowledgements 215 The authors would like to thank Han Nguyen for his contributions to 216 this document. 218 5. Normative References 220 [MDCS] Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast 221 Distribution Control Signaling", draft-rekhter-mdcs-00.txt 222 (work in progress), 2013. 224 [MDRS] Jeng, H., Haas, J., Rekhter, Y., and J. Zhang, "Multicast 225 Distribution Reachability Signaling", 226 draft-rekhter-mdrs-00.txt (work in progress), 2013. 228 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 229 Requirement Levels", BCP 14, RFC 2119, March 1997. 231 Authors' Addresses 233 Huajin Jeng 234 AT&T 236 Email: hj2387@att.com 238 Jeffrey Haas 239 Juniper Networks 240 1194 N. Mathida Ave. 241 Sunnyvale, CA 94089 242 US 244 Email: jhaas@juniper.net 246 Yakov Rekhter 247 Juniper Networks 248 1194 N. Mathida Ave. 249 Sunnyvale, CA 94089 250 US 252 Email: yakov@juniper.net 253 Jeffrey (Zhaohui) Zhang 254 Juniper Networks 255 1194 N. Mathida Ave. 256 Sunnyvale, CA 94089 257 US 259 Email: zzhang@juniper.net