idnits 2.17.1 draft-tarapore-mboned-multicast-cdni-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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 8. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 9, 2012) is 4308 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'A-0200003' on line 414 looks like a reference -- Missing reference section? 'A-0200004' on line 419 looks like a reference -- Missing reference section? 'RFC2784' on line 406 looks like a reference -- Missing reference section? 'IETF-ID-AMT' on line 409 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Percy S. Tarapore 2 Internet Draft Robert Sayko 3 Intended status: BCP AT&T 4 Expires: January 9, 2013 Ram Krishnan 5 Brocade 6 July 9, 2012 8 Multicast Considerations in Support of CDN-I 9 draft-tarapore-mboned-multicast-cdni-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on January 9, 2012. 34 Copyright Notice 36 Copyright (c) 2012 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Abstract 51 This document examines the current capabilities of multicast to 52 support content distribution in an environment involving multiple 53 Service Providers joining together to form a Content Distribution 54 Network Interconnection (CDN-I) Federation. 56 Table of Contents 58 1. Introduction...................................................2 59 2. CDN Nomenclature...............................................3 60 3. Multicast Use Cases for a CDN-I Federation.....................4 61 3.1. Native Multicast Use Case.................................5 62 3.2. Automatic Multicast Tunneling Use Cases...................5 63 3.2.1. AMT Interconnection Between P-CDN and S-CDN..........6 64 3.2.2. AMT Tunnel Connecting S-CDN and EU...................7 65 3.2.3. AMT Tunnel Connecting EU to P-CDN Through Non-Multicast 66 S-CDN.......................................................7 67 4. Content Types Suitable for Multicast-based CDN.................8 68 4.1. Live Content..............................................8 69 4.2. "Delayed-Play" Download...................................8 70 4.3. "Instant-Play" Download...................................8 71 5. Evaluation of Native Multicast for CDN.........................9 72 6. Evaluation of AMT for CDN......................................9 73 7. Security Considerations.......................................10 74 8. IANA Considerations...........................................10 75 TBD..............................................................10 76 9. Conclusions...................................................10 77 10. References...................................................11 78 10.1. Normative References....................................11 79 10.2. Informative References..................................11 80 11. Acknowledgments..............................................11 82 1. Introduction 84 Content Providers (CP) are experiencing significant growth in demand 85 for all types of internet-based content. A single "over-the-top" CP 86 would require significant resources to deliver content that could be 87 requested from anywhere in the world. Service Providers (SP) are 88 taking advantage of this situation by forming Content Distribution 89 Network (CDN) Federations for the purpose of distributing content on 90 behalf of Content Providers (CP). There are several advantages to 91 such CDN Federations: 93 o CPs can simply contract with one or more SPs in a CDN Federation 94 for delivery of their content. This enables CPs to concentrate on 95 their main objective - creation of content. 97 o SPs can expand their geographic reach via distribution agreements 98 with Federation members without developing costly resources 99 outside their local territories. 101 Multicast-based delivery mechanisms are a natural fit for content 102 distribution in the proposed CDN Federations. The scope of this 103 document is strictly focused on the interactions between CDN 104 Federation members to support multicast-based content distribution. 105 The purpose of this document is the detailed examination of 106 applicable multicast techniques and the identification of detailed 107 data/metadata/parameters that will have to be exchanged by CDN 108 Federation members to enable multicast-based content distribution. 110 2. CDN Nomenclature 112 Terminology utilized to describe end-to-end user requests is 113 described as follows. 115 There are many entities involved in distribution of the content from 116 the CP all the way to the End User (EU). Figure 1 is a diagram 117 depicting the basic logical relationships among the various roles 118 involved in content delivery. Besides the CP and EU, the two 119 remaining major entities are the two members of a CDN Federation - 120 the Primary CDN Provider (P-CDN) and the Supporting CDN Provider (S- 121 CDN) [A-0200003]. The relationships between these entities are as 122 follows - see Figure 1. 124 1. The Content Provider owns the content and specifies conditions of 125 delivery and use. The End User interacts with the CP (link 1 in 126 the figure) for authentication and authorization, and to reach an 127 agreement to obtain specific content (content selection, content 128 purchase, acknowledgement of conditions of use). The CP has the 129 legal right to distribute content and specify conditions for 130 distribution. 132 2. The CP has an agreement and interacts with the P-CDN for deploying 133 content (link 2). 135 3. The P-CDN in turn has an agreement with an S-CDN for deploying and 136 distributing content (link 3). 138 4. The End User is attached to S-CDN for access and obtains the 139 content from the S-CDN (link 4). The End User also interacts with 140 the CP (link 1) as indicated above. 142 ----------------------------------------------- 143 | (1) | 144 v | 145 +---------+ +---------+ +---------+ +---------+ 146 | | | | | | | | 147 | Content | | Primary | | Suppor- | | End | 148 | Provider| --> | CDN | --> | -ting | --> | User | 149 | | (2) | | (3) | CDN | (4) | | 150 | | | | | | | | 151 +---------+ +---------+ +---------+ +---------+ 153 Figure 1 - Relationships in a CDN Federation 155 Note that all SPs in the CDN Federation can play the role of P-CDN 156 (active relationship with a CP) as well as an S-CDN (attach EUs and 157 distribute content from P-CDN to EUs). 159 3. Multicast Use Cases for a CDN-I Federation 161 Use cases involving multicast methods for distributing content in a 162 CDN Federation have been described in [A-0200004]. 164 3.1. Native Multicast Use Case 166 ------------------- ------------------- 167 / P-CDN \ / S-CDN \ 168 / (Multicast Enabled) \ / (Multicast Enabled) \ 169 / \ / \ 170 | +----+ | | | 171 | | | +------+ | | +------+ | +----+ 172 | | CS |------>| BR |-|---------|->| BR |-------------|--->| EU | 173 | | | +------+ | I1 | +------+ | I2 +----+ 174 \ +----+ / \ / 175 \ / \ / 176 \ / \ / 177 ------------------- ------------------- 179 CS = Content Server 180 BR = Border Router 181 I1 = P-CDN and S-CDN Multicast Interconnection (MBGP or BGMP) 182 I2 = S-CDN and EU Multicast Connection 184 Figure 1 - Content Distribution via End to End Native Multicast 186 This case assumes that both CDN Providers as well as the 187 interconnection between them and the connection between the EU and S- 188 CDN are all multicast enabled. 190 A variation of this "pure" Native Multicast case is when the 191 interconnection I1 between the CDNs is multicast enabled via a 192 Generic Routing Encapsulation Tunnel (GRE) [RFC2784] instead of 193 utilizing MBGP or BGMP protocols. 195 3.2. Automatic Multicast Tunneling Use Cases 197 In reality, the initial introduction of multicast may not be fully 198 multicast enabled resulting in "Multicast Islands" requiring 199 Automatic Multicast Tunnels (AMT) for enabling multicast connections 200 between them [IETF-ID-AMT]. 202 3.2.1. AMT Interconnection Between P-CDN and S-CDN 204 ------------------- ------------------- 205 / P-CDN \ / S-CDN \ 206 / (Multicast Enabled) \ / (Multicast Enabled) \ 207 / \ / \ 208 | +----+ | | | 209 | | | +------+ | | +------+ | +----+ 210 | | CS |------>| AR |-|---------|->| AG |-------------|--->| EU | 211 | | | +------+ | I1 | +------+ | I2 +----+ 212 \ +----+ / \ / 213 \ / \ / 214 \ / \ / 215 ------------------- ------------------- 217 AR = AMT Relay 218 AG = AMT Gateway 219 I1 = AMT Interconnection between P-CDN and S-CDN 220 I2 = S-CDN and EU Multicast Connection 222 Figure 3 - AMT Interconnection between P-CDN and S-CDN 224 This configuration assumes both CDN Providers are multicast enabled. 225 Only the interconnection between them is not multicast enabled and 226 hence, an AMT tunnel is established between them as shown in Figure 227 3. 229 3.2.2. AMT Tunnel Connecting S-CDN and EU 231 ------------------- ------------------- 232 / P-CDN \ / S-CDN \ 233 / (Multicast Enabled) \ / (Multicast Enabled) \ 234 / \ / \ 235 | +----+ | | | 236 | | | +------+ | | +------+ +------+ | +----+ 237 | | CS |------>| BR |-|---------|->| BR |--->| AR |-|--->| EU | 238 | | | +------+ | I1 | +------+ +------+ | I2 +----+ 239 \ +----+ / \ / 240 \ / \ / 241 \ / \ / 242 ------------------- ------------------- 244 CS = Content Server 245 BR = Border Router 246 AR = AMT Relay 247 I1 = P-CDN and S-CDN Multicast Interconnection (MBGP or BGMP) 248 I2 = AMT Connection between S-CDN and EU 250 Figure 4 - AMT Tunnel Connecting S-CDN and EU 252 This case involves EU devices that are not multicast enabled. Hence 253 an AMT Tunnel is established between the S-CDN AMT Relay and the EU 254 device. This implies one tunnel per EU - potentially several AMT 255 tunnels may need to be setup. 256 Note that there could be configurations involving both situations 257 described in 3.2.1 and 3.2.2. 259 3.2.3. AMT Tunnel Connecting EU to P-CDN Through Non-Multicast S-CDN 261 This Use Case assumes that EU attached to the non-multicast enabled 262 S-CDN has a device populated with a client that establishes an AMT 263 tunnel to the AMT Relay in the P-CDN. 265 This configuration is needed when the S-CDN is not multicast-enabled. 266 This is the most "extreme" AMT case as the length of the tunnels as 267 well as the number of tunnels can be large. 269 ------------------- ------------------- 270 / P-CDN \ / S-CDN \ 271 / (Multicast Enabled) \ / (Non-Multicast \ 272 / \ / Enabled) \ 273 | +----+ | | | 274 | | | +------+ | | | +----+ 275 | | CS |------>| AR |-|---------|-----------------------|--->| EU | 276 | | | +------+ | | | I2 +----+ 277 \ +----+ / \ / 278 \ / \ / 279 \ / \ / 280 ------------------- ------------------- 282 CS = Content Source 283 AR = AMT Relay 284 I2 = AMT Tunnel Connecting EU to P-CDN Relay through Non-Multicast 285 Enabled S-CDN. 287 Figure 5 - AMT Tunnel Connecting P-CDN AMT Relay and EU 289 4. Content Types Suitable for Multicast-based CDN 291 This section highlights applications and content types that are 292 suitable for multicast-based delivery in a CDN Federation. Any unique 293 aspects of specific applications/content types that require special 294 attention are duly noted. 296 4.1. Live Content 298 Live events and presentations such as live radio an sporting events 299 are examples. Delivery is via simple multicast means. 301 Additional detail TBD 303 4.2. "Delayed-Play" Download 305 This includes download of movies and software updates. Delivery is 306 via repeated multicasting of content. 308 Additional detail TBD 310 4.3. "Instant-Play" Download 312 This includes Video-on-Demand (VoD) and on-demand streaming. Delivery 313 is via simultaneous repeated multicast of content segments. 315 Additional detail TBD 317 5. Evaluation of Native Multicast for CDN 319 Use Case 3.1 describes Native Multicast configurations. This is the 320 "simplest" multicast case in that a single standard set of protocols 321 supports end-to-end content delivery from the CP to EU via two or 322 more fully multicast-enabled CDN Providers. It also provides for 323 efficient use of bandwidth and resources. 325 Use Case 2a does deploy an AMT Tunnel for interconnecting two CDN 326 Providers; the rest of the configuration is Native Multicast - this 327 assumes that the EU devices are also multicast-enabled. 329 Thus existing Native Multicast capabilities need to be examined to 330 determine their ability to fully support content distribution in a 331 CDN Federation. A list of issues requiring examination is as follows: 333 o Delivery - Identification and communication of {Source, Group} 334 information and DNS information for provisioning across CDNs. 335 Details to be provided. 337 o Routing/Peering - Identification and acknowledgement of external 338 IP addresses particularly when utilizing a GRE Tunnel for 339 interconnecting CDNs. Details to be provided. 341 o Back-Office Functions - Identification of appropriate 342 data/metadata collected by Native Multicast to support usage of 343 content for billing, settlements, logging, etc. Details to be 344 provided. 346 o Security - Determine ability of Native Multicast to deal with 347 security risks such as bot attacks, denial of service, etc. 348 Details to be provided. 350 o Others - To Be Determined 352 6. Evaluation of AMT for CDN 354 Use Cases 3.2.1, 3.2.2, and 3.2.3 describe the possible 355 configurations involving AMT Tunnels. The likeliest scenario is a 356 combination of Use Cases 3.2.1 and 3.2.2. 358 Use Case 3.2.3 becomes problematic if the length of the AMT Tunnels 359 connecting the EUs to the P-CDN AMT Gateway become prohibitively 360 long. 362 In all cases, there may be a concern if the total number of AMT 363 Tunnels required is large. The list of issues that need to be 364 examined for the AMT scenarios to support content distribution in a 365 CDN Federation includes all identified issues in the Native Multicast 366 case: 368 o Delivery - Identification and communication of {Source, Group} 369 information and DNS information for provisioning across CDNs. 370 Details to be provided. 372 o Routing/Peering - Identification and acknowledgement of external 373 IP addresses when utilizing AMT Tunnels for interconnecting CDNs. 374 Details to be provided. 376 o Back-Office Functions - Identification of appropriate 377 data/metadata collected via AMT to support usage of content for 378 billing, settlements, logging, etc. Details to be provided. 380 o Security - Determine ability of AMT to deal with security risks 381 such as bot attacks, denial of service, etc. Details to be 382 provided. 384 o Others - To Be Determined 386 These have to be separately investigated for the AMT cases. 387 In addition, there may be a need to examine the scope of additional 388 resources in terms of bandwidth capacity and additional network 389 elements particularly for Use Cases 3.2.2 and 3.2.3. 391 7. Security Considerations 393 TBD 395 8. IANA Considerations 397 TBD 399 9. Conclusions 401 TBD 402 10. References 404 10.1. Normative References 406 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 407 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 409 [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- 410 ietf-mboned-auto-multicast-13, April 2012, Work in progress 412 10.2. Informative References 414 [A-0200003] P. Tarapore, "CDN Interconnection Use Case Specifications 415 and High Level Requirements", ATIS Standard A-0200003, June 2011 416 (contact Nicole Butler at nbutler@atis.org using code IETF12 to 417 receive a free copy before September 30, 2012) 419 [A-0200004] P. Tarapore and R. Sayko, "CDN Interconnection Use Cases 420 and Requirements for Multicast-Based Content Distribution", ATIS 421 Standard A-0200004, January 2012 (contact Nicole Butler at 422 nbutler@atis.org using code IETF12 to receive a free copy before 423 September 30, 2012) 425 11. Acknowledgments 426 Authors' Addresses 428 Percy S. Tarapore 429 AT&T 430 Phone: 1-732-420-4172 431 Email: tarapore@att.com 433 Robert Sayko 434 AT&T 435 Phone: 1-732-420-3292 436 Email: rs1983@att.com 438 Ram Krishnan 439 Brocade 440 Phone: 441 Email: ramk@brocade.com