idnits 2.17.1 draft-tarapore-mboned-multicast-cdni-05.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: ' 2. Overview of Inter-domain Multicast Application Transport' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. 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: ' 6. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 118 has weird spacing: '...Catalog all ...' == Line 245 has weird spacing: '...network envi...' == Line 258 has weird spacing: '... Users in A...' == Line 311 has weird spacing: '... f. It is r...' == Line 314 has weird spacing: '... entire netwo...' == (4 more instances...) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2014) is 3707 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? 'RFC4607' on line 849 looks like a reference -- Missing reference section? 'RFC4604' on line 844 looks like a reference -- Missing reference section? 'RFC2784' on line 838 looks like a reference -- Missing reference section? 'IETF-ID-AMT' on line 841 looks like a reference -- Missing reference section? 'RFC2236' on line 669 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 6 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: August 3, 2014 Greg Shepherd 5 Toerless Eckert 6 Cisco 7 Ram Krishnan 8 Brocade 9 March 3, 2014 11 Multicasting Applications Across Inter-Domain Peering Points 12 draft-tarapore-mboned-multicast-cdni-05.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on August 3, 2014. 31 Copyright Notice 33 Copyright (c) 2014 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with 41 respect to this document. Code Components extracted from this 42 document must include Simplified BSD License text as described in 43 Section 4.e of the Trust Legal Provisions and are provided without 44 warranty as described in the Simplified BSD License. 46 IETF I-D Multicasting Applications Across Peering Points February 2014 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Abstract 62 This document examines the process of transporting applications via 63 multicast across inter-domain peering points. The objective is to 64 describe the setup process for multicast-based delivery across 65 administrative domains and document supporting functionality to 66 enable this process. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Overview of Inter-domain Multicast Application Transport.......3 72 3. Inter-domain Peering Point Requirements for Multicast..........5 73 3.1. Native Multicast..........................................5 74 3.2. Peering Point Enabled with GRE Tunnel.....................6 75 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 76 Enabled........................................................8 77 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 78 Enabled........................................................9 79 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through 80 AD-2..........................................................11 81 4. Supporting Functionality......................................13 82 4.1. Network Interconnection Transport and Security Guidelines14 83 4.2. Routing Aspects and Related Guidelines...................15 84 4.2.1 Native Multicast Routing Aspects..................15 85 4.2.2 GRE Tunnel over Interconnecting Peering Point.....16 86 4.2.3 Routing Aspects with AMT Tunnels.....................16 87 4.3. Back Office Functions - Billing and Logging Guidelines...19 88 4.4. Operations - Service Performance and Monitoring Guidelines19 89 4.5. Reliability Models/Service Assurance Guidelines..........19 90 4.6. Provisioning Guidelines..................................19 91 4.7. Client Models............................................19 92 4.8. Addressing Guidelines....................................19 93 5. Security Considerations.......................................19 95 IETF I-D Multicasting Applications Across Peering Points February 2014 97 6. IANA Considerations...........................................20 98 7. Conclusions...................................................20 99 8. References....................................................20 100 8.1. Normative References.....................................20 101 8.2. Informative References...................................20 102 9. Acknowledgments...............................................20 104 1. Introduction 106 Several types of applications (e.g., live video streaming, software 107 downloads) are well suited for delivery via multicast means. The use 108 of multicast for delivering such applications offers significant 109 savings for utilization of resources in any given administrative 110 domain. End user demand for such applications is growing. Often, 111 this requires transporting such applications across administrative 112 domains via inter-domain peering points. 114 The objective of this Best Current Practices document is twofold: 115 o Describe the process and establish guidelines for setting up 116 multicast-based delivery of applications across inter-domain 117 peering points, and 118 o Catalog all required information exchange between the 119 administrative domains to support multicast-based delivery. 121 While there are several multicast protocols available for use, this 122 BCP will focus the discussion to those that are applicable and 123 recommended for the peering requirements of today's service model, 124 including: 126 o Protocol Independent Multicast - Source Specific Multicast 127 (PIM-SSM) [RFC4607] 128 o Internet Group Management Protocol (IGMP) v3 [RFC4604] 129 o Multicast Listener Discovery (MLD) [RFC4604] 131 This document therefore serves the purpose of a "Gap Analysis" 132 exercise for this process. The rectification of any gaps identified 133 - whether they involve protocol extension development or otherwise - 134 is beyond the scope of this document and is for further study. 136 2. Overview of Inter-domain Multicast Application Transport 138 A multicast-based application delivery scenario is as follows: 140 IETF I-D Multicasting Applications Across Peering Points February 2014 142 o Two independent administrative domains are interconnected via a 143 peering point. 144 o The peering point is either multicast enabled (end-to-end 145 native multicast across the two domains) or it is connected by 146 one of two possible tunnel types: 147 o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] 148 allowing multicast tunneling across the peering point, or 149 o An Automatic Multicast Tunnel (AMT) [IETF-ID-AMT]. 150 o The application stream originates at a source in Domain 1. 151 o An End User associated with Domain 2 requests the application. 152 It is assumed that the application is suitable for delivery via 153 multicast means (e.g., live steaming of major events, software 154 downloads to large numbers of end user devices, etc.) 155 o The request is communicated to the application source which 156 provides the relevant multicast delivery information to the EU 157 device via a "manifest file". At a minimum, this file contains 158 the {Source, Group} or (S,G) information relevant to the 159 multicast stream. 160 o The application client in the EU device then joins the 161 multicast stream distributed by the application source in 162 domain 1 utilizing the (S,G) information provided in the 163 manifest file. The manifest file may also contain additional 164 information that the application client can use to locate the 165 source and join the stream. 167 It should be noted that the second administrative domain - domain 2 168 - may be an independent network domain (e.g., Tier 1 network 169 operator domain) or it could also be an Enterprise network operated 170 by a single customer. The peering point architecture and 171 requirements may have some unique aspects associated with the 172 Enterprise case. 174 The Use Cases describing various architectural configurations for 175 the multicast distribution along with associated requirements is 176 described in section 3. Unique aspects related to the Enterprise 177 network possibility will be described in this section. A 178 comprehensive list of pertinent information that needs to be 179 exchanged between the two domains to support various functions 180 enabling the application transport is provided in section 4. 182 IETF I-D Multicasting Applications Across Peering Points February 2014 184 3. Inter-domain Peering Point Requirements for Multicast 186 The transport of applications using multicast requires that the 187 inter-domain peering point is enabled to support such a process. 188 There are three possible Use Cases for consideration. 190 3.1. Native Multicast 192 This Use Case involves end-to-end Native Multicast between the two 193 administrative domains and the peering point is also native 194 multicast enabled - Figure 1. 196 ------------------- ------------------- 197 / AD-1 \ / AD-2 \ 198 / (Multicast Enabled) \ / (Multicast Enabled) \ 199 / \ / \ 200 | +----+ | | | 201 | | | +------+ | | +------+ | +----+ 202 | | CS |------>| BR |-|---------|->| BR |-------------|-->| EU | 203 | | | +------+ | I1 | +------+ |I2 +----+ 204 \ +----+ / \ / 205 \ / \ / 206 \ / \ / 207 ------------------- ------------------- 209 AD = Administrative Domain (Independent Autonomous System) 210 CS = Content Multicast Source 211 BR = Border Router 212 I1 = AD-1 and AD-2 Multicast Interconnection (MBGP or BGMP) 213 I2 = AD-2 and EU Multicast Connection 215 Figure 1 - Content Distribution via End to End Native Multicast 217 Advantages of this configuration are: 219 o Most efficient use of bandwidth in both domains 221 o Fewer devices in the path traversed by the multicast stream 222 when compared to unicast transmissions. 224 From the perspective of AD-1, the one disadvantage associated with 225 native multicast into AD-2 instead of individual unicast to every EU 227 IETF I-D Multicasting Applications Across Peering Points February 2014 229 in AD-2 is that it does not have the ability to count the number of 230 End Users as well as the transmitted bytes delivered to them. This 231 information is relevant from the perspective of customer billing and 232 operational logs. It is assumed that such data will be collected by 233 the application layer. The application layer mechanisms for 234 generating this information need to be robust enough such that all 235 pertinent requirements for the source provider and the AD operator 236 are satisfactorily met. The specifics of these methods are beyond 237 the scope of this document. 239 Architectural guidelines for this configuration are as follows: 241 a. Dual homing for peering points between domains is recommended 242 as a way to ensure reliability with full BGP table visibility. 244 b. If the peering point between AD-1 and AD-2 is a controlled 245 network environment, then bandwidth can be allocated 246 accordingly by the two domains to permit the transit of non- 247 rate adaptive multicast traffic. If this is not the case, then 248 it is recommended that the multicast traffic should support 249 rate-adaption. 251 c. The sending and receiving of multicast traffic between two 252 domains is typically determined by local policies associated 253 with each domain. For example, if AD-1 is a service provider 254 and AD-2 is an enterprise, then AD-1 may support local policies 255 for traffic delivery to, but not traffic reception from AD-2. 257 d. Relevant information on multicast streams delivered to End 258 Users in AD-2 is assumed to be collected by available 259 capabilities in the application layer. The precise nature and 260 formats of the collected information will be determined by 261 directives from the source owner and the domain operators. 263 3.2. Peering Point Enabled with GRE Tunnel 265 The peering point is not native multicast enabled in this Use Case. 266 There is a Generic Routing Encapsulation Tunnel provisioned over the 267 peering point. In this case, the interconnection I1 between AD-1 and 268 AD-2 in Figure 1 is multicast enabled via a Generic Routing 269 Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast 270 protocols across the interface. The routing configuration is 271 basically unchanged: Instead of BGP (SAFI2) across the native IP 273 IETF I-D Multicasting Applications Across Peering Points February 2014 275 multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across 276 the GRE tunnel. 278 Advantages of this configuration: 280 o Highly efficient use of bandwidth in both domains although not 281 as efficient as the fully native multicast Use Case. 283 o Fewer devices in the path traversed by the multicast stream 284 when compared to unicast transmissions. 286 o Ability to support only partial IP multicast deployments in AD- 287 1 and/or AD-2. 289 o GRE is an existing technology and is relatively simple to 290 implement. 292 Disadvantages of this configuration: 294 o Per Use Case 3.1, current router technology cannot count the 295 number of end users or the number bytes transmitted. 297 o GRE tunnel requires manual configuration. 299 o GRE must be in place prior to stream starting. 301 o GRE is often left pinned up 303 Architectural guidelines for this configuration include the 304 following: 306 Guidelines (a) through (d) are the same as those described in Use 307 Case 3.1. 309 e. GRE tunnels are typically configured manually between peering 310 points to support multicast delivery between domains. 311 f. It is recommended that the GRE tunnel (tunnel server) 312 configuration in the source network is such that it only 313 advertises the routes to the content sources and not to the 314 entire network. This practice will prevent unauthorized 315 delivery of content through the tunnel (e.g., if content is not 316 part of an agreed CDN partnership). 318 IETF I-D Multicasting Applications Across Peering Points February 2014 320 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 321 Enabled 323 Both administrative domains in this Use Case are assumed to be 324 native multicast enabled here; however the peering point is not. The 325 peering point is enabled with an Automatic Multicast Tunnel. The 326 basic configuration is depicted in Figure 2. 328 ------------------- ------------------- 329 / AD-1 \ / AD-2 \ 330 / (Multicast Enabled) \ / (Multicast Enabled) \ 331 / \ / \ 332 | +----+ | | | 333 | | | +------+ | | +------+ | +----+ 334 | | CS |------>| AR |-|---------|->| AG |-------------|-->| EU | 335 | | | +------+ | I1 | +------+ |I2 +----+ 336 \ +----+ / \ / 337 \ / \ / 338 \ / \ / 339 ------------------- ------------------- 341 AR = AMT Relay 342 AG = AMT Gateway 343 I1 = AMT Interconnection between P-CDN and S-CDN 344 I2 = S-CDN and EU Multicast Connection 346 Figure 2 - AMT Interconnection between AD-1 and AD-2 348 Advantages of this configuration: 350 o Highly efficient use of bandwidth in AD-1. 352 o AMT is an existing technology and is relatively simple to 353 implement. Attractive properties of AMT include the following: 355 o Dynamic interconnection between Gateway-Relay pair across 356 the peering point. 358 o Ability to serve clients and servers with differing 359 policies. 361 Disadvantages of this configuration: 363 IETF I-D Multicasting Applications Across Peering Points February 2014 365 o Per Use Case 3.1 (AD-2 is native multicast), current router 366 technology cannot count the number of end users or the number 367 bytes transmitted. 369 o Additional devices (AMT Gateway and Relay pairs) may be 370 introduced into the path if these services are not incorporated 371 in the existing routing nodes. 373 o Currently undefined mechanisms to select the AR from the AG 374 automatically. 376 Architectural guidelines for this configuration are as follows: 378 Guidelines (a) through (d) are the same as those described in Use 379 Case 3.1. 381 e. It is recommended that AMT Relay and Gateway pairs be 382 configured at the peering points to support multicast delivery 383 between domains. AMT tunnels will then configure dynamically 384 across the peering points once the Gateway in AD-2 receives the 385 (S, G) information from the EU. 387 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 389 In this AMT Use Case, the second administrative domain AD-2 is not 390 multicast enabled. This implies that the interconnection between AD- 391 2 and the End User is also not multicast enabled as depicted in 392 Figure 3. 394 IETF I-D Multicasting Applications Across Peering Points February 2014 396 ------------------- ------------------- 397 / AD-1 \ / AD-2 \ 398 / (Multicast Enabled) \ / (Non-Multicast \ 399 / \ / Enabled) \ 400 | +----+ | | | 401 | | | +------+ | | | +----+ 402 | | CS |------>| AR |-|---------|-----------------------|-->|EU/G| 403 | | | +------+ | | |I2 +----+ 404 \ +----+ / \ / 405 \ / \ / 406 \ / \ / 407 ------------------- ------------------- 409 CS = Content Source 410 AR = AMT Relay 411 EU/G = Gateway client embedded in EU device 412 I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast 413 Enabled AD-2. 415 Figure 3 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 417 This Use Case is equivalent to having unicast distribution of the 418 application through AD-2. The total number of AMT tunnels would be 419 equal to the total number of End Users requesting the application. 420 The peering point thus needs to accommodate the total number of AMT 421 tunnels between the two domains. Each AMT tunnel can provide the 422 data usage associated with each End User. 424 Advantages of this configuration: 426 o Highly efficient use of bandwidth in AD-1. 428 o AMT is an existing technology and is relatively simple to 429 implement. Attractive properties of AMT include the following: 431 o Dynamic interconnection between Gateway-Relay pair across 432 the peering point. 434 o Ability to serve clients and servers with differing 435 policies. 437 o Each AMT tunnel serves as a count for each End User and is also 438 able to track data usage (bytes) delivered to the EU. 440 IETF I-D Multicasting Applications Across Peering Points February 2014 442 Disadvantages of this configuration: 444 o Additional devices (AMT Gateway and Relay pairs) are introduced 445 into the transport path. 447 o Assuming multiple peering points between the domains, the EU 448 Gateway needs to be able to find the "correct" AMT Relay in AD- 449 1. 451 Architectural guidelines for this configuration are as follows: 453 Guidelines (a) through (c) are the same as those described in Use 454 Case 3.1. 456 d. It is recommended that proper procedures are implemented such 457 that the AMT Gateway at the End User device is able to find the 458 correct AMT Relay in AD-1 across the peering points. The 459 application client in the EU device is expected to supply the (S, 460 G) information to the Gateway for this purpose. 462 e. The AMT tunnel capabilities are expected to be sufficient for 463 the purpose of collecting relevant information on the multicast 464 streams delivered to End Users in AD-2. 466 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 468 This is a variation of Use Case 3.4 as follows: 470 IETF I-D Multicasting Applications Across Peering Points February 2014 472 ------------------- ------------------- 473 / AD-1 \ / AD-2 \ 474 / (Multicast Enabled) \ / (Non-Multicast \ 475 / \ / Enabled) \ 476 | +----+ | |+--+ +--+ | 477 | | | +------+ | ||AG| |AG| | +----+ 478 | | CS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| 479 | | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ 480 \ +----+ / \+--+ +--+ / 481 \ / \ / 482 \ / \ / 483 ------------------- ------------------- 485 (Note: Diff-marks for the figure have been removed to improve 486 viewing) 488 CS = Content Source 489 AR = AMT Relay in AD-1 490 AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point 491 I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 492 AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge 493 I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 494 EU/G = Gateway client embedded in EU device 495 I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 497 Figure 4 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 499 Use Case 3.4 results in several long AMT tunnels crossing the entire 500 network of AD-2 linking the EU device and the AMT Relay in AD-1 501 through the peering point. Depending on the number of End Users, 502 there is a likelihood of an unacceptably large number of AMT tunnels 503 - and unicast streams - through the peering point. This situation 504 can be alleviated as follows: 506 o Provisioning of strategically located AMT nodes at the edges of 507 AD-2. An AMT node comprises co-location of an AMT Gateway and 508 an AMT Relay. One such node is at the AD-2 side of the peering 509 point (node AGAR1 in Figure 4). 511 o Single AMT tunnel established across peering point linking AMT 512 Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. 514 o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to 515 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel 517 IETF I-D Multicasting Applications Across Peering Points February 2014 519 I2 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 520 in Figure 4. 522 o AMT tunnels linking EU device (via Gateway client embedded in 523 device) and AMT Relay in appropriate AMT node at edge of AD-2: 524 e.g., I3 linking EU Gateway in device to AMT Relay in AMT node 525 AGAR2. 527 The advantage for such a chained set of AMT tunnels is that the 528 total number of unicast streams across AD-2 is significantly reduced 529 thus freeing up bandwidth. Additionally, there will be a single 530 unicast stream across the peering point instead of possibly, an 531 unacceptably large number of such streams per Use Case 3.4. However, 532 this implies that several AMT tunnels will need to be dynamically 533 configured by the various AMT Gateways based solely on the (S,G) 534 information received from the application client at the EU device. A 535 suitable mechanism for such dynamic configurations is therefore 536 critical. 538 Architectural guidelines for this configuration are as follows: 540 Guidelines (a) through (c) are the same as those described in Use 541 Case 3.1. 543 d. It is recommended that proper procedures are implemented such 544 that the various AMT Gateways (at the End User devices and the AMT 545 nodes in AD-2) are able to find the correct AMT Relay in other AMT 546 nodes as appropriate. The application client in the EU device is 547 expected to supply the (S, G) information to the Gateway for this 548 purpose. 550 e. The AMT tunnel capabilities are expected to be sufficient for 551 the purpose of collecting relevant information on the multicast 552 streams delivered to End Users in AD-2. 554 4. Supporting Functionality 556 Supporting functions and related interfaces over the peering point 557 that enable the multicast transport of the application are listed in 558 this section. Critical information parameters that need to be 559 exchanged in support of these functions are enumerated along with 560 guidelines as appropriate. Specific interface functions for 561 consideration are as follows. 563 IETF I-D Multicasting Applications Across Peering Points February 2014 565 4.1. Network Interconnection Transport and Security Guidelines 567 The term "Network Interconnection Transport" refers to the 568 interconnection points between the two Administrative Domains. The 569 following is a representative set of attributes that will need to be 570 agreed to between the two administrative domains to support 571 multicast delivery. 573 o Number of Peering Points 575 o Peering Point Addresses and Locations 577 o Connection Type - Dedicated for Multicast delivery or shared 578 with other services 580 o Connection Mode - Direct connectivity between the two AD's or 581 via another ISP 583 o Peering Point Protocol Support - Multicast protocols that will 584 be used for multicast delivery will need to be supported at 585 these points. Examples of protocols include eBGP, BGMP, and 586 MBGP. 588 o Bandwidth Allocation - If shared with other services, then 589 there needs to be a determination of the share of bandwidth 590 reserved for multicast delivery. 592 o QoS Requirements - Delay/latency specifications that need to be 593 specified in an SLA. 595 o AD Roles and Responsibilities - the role played by each AD for 596 provisioning and maintaining the set of peering points to 597 support multicast delivery. 599 From a security perspective, it is expected that normal/typical 600 security procedures will be followed by each AD to facilitate 601 multicast delivery to registered and authenticated end users. Some 602 security aspects for consideration are: 604 o Encryption - Peering point links may be encrypted per agreement 605 if dedicated for multicast delivery. 607 o Security Breach Mitigation Plan - In the event of a security 608 breach, the two AD's are expected to have a mitigation plan for 609 shutting down the peering point and directing multicast traffic 611 IETF I-D Multicasting Applications Across Peering Points February 2014 613 over alternated peering points. It is also expected that 614 appropriate information will be shared for the purpose of 615 securing the identified breach. 617 4.2. Routing Aspects and Related Guidelines 619 The main objective for multicast delivery routing is to ensure that 620 the End User receives the multicast stream from the "most optimal" 621 source [INF_ATIS_10] which typically: 623 o Maximizes the multicast portion of the transport and minimizes 624 any unicast portion of the delivery, and 626 o Minimizes the overall combined network(s) route distance. 628 This routing objective applies to both Native and AMT; the actual 629 methodology of the solution will be different for each. Regardless, 630 the routing solution is expected to be: 632 o Scalable 634 o Avoid/minimize new protocol development or modifications, and 636 o Be robust enough to achieve high reliability and automatically 637 adjust to changes/problems in the multicast infrastructure. 639 For both Native and AMT environments, having a source as close as 640 possible to the EU network is most desirable; therefore, in some 641 cases, an AD may prefer to have multiple sources near different 642 peering points, but that is entirely an implementation issue. 644 4.2.1 Native Multicast Routing Aspects 646 Native multicast simply requires that the Administrative Domains 647 coordinate and advertise the correct source address(es) at their 648 network interconnection peering points(i.e., border routers). An 649 example of multicast delivery via a Native Multicast process across 650 two administrative Domains is as follows assuming that the 651 interconnecting peering points are also multicast enabled: 653 o Appropriate information is obtained by the EU client who is a 654 subscriber to AD-2 (see Use Case 3.1). This is usually done via 655 an appropriate file transfer - this file is typically known as 656 the manifest file. It contains instructions directing the EU 658 IETF I-D Multicasting Applications Across Peering Points February 2014 660 client to launch an appropriate application if necessary, and 661 also additional information for the application about the source 662 location and the group (or stream) id in the form of the "S,G" 663 data. The "S" portion provides the name or IP address of the 664 source of the multicast stream. The file may also contain 665 alternate delivery information such as specifying the unicast 666 address of the stream. 668 o The client uses the join message with S,G to join the multicast 669 stream [RFC2236]. 671 To facilitate this process, the two AD's need to do the following: 673 o Advertise the source id(s) over the Peering Points 675 o Exchange relevant Peering Point information such as Capacity 676 and Utilization (Other??) 678 4.2.2 GRE Tunnel over Interconnecting Peering Point 680 If the interconnecting peering point is not multicast enabled and 681 both ADs are multicast enabled, then a simple solution is to 682 provision a GRE tunnel between the two ADs - see Use Case 3.2.2. 683 The termination points of the tunnel will usually be a network 684 engineering decision, but generally will be between the border 685 routers or even between the AD 2 border router and the AD 1 source 686 (or source access router). The GRE tunnel would allow end-to-end 687 native multicast or AMT multicast to traverse the interface. 688 Coordination and advertisement of the source IP is still required. 690 The two AD's need to follow the same process as described in 4.2.1 691 to facilitate multicast delivery across the Peering Points. 693 4.2.3 Routing Aspects with AMT Tunnels 695 Unlike Native (with or without GRE), an AMT Multicast environment is 696 more complex. It presents a dual layered problem because there are 697 two criteria that should be simultaneously meet: 699 o Find the closest AMT relay to the end-user that also has 700 multicast connectivity to the content source and 702 o Minimize the AMT unicast tunnel distance. 704 There are essentially two components to the AMT specification: 706 IETF I-D Multicasting Applications Across Peering Points February 2014 708 o AMT Relays: These serve the purpose of tunneling UDP multicast 709 traffic to the receivers (i.e., End Points). The AMT Relay will 710 receive the traffic natively from the multicast media source and 711 will replicate the stream on behalf of the downstream AMT 712 Gateways, encapsulating the multicast packets into unicast 713 packets and sending them over the tunnel toward the AMT Gateway. 714 In addition, the AMT Relay may perform various usage and 715 activity statistics collection. This results in moving the 716 replication point closer to the end user, and cuts down on 717 traffic across the network. Thus, the linear costs of adding 718 unicast subscribers can be avoided. However, unicast replication 719 is still required for each requesting endpoint within the 720 unicast-only network. 722 o AMT Gateway (GW): The Gateway will reside on an on End-Point - 723 this may be a Personal Computer (PC) or a Set Top Box (STB). The 724 AMT Gateway receives join and leave requests from the 725 Application via an Application Programming Interface (API). In 726 this manner, the Gateway allows the endpoint to conduct itself 727 as a true Multicast End-Point. The AMT Gateway will encapsulate 728 AMT messages into UDP packets and send them through a tunnel 729 (across the unicast-only infrastructure) to the AMT Relay. 731 The simplest AMT Use Case (section 3.3) involves peering points that 732 are not multicast enabled between two multicast enabled ADs. An AMT 733 tunnel is deployed between an AMT Relay on the AD 1 side of the 734 peering point and an AMT Gateway on the AD 2 side of the peering 735 point. One advantage to this arrangement is that the tunnel is 736 established on an as needed basis and need not be a provisioned 737 element. The two ADs can coordinate and advertise special AMT Relay 738 Anycast addresses with each other - though they may alternately 739 decide to simply provision Relay addresses, though this would not be 740 a optimal solution in terms of scalability. 742 Use Cases 3.4 and 3.5 describe more complicated AMT situations as 743 AD-2 is not multicast enabled. For these cases, the End User device 744 needs to be able to setup an AMT tunnel in the most optimal manner. 745 Using an Anycast IP address for AMT Relays allows for all AMT 746 Gateways to find the "closest" AMT Relay - the nearest edge of the 747 multicast topology of the source. An example of a basic delivery 748 via an AMT Multicast process for these two Use Cases is as follows: 750 o The manifest file is obtained by the EU client application. This 751 file contains instructions directing the EU client to an ordered 752 list of particular destinations to seek the requested stream and, 753 for multicast, specifies the source location and the group (or 754 stream) ID in the form of the "S,G" data. The "S" portion provides 756 IETF I-D Multicasting Applications Across Peering Points February 2014 758 the URI (name or IP address) of the source of the multicast stream 759 and the "G" identifies the particular stream originated by that 760 source. The manifest file may also contain alternate delivery 761 information such as the address of the unicast form of the content 762 to be used, for example, if the multicast stream becomes 763 unavailable. 765 o Using the information in the manifest file, and possibly 766 information provisioned directly in the EU client, a DNS query is 767 initiated in order to connect the EU client/AMT Gateway to an AMT 768 Relay. 770 o Query results are obtained, and may return an Anycast address or a 771 specific unicast address of a relay. Multiple relays will 772 typically exist. The Anycast address is a routable "pseudo- 773 address" shared among the relays that can gain multicast access to 774 the source. 776 o If a specific IP address unique to a relay was not obtained, the 777 AMT Gateway then sends a message (e.g., the discovery message) to 778 the Anycast address such that the network is making the routing 779 choice of particular relay - e.g., closest relay to the EU. (Note 780 that in IPv6 there is a specific Anycast format and Anycast is 781 inherent in IPv6 routing, whereas in IPv4 Anycast is handled via 782 provisioning in the network. Details are out of scope for this 783 document.) 785 o The contacted AMT Relay then returns its specific unicast IP 786 address (after which the Anycast address is no longer required). 787 Variations may exist as well. 789 o The AMT Gateway uses that unicast IP address to initiate a three- 790 way handshake with the AMT Relay. 792 o AMT Gateway provides "S,G" to the AMT Relay (embedded in AMT 793 protocol messages). 795 o AMT Relay receives the "S,G" information and uses the S,G to join 796 the appropriate multicast stream, if it has not already subscribed 797 to that stream. 799 o AMT Relay encapsulates the multicast stream into the tunnel 800 between the Relay and the Gateway, providing the requested content 801 to the EU. 803 IETF I-D Multicasting Applications Across Peering Points February 2014 805 Note: Further routing discussion on optimal method to find "best AMT 806 Relay/GW combination" and information exchange between AD's to be 807 provided. 809 4.3. Back Office Functions - Billing and Logging Guidelines 811 4.4. Operations - Service Performance and Monitoring Guidelines 813 4.5. Reliability Models/Service Assurance Guidelines 815 4.6. Provisioning Guidelines 817 In order to find right relay there is a need for a small/light 818 implementation of an AMT DNS in source network. 820 4.7. Client Models 822 4.8. Addressing Guidelines 824 5. Security Considerations 826 (Include discussion on DRM, AAA, Network Security) 828 IETF I-D Multicasting Applications Across Peering Points February 2014 830 6. IANA Considerations 832 7. Conclusions 834 8. References 836 8.1. Normative References 838 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 839 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 841 [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- 842 ietf-mboned-auto-multicast-13, April 2012, Work in progress 844 [RFC4604] H. Holbrook, et al, "Using Internet Group Management 845 Protocol Version 3 (IGMPv3) and Multicast Listener Discovery 846 Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, 847 August 2006 849 [RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607, 850 August 2006 852 8.2. Informative References 854 [INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a 855 Multi-Party Federation Environment", ATIS Standard A-0200010, 856 December 2012 858 9. Acknowledgments 860 IETF I-D Multicasting Applications Across Peering Points February 2014 862 Authors' Addresses 864 Percy S. Tarapore 865 AT&T 866 Phone: 1-732-420-4172 867 Email: tarapore@att.com 869 Robert Sayko 870 AT&T 871 Phone: 1-732-420-3292 872 Email: rs1983@att.com 874 Greg Shepherd 875 Cisco 876 Phone: 877 Email: shep@cisco.com 879 Toerless Eckert 880 Cisco 881 Phone: 882 Email: eckert@cisco.com 884 Ram Krishnan 885 Brocade 886 Phone: 887 Email: ramk@brocade.com