idnits 2.17.1 draft-ietf-mboned-interdomain-peering-bcp-10.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 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 (August 9, 2017) is 2451 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) ** Downref: Normative reference to an Informational RFC: RFC 4609 -- Possible downref: Non-RFC (?) normative reference: ref. 'BCP38' -- Possible downref: Non-RFC (?) normative reference: ref. 'BCP41' == Outdated reference: A later version (-05) exists of draft-ietf-mboned-mdh-04 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 3 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: February 9, 2018 Greg Shepherd 5 Cisco 6 Toerless Eckert 7 Futurewei Technologies 8 Ram Krishnan 9 SupportVectors 10 August 9, 2017 12 Use of Multicast Across Inter-Domain Peering Points 13 draft-ietf-mboned-interdomain-peering-bcp-10.txt 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on February 9, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with 42 respect to this document. Code Components extracted from this 43 document must include Simplified BSD License text as described in 44 Section 4.e of the Trust Legal Provisions and are provided without 45 warranty as described in the Simplified BSD License. 47 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 This document examines the use of Source Specific Multicast (SSM) 64 across inter-domain peering points for a specified set of deployment 65 scenarios. The objective is to describe the setup process for 66 multicast-based delivery across administrative domains for these 67 scenarios and document supporting functionality to enable this 68 process. 70 Table of Contents 72 1. Introduction .................................................. 3 73 2. Overview of Inter-domain Multicast Application Transport ...... 4 74 3. Inter-domain Peering Point Requirements for Multicast ......... 6 75 3.1. Native Multicast ......................................... 6 76 3.2. Peering Point Enabled with GRE Tunnel .................... 8 77 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 78 Enabled ....................................................... 9 79 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 80 Enabled ...................................................... 10 81 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through 82 AD-2 ......................................................... 12 83 4. Supporting Functionality ..................................... 14 84 4.1. Network Interconnection Transport and Security Guidelines15 85 4.2. Routing Aspects and Related Guidelines .................. 15 86 4.2.1 Native Multicast Routing Aspects ................. 16 87 4.2.2 GRE Tunnel over Interconnecting Peering Point .... 17 88 4.2.3 Routing Aspects with AMT Tunnels .................... 17 89 4.3. Back Office Functions - Provisioning and Logging Guidelines 90 ............................................................. 19 91 4.3.1 Provisioning Guidelines .......................... 20 92 4.3.2 Application Accounting Guidelines ................ 21 93 4.3.3 Log Management Guidelines ........................ 22 94 4.4. Operations - Service Performance and Monitoring Guidelines22 96 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 98 4.5. Client Reliability Models/Service Assurance Guidelines .. 25 99 5. Troubleshooting and Diagnostics .............................. 25 100 6. Security Considerations ...................................... 26 101 7. IANA Considerations .......................................... 27 102 8. Conclusions .................................................. 27 103 9. References ................................................... 27 104 9.1. Normative References .................................... 27 105 9.2. Informative References .................................. 28 106 10. Acknowledgments ............................................. 29 108 1. Introduction 110 Content and data from several types of applications (e.g., live 111 video streaming, software downloads) are well suited for delivery 112 via multicast means. The use of multicast for delivering such 113 content/data offers significant savings of utilization of resources 114 in any given administrative domain. End user demand for such 115 content/data is growing. Often, this requires transporting the 116 content/data across administrative domains via inter-domain peering 117 points. 119 The objective of this Best Current Practices document is twofold: 120 o Describe the technical process and establish guidelines for 121 setting up multicast-based delivery of application content/data 122 across inter-domain peering points via a set of use cases. 123 o Catalog all required information exchange between the 124 administrative domains to support multicast-based delivery. 125 This enables operators to initiate necessary processes to 126 support inter-domain peering with multicast. 128 The scope and assumptions for this document are stated as follows: 130 o For the purpose of this document, the term "peering point" 131 refers to an interface between two networks/administrative 132 domains over which traffic is exchanged between them. A 133 Network-Network Interface (NNI) is an example of a peering 134 point. 135 o Administrative Domain 1 (AD-1) is enabled with native 136 multicast. A peering point exists between AD-1 and AD-2. 137 o It is understood that several protocols are available for this 138 purpose including PIM-SM [RFC4609], Protocol Independent 139 Multicast - Source Specific Multicast (PIM-SSM) [RFC7761], 140 Internet Group Management Protocol (IGMP) [RFC3376], and 141 Multicast Listener Discovery (MLD) [RFC3810]. 143 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 145 o As described in Section 2, the source IP address of the 146 multicast stream in the originating AD (AD-1) is known. Under 147 this condition, PIM-SSM use is beneficial as it allows the 148 receiver's upstream router to directly send a JOIN message to 149 the source without the need of invoking an intermediate 150 Rendezvous Point (RP). Use of SSM also presents an improved 151 threat mitigation profile against attack, as described in 152 [RFC4609]. Hence, in the case of inter-domain peering, it is 153 recommended to use only SSM protocols; the setup of inter- 154 domain peering for ASM (Any-Source Multicast) is not in scope 155 for this document. 156 o AD-1 and AD-2 are assumed to adopt compatible protocols. The 157 use of different protocols is beyond the scope of this 158 document. 159 o An Automatic Multicast Tunnel (AMT) [RFC7450] is setup at the 160 peering point if either the peering point or AD-2 is not 161 multicast enabled. It is assumed that an AMT Relay will be 162 available to a client for multicast delivery. The selection of 163 an optimal AMT relay by a client is out of scope for this 164 document. Note that AMT use is necessary only when native 165 multicast is unavailable in the peering point (Use Case 3.3) or 166 in the downstream administrative domain (Use Cases 3.4, and 167 3.5). 168 o The collection of billing data is assumed to be done at the 169 application level and is not considered to be a networking 170 issue. The settlements process for end user billing and/or 171 inter-provider billing is out of scope for this document. 172 o Inter-domain network connectivity troubleshooting is only 173 considered within the context of a cooperative process between 174 the two domains. 175 Thus, the primary purpose of this document is to describe a scenario 176 where two AD's interconnect via a direct connection to each other. 177 Security and operational aspects for exchanging traffic on a public 178 Internet Exchange Point (IXP) with a large shared broadcast domain 179 between many operators, is not in scope for this document. 181 This document also attempts to identify ways by which the peering 182 process can be improved. Development of new methods for improvement 183 is beyond the scope of this document. 185 2. Overview of Inter-domain Multicast Application Transport 187 A multicast-based application delivery scenario is as follows: 189 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 191 o Two independent administrative domains are interconnected via a 192 peering point. 193 o The peering point is either multicast enabled (end-to-end 194 native multicast across the two domains) or it is connected by 195 one of two possible tunnel types: 196 o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] 197 allowing multicast tunneling across the peering point, or 198 o An Automatic Multicast Tunnel (AMT) [RFC7450]. 199 o A service provider controls one or more application sources in 200 AD-1 which will send multicast IP packets for one or more 201 (S,G)s. It is assumed that the service being provided is 202 suitable for delivery via multicast (e.g. live video streaming 203 of popular events, software downloads to many devices, etc.), 204 and that the packet streams will be part of a suitable 205 multicast transport protocol. 206 o An End User (EU) controls a device connected to AD-2, which 207 runs an application client compatible with the service 208 provider's application source. 209 o The application client joins appropriate (S,G)s in order to 210 receive the data necessary to provide the service to the EU. 211 The mechanisms by which the application client learns the 212 appropriate (S,G)s are an implementation detail of the 213 application, and are out of scope for this document. 215 Note that domain 2 may be an independent network domain (e.g., Tier 216 1 network operator domain). Alternately, domain 2 could also be an 217 Enterprise network domain operated by a single customer. The peering 218 point architecture and requirements may have some unique aspects 219 associated with the Enterprise case. 221 The Use Cases describing various architectural configurations for 222 the multicast distribution along with associated requirements is 223 described in section 3. Unique aspects related to the Enterprise 224 network possibility will be described in this section. Section 4 225 contains a comprehensive list of pertinent information that needs to 226 be exchanged between the two domains in order to support functions 227 to enable the application transport. 229 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 231 3. Inter-domain Peering Point Requirements for Multicast 233 The transport of applications using multicast requires that the 234 inter-domain peering point is enabled to support such a process. 235 There are five Use Cases for consideration in this document. 237 3.1. Native Multicast 239 This Use Case involves end-to-end Native Multicast between the two 240 administrative domains and the peering point is also native 241 multicast enabled - Figure 1. 243 ------------------- ------------------- 244 / AD-1 \ / AD-2 \ 245 / (Multicast Enabled) \ / (Multicast Enabled) \ 246 / \ / \ 247 | +----+ | | | 248 | | | +------+ | | +------+ | +----+ 249 | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | 250 | | | +------+ | I1 | +------+ |I2 +----+ 251 \ +----+ / \ / 252 \ / \ / 253 \ / \ / 254 ------------------- ------------------- 256 AD = Administrative Domain (Independent Autonomous System) 257 AS = Application (e.g., Content) Multicast Source 258 BR = Border Router 259 I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) 260 I2 = AD-2 and EU Multicast Connection 262 Figure 1 - Content Distribution via End to End Native Multicast 264 Advantages of this configuration are: 266 o Most efficient use of bandwidth in both domains. 268 o Fewer devices in the path traversed by the multicast stream when 269 compared to unicast transmissions. 271 From the perspective of AD-1, the one disadvantage associated with 272 native multicast into AD-2 instead of individual unicast to every EU 274 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 276 in AD-2 is that it does not have the ability to count the number of 277 End Users as well as the transmitted bytes delivered to them. This 278 information is relevant from the perspective of customer billing and 279 operational logs. It is assumed that such data will be collected by 280 the application layer. The application layer mechanisms for 281 generating this information need to be robust enough such that all 282 pertinent requirements for the source provider and the AD operator 283 are satisfactorily met. The specifics of these methods are beyond 284 the scope of this document. 286 Architectural guidelines for this configuration are as follows: 288 a. Dual homing for peering points between domains is recommended 289 as a way to ensure reliability with full BGP table visibility. 291 b. If the peering point between AD-1 and AD-2 is a controlled 292 network environment, then bandwidth can be allocated 293 accordingly by the two domains to permit the transit of non- 294 rate adaptive multicast traffic. If this is not the case, then 295 it is recommended that the multicast traffic should support 296 rate-adaption. 298 c. The sending and receiving of multicast traffic between two 299 domains is typically determined by local policies associated 300 with each domain. For example, if AD-1 is a service provider 301 and AD-2 is an enterprise, then AD-1 may support local policies 302 for traffic delivery to, but not traffic reception from, AD-2. 303 Another example is the use of a policy by which AD-1 delivers 304 specified content to AD-2 only if such delivery has been 305 accepted by contract. 307 d. Relevant information on multicast streams delivered to End 308 Users in AD-2 is assumed to be collected by available 309 capabilities in the application layer. The precise nature and 310 formats of the collected information will be determined by 311 directives from the source owner and the domain operators. 313 e. The interconnection of AD-1 and AD-2 should, at a minimum, 314 follow guidelines for traffic filtering between autonomous 315 systems [BCP38]. Filtering guidelines specific to the multicast 316 control-plane and data-plane are described in section 6. 318 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 320 3.2. Peering Point Enabled with GRE Tunnel 322 The peering point is not native multicast enabled in this Use Case. 323 There is a Generic Routing Encapsulation Tunnel provisioned over the 324 peering point. In this case, the interconnection I1 between AD-1 and 325 AD-2 in Figure 1 is multicast enabled via a Generic Routing 326 Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast 327 protocols across the interface. The routing configuration is 328 basically unchanged: Instead of BGP (SAFI2) across the native IP 329 multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across 330 the GRE tunnel. 332 Advantages of this configuration: 334 o Highly efficient use of bandwidth in both domains, although not 335 as efficient as the fully native multicast Use Case. 337 o Fewer devices in the path traversed by the multicast stream 338 when compared to unicast transmissions. 340 o Ability to support only partial IP multicast deployments in AD- 341 1 and/or AD-2. 343 o GRE is an existing technology and is relatively simple to 344 implement. 346 Disadvantages of this configuration: 348 o Per Use Case 3.1, current router technology cannot count the 349 number of end users or the number bytes transmitted. 351 o GRE tunnel requires manual configuration. 353 o The GRE must be established prior to stream starting. 355 o The GRE tunnel is often left pinned up. 357 Architectural guidelines for this configuration include the 358 following: 360 Guidelines (a) through (d) are the same as those described in Use 361 Case 3.1. Two additional guidelines are as follows: 363 e. GRE tunnels are typically configured manually between peering 364 points to support multicast delivery between domains. 366 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 368 f. It is recommended that the GRE tunnel (tunnel server) 369 configuration in the source network is such that it only 370 advertises the routes to the application sources and not to the 371 entire network. This practice will prevent unauthorized delivery 372 of applications through the tunnel (e.g., if application - e.g., 373 content - is not part of an agreed inter-domain partnership). 375 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 376 Enabled 378 Both administrative domains in this Use Case are assumed to be 379 native multicast enabled here; however, the peering point is not. 380 The peering point is enabled with an Automatic Multicast Tunnel. The 381 basic configuration is depicted in Figure 2. 383 ------------------- ------------------- 384 / AD-1 \ / AD-2 \ 385 / (Multicast Enabled) \ / (Multicast Enabled) \ 386 / \ / \ 387 | +----+ | | | 388 | | | +------+ | | +------+ | +----+ 389 | | AS |------>| AR |-|---------|->| AG |-------------|-->| EU | 390 | | | +------+ | I1 | +------+ |I2 +----+ 391 \ +----+ / \ / 392 \ / \ / 393 \ / \ / 394 ------------------- ------------------- 396 AR = AMT Relay 397 AG = AMT Gateway 398 I1 = AMT Interconnection between AD-1 and AD-2 399 I2 = AD-2 and EU Multicast Connection 401 Figure 2 - AMT Interconnection between AD-1 and AD-2 403 Advantages of this configuration: 405 o Highly efficient use of bandwidth in AD-1. 407 o AMT is an existing technology and is relatively simple to 408 implement. Attractive properties of AMT include the following: 410 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 412 o Dynamic interconnection between Gateway-Relay pair across 413 the peering point. 415 o Ability to serve clients and servers with differing 416 policies. 418 Disadvantages of this configuration: 420 o Per Use Case 3.1 (AD-2 is native multicast), current router 421 technology cannot count the number of end users or the number 422 of bytes transmitted to all end users. 424 o Additional devices (AMT Gateway and Relay pairs) may be 425 introduced into the path if these services are not incorporated 426 in the existing routing nodes. 428 o Currently undefined mechanisms for the AG to automatically 429 select the optimal AR. 431 Architectural guidelines for this configuration are as follows: 433 Guidelines (a) through (d) are the same as those described in Use 434 Case 3.1. In addition, 436 e. It is recommended that AMT Relay and Gateway pairs be 437 configured at the peering points to support multicast delivery 438 between domains. AMT tunnels will then configure dynamically 439 across the peering points once the Gateway in AD-2 receives the 440 (S, G) information from the EU. 442 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 444 In this AMT Use Case, the second administrative domain AD-2 is not 445 multicast enabled. Hence, the interconnection between AD-2 and the 446 End User is also not multicast enabled. This Use Case is depicted in 447 Figure 3. 449 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 451 ------------------- ------------------- 452 / AD-1 \ / AD-2 \ 453 / (Multicast Enabled) \ / (Non-Multicast \ 454 / \ / Enabled) \ 455 | +----+ | | | 456 | | | +------+ | | | +----+ 457 | | AS |------>| AR |-|---------|-----------------------|-->|EU/G| 458 | | | +------+ | | |I2 +----+ 459 \ +----+ / \ / 460 \ / \ / 461 \ / \ / 462 ------------------- ------------------- 464 AS = Application Multicast Source 465 AR = AMT Relay 466 EU/G = Gateway client embedded in EU device 467 I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast 468 Enabled AD-2. 470 Figure 3 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 472 This Use Case is equivalent to having unicast distribution of the 473 application through AD-2. The total number of AMT tunnels would be 474 equal to the total number of End Users requesting the application. 475 The peering point thus needs to accommodate the total number of AMT 476 tunnels between the two domains. Each AMT tunnel can provide the 477 data usage associated with each End User. 479 Advantages of this configuration: 481 o Highly efficient use of bandwidth in AD-1. 483 o AMT is an existing technology and is relatively simple to 484 implement. Attractive properties of AMT include the following: 486 o Dynamic interconnection between Gateway-Relay pair across 487 the peering point. 489 o Ability to serve clients and servers with differing 490 policies. 492 o Each AMT tunnel serves as a count for each End User and is also 493 able to track data usage (bytes) delivered to the EU. 495 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 497 Disadvantages of this configuration: 499 o Additional devices (AMT Gateway and Relay pairs) are introduced 500 into the transport path. 502 o Assuming multiple peering points between the domains, the EU 503 Gateway needs to be able to find the "correct" AMT Relay in AD- 504 1. 506 Architectural guidelines for this configuration are as follows: 508 Guidelines (a) through (c) are the same as those described in Use 509 Case 3.1. 511 d. It is recommended that proper procedures are implemented such 512 that the AMT Gateway at the End User device is able to find the 513 correct AMT Relay in AD-1 across the peering points. The 514 application client in the EU device is expected to supply the (S, 515 G) information to the Gateway for this purpose. 517 e. The AMT tunnel capabilities are expected to be sufficient for 518 the purpose of collecting relevant information on the multicast 519 streams delivered to End Users in AD-2. 521 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 523 This is a variation of Use Case 3.4 as follows: 525 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 527 ------------------- ------------------- 528 / AD-1 \ / AD-2 \ 529 / (Multicast Enabled) \ / (Non-Multicast \ 530 / \ / Enabled) \ 531 | +----+ | |+--+ +--+ | 532 | | | +------+ | ||AG| |AG| | +----+ 533 | | AS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| 534 | | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ 535 \ +----+ / \+--+ +--+ / 536 \ / \ / 537 \ / \ / 538 ------------------- ------------------- 540 AS = Application Source 541 AR = AMT Relay in AD-1 542 AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point 543 I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 544 AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge 545 I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 546 EU/G = Gateway client embedded in EU device 547 I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 549 Figure 4 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 551 Use Case 3.4 results in several long AMT tunnels crossing the entire 552 network of AD-2 linking the EU device and the AMT Relay in AD-1 553 through the peering point. Depending on the number of End Users, 554 there is a likelihood of an unacceptably large number of AMT tunnels 555 - and unicast streams - through the peering point. This situation 556 can be alleviated as follows: 558 o Provisioning of strategically located AMT nodes at the edges of 559 AD-2. An AMT node comprises co-location of an AMT Gateway and 560 an AMT Relay. One such node is at the AD-2 side of the peering 561 point (node AGAR1 in Figure 4). 563 o Single AMT tunnel established across peering point linking AMT 564 Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. 566 o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to 567 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel 569 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 571 I2 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 572 in Figure 4. 574 o AMT tunnels linking EU device (via Gateway client embedded in 575 device) and AMT Relay in appropriate AMT node at edge of AD-2: 576 e.g., I3 linking EU Gateway in device to AMT Relay in AMT node 577 AGAR2. 579 The advantage for such a chained set of AMT tunnels is that the 580 total number of unicast streams across AD-2 is significantly 581 reduced, thus freeing up bandwidth. Additionally, there will be a 582 single unicast stream across the peering point instead of possibly, 583 an unacceptably large number of such streams per Use Case 3.4. 584 However, this implies that several AMT tunnels will need to be 585 dynamically configured by the various AMT Gateways based solely on 586 the (S,G) information received from the application client at the EU 587 device. A suitable mechanism for such dynamic configurations is 588 therefore critical. 590 Architectural guidelines for this configuration are as follows: 592 Guidelines (a) through (c) are the same as those described in Use 593 Case 3.1. 595 d. It is recommended that proper procedures are implemented such 596 that the various AMT Gateways (at the End User devices and the AMT 597 nodes in AD-2) are able to find the correct AMT Relay in other AMT 598 nodes as appropriate. The application client in the EU device is 599 expected to supply the (S, G) information to the Gateway for this 600 purpose. 602 e. The AMT tunnel capabilities are expected to be sufficient for 603 the purpose of collecting relevant information on the multicast 604 streams delivered to End Users in AD-2. 606 4. Supporting Functionality 608 Supporting functions and related interfaces over the peering point 609 that enable the multicast transport of the application are listed in 610 this section. Critical information parameters that need to be 611 exchanged in support of these functions are enumerated, along with 612 guidelines as appropriate. Specific interface functions for 613 consideration are as follows. 615 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 617 4.1. Network Interconnection Transport and Security Guidelines 619 The term "Network Interconnection Transport" refers to the 620 interconnection points between the two Administrative Domains. The 621 following is a representative set of attributes that will need to be 622 agreed to between the two administrative domains to support 623 multicast delivery. 625 o Number of Peering Points. 627 o Peering Point Addresses and Locations. 629 o Connection Type - Dedicated for Multicast delivery or shared 630 with other services. 632 o Connection Mode - Direct connectivity between the two AD's or 633 via another ISP. 635 o Peering Point Protocol Support - Multicast protocols that will 636 be used for multicast delivery will need to be supported at 637 these points. Examples of protocols include eBGP [RFC4271] and 638 MBGP [RFC4271]. 640 o Bandwidth Allocation - If shared with other services, then 641 there needs to be a determination of the share of bandwidth 642 reserved for multicast delivery. When determining the 643 appropriate bandwidth allocation, parties should consider use 644 of a multicast protocol suitable for live video streaming that 645 is consistent with Congestion Control Principles [BCP41]. 647 o QoS Requirements - Delay/latency specifications that need to be 648 specified in an SLA. 650 o AD Roles and Responsibilities - the role played by each AD for 651 provisioning and maintaining the set of peering points to 652 support multicast delivery. 654 4.2. Routing Aspects and Related Guidelines 656 The main objective for multicast delivery routing is to ensure that 657 the End User receives the multicast stream from the "most optimal" 658 source [INF_ATIS_10] which typically: 660 o Maximizes the multicast portion of the transport and minimizes 661 any unicast portion of the delivery, and 663 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 665 o Minimizes the overall combined network(s) route distance. 667 This routing objective applies to both Native and AMT; the actual 668 methodology of the solution will be different for each. Regardless, 669 the routing solution is expected: 671 o To be scalable, 673 o To avoid/minimize new protocol development or modifications, 674 and 676 o To be robust enough to achieve high reliability and 677 automatically adjust to changes/problems in the multicast 678 infrastructure. 680 For both Native and AMT environments, having a source as close as 681 possible to the EU network is most desirable; therefore, in some 682 cases, an AD may prefer to have multiple sources near different 683 peering points. However, that is entirely an implementation issue. 685 4.2.1 Native Multicast Routing Aspects 687 Native multicast simply requires that the Administrative Domains 688 coordinate and advertise the correct source address(es) at their 689 network interconnection peering points(i.e., border routers). An 690 example of multicast delivery via a Native Multicast process across 691 two Administrative Domains is as follows assuming that the 692 interconnecting peering points are also multicast enabled: 694 o Appropriate information is obtained by the EU client who is a 695 subscriber to AD-2 (see Use Case 3.1). This information is in 696 the form of metadata and it contains instructions directing the 697 EU client to launch an appropriate application if necessary, as 698 well as additional information for the application about the 699 source location and the group (or stream) id in the form of the 700 "S,G" data. The "S" portion provides the name or IP address of 701 the source of the multicast stream. The metadata may also 702 contain alternate delivery information such as specifying the 703 unicast address of the stream. 705 o The client uses the join message with S,G to join the multicast 706 stream [RFC4604]. 708 To facilitate this process, the two AD's need to do the following: 710 o Advertise the source id(s) over the Peering Points. 712 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 714 o Exchange relevant Peering Point information such as Capacity 715 and Utilization. 717 o Implement compatible multicast protocols to ensure proper 718 multicast delivery across the peering points. 720 4.2.2 GRE Tunnel over Interconnecting Peering Point 722 If the interconnecting peering point is not multicast enabled and 723 both AD's are multicast enabled, then a simple solution is to 724 provision a GRE tunnel between the two AD's - see Use Case 3.2.2. 725 The termination points of the tunnel will usually be a network 726 engineering decision, but generally will be between the border 727 routers or even between the AD 2 border router and the AD 1 source 728 (or source access router). The GRE tunnel would allow end-to-end 729 native multicast or AMT multicast to traverse the interface. 730 Coordination and advertisement of the source IP is still required. 732 The two AD's need to follow the same process as described in 4.2.1 733 to facilitate multicast delivery across the Peering Points. 735 4.2.3 Routing Aspects with AMT Tunnels 737 Unlike Native Multicast (with or without GRE), an AMT Multicast 738 environment is more complex. It presents a dual layered problem 739 because there are two criteria that should be simultaneously met: 741 o Find the closest AMT relay to the end-user that also has 742 multicast connectivity to the content source, and 744 o Minimize the AMT unicast tunnel distance. 746 There are essentially two components to the AMT specification: 748 o AMT Relays: These serve the purpose of tunneling UDP multicast 749 traffic to the receivers (i.e., End-Points). The AMT Relay will 750 receive the traffic natively from the multicast media source and 751 will replicate the stream on behalf of the downstream AMT 752 Gateways, encapsulating the multicast packets into unicast 753 packets and sending them over the tunnel toward the AMT Gateway. 754 In addition, the AMT Relay may perform various usage and 755 activity statistics collection. This results in moving the 756 replication point closer to the end user, and cuts down on 757 traffic across the network. Thus, the linear costs of adding 758 unicast subscribers can be avoided. However, unicast replication 760 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 762 is still required for each requesting End-Point within the 763 unicast-only network. 765 o AMT Gateway (GW): The Gateway will reside on an End-Point - this 766 may be a Personal Computer (PC) or a Set Top Box (STB). The AMT 767 Gateway receives join and leave requests from the Application 768 via an Application Programming Interface (API). In this manner, 769 the Gateway allows the End-Point to conduct itself as a true 770 Multicast End-Point. The AMT Gateway will encapsulate AMT 771 messages into UDP packets and send them through a tunnel (across 772 the unicast-only infrastructure) to the AMT Relay. 774 The simplest AMT Use Case (section 3.3) involves peering points that 775 are not multicast enabled between two multicast enabled AD's. An AMT 776 tunnel is deployed between an AMT Relay on the AD 1 side of the 777 peering point and an AMT Gateway on the AD 2 side of the peering 778 point. One advantage to this arrangement is that the tunnel is 779 established on an as needed basis and need not be a provisioned 780 element. The two AD's can coordinate and advertise special AMT Relay 781 Anycast addresses with each other. Alternately, they may decide to 782 simply provision Relay addresses, though this would not be an 783 optimal solution in terms of scalability. 785 Use Cases 3.4 and 3.5 describe more complicated AMT situations as 786 AD-2 is not multicast enabled. For these cases, the End User device 787 needs to be able to setup an AMT tunnel in the most optimal manner. 788 There are many methods by which relay selection can be done 789 including the use of DNS based queries and static lookup tables 790 [RFC7450]. The choice of the method is implementation dependent and 791 is up to the network operators. Comparison of various methods is out 792 of scope for this document; it is for further study. 794 An illustrative example of a relay selection based on DNS queries 795 and Anycast IP addresses process for Use Cases 3.4 and 3.5 is 796 described here. Using an Anycast IP address for AMT Relays allows 797 for all AMT Gateways to find the "closest" AMT Relay - the nearest 798 edge of the multicast topology of the source. Note that this is 799 strictly illustrative; the choice of the method is up to the network 800 operators. The basic process is as follows: 802 o Appropriate metadata is obtained by the EU client application. The 803 metadata contains instructions directing the EU client to an 804 ordered list of particular destinations to seek the requested 805 stream and, for multicast, specifies the source location and the 806 group (or stream) ID in the form of the "S,G" data. The "S" 807 portion provides the URI (name or IP address) of the source of the 808 multicast stream and the "G" identifies the particular stream 810 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 812 originated by that source. The metadata may also contain alternate 813 delivery information such as the address of the unicast form of 814 the content to be used, for example, if the multicast stream 815 becomes unavailable. 817 o Using the information from the metadata, and possibly information 818 provisioned directly in the EU client, a DNS query is initiated in 819 order to connect the EU client/AMT Gateway to an AMT Relay. 821 o Query results are obtained, and may return an Anycast address or a 822 specific unicast address of a relay. Multiple relays will 823 typically exist. The Anycast address is a routable "pseudo- 824 address" shared among the relays that can gain multicast access to 825 the source. 827 o If a specific IP address unique to a relay was not obtained, the 828 AMT Gateway then sends a message (e.g., the discovery message) to 829 the Anycast address such that the network is making the routing 830 choice of particular relay - e.g., closest relay to the EU. (Note 831 that in IPv6 there is a specific Anycast format and Anycast is 832 inherent in IPv6 routing, whereas in IPv4 Anycast is handled via 833 provisioning in the network. Details are out of scope for this 834 document.) 836 o The contacted AMT Relay then returns its specific unicast IP 837 address (after which the Anycast address is no longer required). 838 Variations may exist as well. 840 o The AMT Gateway uses that unicast IP address to initiate a three- 841 way handshake with the AMT Relay. 843 o AMT Gateway provides "S,G" to the AMT Relay (embedded in AMT 844 protocol messages). 846 o AMT Relay receives the "S,G" information and uses the S,G to join 847 the appropriate multicast stream, if it has not already subscribed 848 to that stream. 850 o AMT Relay encapsulates the multicast stream into the tunnel 851 between the Relay and the Gateway, providing the requested content 852 to the EU. 854 4.3. Back Office Functions - Provisioning and Logging Guidelines 856 Back Office refers to the following: 858 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 860 o Servers and Content Management systems that support the delivery 861 of applications via multicast and interactions between AD's. 862 o Functionality associated with logging, reporting, ordering, 863 provisioning, maintenance, service assurance, settlement, etc. 865 4.3.1 Provisioning Guidelines 867 Resources for basic connectivity between AD's Providers need to be 868 provisioned as follows: 870 o Sufficient capacity must be provisioned to support multicast-based 871 delivery across AD's. 872 o Sufficient capacity must be provisioned for connectivity between 873 all supporting back-offices of the AD's as appropriate. This 874 includes activating proper security treatment for these back- 875 office connections (gateways, firewalls, etc) as appropriate. 876 o Routing protocols as needed, e.g. configuring routers to support 877 these. 879 Provisioning aspects related to Multicast-Based inter-domain 880 delivery are as follows. 882 The ability to receive requested application via multicast is 883 triggered via receipt of the necessary metadata. Hence, this 884 metadata must be provided to the EU regarding multicast URL - and 885 unicast fallback if applicable. AD-2 must enable the delivery of 886 this metadata to the EU and provision appropriate resources for this 887 purpose. 889 Native multicast functionality is assumed to be available across 890 many ISP backbones, peering and access networks. If, however, native 891 multicast is not an option (Use Cases 3.4 and 3.5), then: 893 o EU must have multicast client to use AMT multicast obtained either 894 from Application Source (per agreement with AD-1) or from AD-1 or 895 AD-2 (if delegated by the Application Source). 896 o If provided by AD-1/AD-2, then the EU could be redirected to a 897 client download site (note: this could be an Application Source 898 site). If provided by the Application Source, then this Source 899 would have to coordinate with AD-1 to ensure the proper client is 900 provided (assuming multiple possible clients). 902 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 904 o Where AMT Gateways support different application sets, all AD-2 905 AMT Relays need to be provisioned with all source & group 906 addresses for streams it is allowed to join. 907 o DNS across each AD must be provisioned to enable a client GW to 908 locate the optimal AMT Relay (i.e. longest multicast path and 909 shortest unicast tunnel) with connectivity to the content's 910 multicast source. 912 Provisioning Aspects Related to Operations and Customer Care are 913 stated as follows. 915 Each AD provider is assumed to provision operations and customer 916 care access to their own systems. 918 AD-1's operations and customer care functions must have visibility 919 to what is happening in AD-2's network or to the service provided by 920 AD-2, sufficient to verify their mutual goals and operations, e.g. 921 to know how the EU's are being served. This can be done in two ways: 923 o Automated interfaces are built between AD-1 and AD-2 such that 924 operations and customer care continue using their own systems. 925 This requires coordination between the two AD's with appropriate 926 provisioning of necessary resources. 927 o AD-1's operations and customer care personnel are provided access 928 directly to AD-2's system. In this scenario, additional 929 provisioning in these systems will be needed to provide necessary 930 access. Additional provisioning must be agreed to by the two AD's 931 to support this option. 933 4.3.2 Application Accounting Guidelines 935 All interactions between pairs of AD's can be discovered and/or be 936 associated with the account(s) utilized for delivered applications. 937 Supporting guidelines are as follows: 939 o A unique identifier is recommended to designate each master 940 account. 941 o AD-2 is expected to set up "accounts" (logical facility generally 942 protected by login/password/credentials) for use by AD-1. Multiple 943 accounts and multiple types/partitions of accounts can apply, e.g. 944 customer accounts, security accounts, etc. 946 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 948 4.3.3 Log Management Guidelines 950 Successful delivery of applications via multicast between pairs of 951 interconnecting AD's requires that appropriate logs will be 952 exchanged between them in support. Associated guidelines are as 953 follows. 955 AD-2 needs to supply logs to AD-1 per existing contract(s). Examples 956 of log types include the following: 958 o Usage information logs at aggregate level. 959 o Usage failure instances at an aggregate level. 960 o Grouped or sequenced application access. 961 performance/behavior/failure at an aggregate level to support 962 potential Application Provider-driven strategies. Examples of 963 aggregate levels include grouped video clips, web pages, and sets 964 of software download. 965 o Security logs, aggregated or summarized according to agreement 966 (with additional detail potentially provided during security 967 events, by agreement). 968 o Access logs (EU), when needed for troubleshooting. 969 o Application logs (what is the application doing), when needed for 970 shared troubleshooting. 971 o Syslogs (network management), when needed for shared 972 troubleshooting. 974 The two AD's may supply additional security logs to each other as 975 agreed to by contract(s). Examples include the following: 977 o Information related to general security-relevant activity which 978 may be of use from a protective or response perspective, such as 979 types and counts of attacks detected, related source information, 980 related target information, etc. 981 o Aggregated or summarized logs according to agreement (with 982 additional detail potentially provided during security events, by 983 agreement). 985 4.4. Operations - Service Performance and Monitoring Guidelines 987 Service Performance refers to monitoring metrics related to 988 multicast delivery via probes. The focus is on the service provided 989 by AD-2 to AD-1 on behalf of all multicast application sources 991 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 993 (metrics may be specified for SLA use or otherwise). Associated 994 guidelines are as follows: 996 o Both AD's are expected to monitor, collect, and analyze service 997 performance metrics for multicast applications. AD-2 provides 998 relevant performance information to AD-1; this enables AD-1 to 999 create an end-to-end performance view on behalf of the 1000 multicast application source. 1002 o Both AD's are expected to agree on the type of probes to be 1003 used to monitor multicast delivery performance. For example, 1004 AD-2 may permit AD-1's probes to be utilized in the AD-2 1005 multicast service footprint. Alternately, AD-2 may deploy its 1006 own probes and relay performance information back to AD-1. 1008 o In the event of performance degradation (SLA violation), AD-1 1009 may have to compensate the multicast application source per SLA 1010 agreement. As appropriate, AD-1 may seek compensation from AD-2 1011 if the cause of the degradation is in AD-2's network. 1013 Service Monitoring generally refers to a service (as a whole) 1014 provided on behalf of a particular multicast application source 1015 provider. It thus involves complaints from End Users when service 1016 problems occur. EUs direct their complaints to the source provider; 1017 in turn the source provider submits these complaints to AD-1. The 1018 responsibility for service delivery lies with AD-1; as such AD-1 1019 will need to determine where the service problem is occurring - its 1020 own network or in AD-2. It is expected that each AD will have tools 1021 to monitor multicast service status in its own network. 1023 o Both AD's will determine how best to deploy multicast service 1024 monitoring tools. Typically, each AD will deploy its own set of 1025 monitoring tools; in which case, both AD's are expected to 1026 inform each other when multicast delivery problems are 1027 detected. 1029 o AD-2 may experience some problems in its network. For example, 1030 for the AMT Use Cases, one or more AMT Relays may be 1031 experiencing difficulties. AD-2 may be able to fix the problem 1032 by rerouting the multicast streams via alternate AMT Relays. If 1033 the fix is not successful and multicast service delivery 1034 degrades, then AD-2 needs to report the issue to AD-1. 1036 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1038 o When problem notification is received from a multicast 1039 application source, AD-1 determines whether the cause of the 1040 problem is within its own network or within the AD-2 domain. If 1041 the cause is within the AD-2 domain, then AD-1 supplies all 1042 necessary information to AD-2. Examples of supporting 1043 information include the following: 1045 o Kind of problem(s). 1047 o Starting point & duration of problem(s). 1049 o Conditions in which problem(s) occur. 1051 o IP address blocks of affected users. 1053 o ISPs of affected users. 1055 o Type of access e.g., mobile versus desktop. 1057 o Locations of affected EUs. 1059 o Both AD's conduct some form of root cause analysis for 1060 multicast service delivery problems. Examples of various 1061 factors for consideration include: 1063 o Verification that the service configuration matches the 1064 product features. 1066 o Correlation and consolidation of the various customer 1067 problems and resource troubles into a single root service 1068 problem. 1070 o Prioritization of currently open service problems, giving 1071 consideration to problem impact, service level agreement, 1072 etc. 1074 o Conduction of service tests, including one time tests or a 1075 series of tests over a period of time. 1077 o Analysis of test results. 1079 o Analysis of relevant network fault or performance data. 1081 o Analysis of the problem information provided by the customer 1082 (CP). 1084 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1086 o Once the cause of the problem has been determined and the 1087 problem has been fixed, both AD's need to work jointly to 1088 verify and validate the success of the fix. 1090 o Faults in service could lead to SLA violation for which the 1091 multicast application source provider may have to be 1092 compensated by AD-1. Subsequently, AD-1 may have to be 1093 compensated by AD-2 based on the contract. 1095 4.5. Client Reliability Models/Service Assurance Guidelines 1097 There are multiple options for instituting reliability 1098 architectures, most are at the application level. Both AD's should 1099 work those out with their contract/agreement and with the multicast 1100 application source providers. 1102 Network reliability can also be enhanced by the two AD's by 1103 provisioning alternate delivery mechanisms via unicast means. 1105 5. Troubleshooting and Diagnostics 1107 Any service provider supporting multicast delivery of content should 1108 have the capability to collect diagnostics as part of multicast 1109 troubleshooting practices and resolve network issues accordingly. 1110 Issues may become apparent or identified either through network 1111 monitoring functions or by customer reported problems as described 1112 in section 4.4. 1114 It is expected that multicast diagnostics will be collected 1115 according to currently established practices [MDH-04]. However, 1116 given that inter-domain multicast creates a significant 1117 interdependence of proper networking functionality between providers 1118 there does exist a need for providers to be able to signal/alert 1119 each other if there are any issues noted by either one. 1121 Service providers may also wish to allow limited read-only 1122 administrative access to their routers via a looking-glass style 1123 router proxy to facilitate the debugging of multicast control state 1124 and peering status. Software implementations for this purpose is 1125 readily available [Traceroute], [draft-MTraceroute] and can be 1126 easily extended to provide access to commonly-used multicast 1127 troubleshooting commands in a secure manner. 1129 The specifics of the notification and alerts are beyond the scope of 1130 this document, but general guidelines are similar to those described 1132 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1134 in section 4.4 (Service Performance and Monitoring). Some general 1135 communications issues are stated as follows. 1137 o Appropriate communications channels will be established between 1138 the customer service and operations groups from both AD's to 1139 facilitate information sharing related to diagnostic 1140 troubleshooting. 1142 o A default resolution period may be considered to resolve open 1143 issues. Alternately, mutually acceptable resolution periods 1144 could be established depending on the severity of the 1145 identified trouble. 1147 6. Security Considerations 1149 From a security perspective, normal security procedures are expected 1150 to be followed by each AD to facilitate multicast delivery to 1151 registered and authenticated end users. Additionally: 1153 o Encryption - Peering point links may be encrypted per agreement 1154 for multicast delivery. 1156 o Security Breach Mitigation Plan - In the event of a security 1157 breach, the two AD's are expected to have a mitigation plan for 1158 shutting down the peering point and directing multicast traffic 1159 over alternative peering points. It is also expected that 1160 appropriate information will be shared for the purpose of 1161 securing the identified breach. 1163 DRM and Application Accounting, Authorization and Authentication 1164 should be the responsibility of the multicast application source 1165 provider and/or AD-1. AD-1 needs to work out the appropriate 1166 agreements with the source provider. 1168 Network has no DRM responsibilities, but might have authentication 1169 and authorization obligations. These though are consistent with 1170 normal operations of a CDN to insure end user reliability, security 1171 and network security. 1173 AD-1 and AD-2 should have mechanisms in place to ensure proper 1174 accounting for the volume of bytes delivered through the peering 1175 point and separately the number of bytes delivered to EUs. For 1176 example, [BCP38] style filtering could be deployed by both AD's to 1177 ensure that only legitimately sourced multicast content is exchanged 1178 between them. 1180 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1182 Authentication and authorization of EU to receive multicast content 1183 is done at the application layer between the client application and 1184 the source. This may involve some kind of token authentication and 1185 is done at the application layer independently of the two AD's. If 1186 there are problems related to failure of token authentication when 1187 end-users are supported by AD-2, then some means of validating 1188 proper working of the token authentication process (e.g., back-end 1189 servers querying the multicast application source provider's token 1190 authentication server are communicating properly) should be 1191 considered. Implementation details are beyond the scope of this 1192 document. 1194 7. IANA Considerations 1196 No considerations identified in this document 1198 8. Conclusions 1200 This Best Current Practice document provides detailed Use Case 1201 scenarios for the transmission of applications via multicast across 1202 peering points between two Administrative Domains. A detailed set of 1203 guidelines supporting the delivery is provided for all Use Cases. 1205 For Use Cases involving AMT tunnels (cases 3.4 and 3.5), it is 1206 recommended that proper procedures are implemented such that the 1207 various AMT Gateways (at the End User devices and the AMT nodes in 1208 AD-2) are able to find the correct AMT Relay in other AMT nodes as 1209 appropriate. Section 4.3 provides an overview of one method that 1210 finds the optimal Relay-Gateway combination via the use of an 1211 Anycast IP address for AMT Relays. 1213 9. References 1215 9.1. Normative References 1217 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 1218 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 1220 [RFC3376] B. Cain, et al, "Internet Group Management Protocol, 1221 Version 3", RFC 3376, October 2002 1223 [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery 1224 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004 1226 [RFC4271] Y. Rekhter, et al, "A Border Gateway Protocol 4 (BGP-4)", 1227 RFC 4271, January 2006 1229 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1231 [RFC4604] H. Holbrook, et al, "Using Internet Group Management 1232 Protocol Version 3 (IGMPv3) and Multicast Listener Discovery 1233 Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, 1234 August 2006 1236 [RFC4609] P. Savola, et al, "Protocol Independent Multicast - Sparse 1237 Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", 1238 RFC 4609, August 2006 1240 [RFC7450] G. Bumgardner, "Automatic Multicast Tunneling", RFC 7450, 1241 February 2015 1243 [RFC7761] B. Fenner, et al, "Protocol Independent Multicast - Sparse 1244 Mode (PIM-SM): Protocol Specification (Revised), RFC 7761, March 1245 2016 1247 [BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating 1248 Denial of Service Attacks which employ IP Source Address Spoofing", 1249 BCP: 38, May 2000 1251 [BCP41] S. Floyd, "Congestion Control Principles", BCP 41, September 1252 2000 1254 9.2. Informative References 1256 [INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a 1257 Multi-Party Federation Environment", ATIS Standard A-0200010, 1258 December 2012 1260 [MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D 1261 draft-ietf-mboned-mdh-04.txt, May 2000 1263 [Traceroute] http://traceroute.org/#source%20code 1265 [draft-MTraceroute] H. Asaeda, K, Meyer, and W. Lee, "Mtrace Version 1266 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace- 1267 v2-16, October 2016, work in progress 1269 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1271 10. Acknowledgments 1273 The authors would like to thank the following individuals for their 1274 suggestions, comments, and corrections: 1276 Mikael Abrahamsson 1278 Hitoshi Asaeda 1280 Dale Carder 1282 Tim Chown 1284 Leonard Giuliano 1286 Jake Holland 1288 Joel Jaeggli 1290 Albert Manfredi 1292 Stig Venaas 1294 IETF I-D Multicast Across Inter-Domain Peering Points August 2017 1296 Authors' Addresses 1298 Percy S. Tarapore 1299 AT&T 1300 Phone: 1-732-420-4172 1301 Email: tarapore@att.com 1303 Robert Sayko 1304 AT&T 1305 Phone: 1-732-420-3292 1306 Email: rs1983@att.com 1308 Greg Shepherd 1309 Cisco 1310 Phone: 1311 Email: shep@cisco.com 1313 Toerless Eckert 1314 Futurewei Technologies Inc. 1315 Phone: 1316 Email: tte@cs.fau.de 1318 Ram Krishnan 1319 SupportVectors 1320 Phone: 1321 Email: ramkri123@gmail.com