idnits 2.17.1 draft-ietf-mboned-interdomain-peering-bcp-07.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: ' 6. 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: ' 7. IANA Considerations' ) ** There are 19 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 122 has weird spacing: '...Catalog all ...' == Line 412 has weird spacing: '...Ability to s...' == Line 425 has weird spacing: '...tically selec...' == Line 486 has weird spacing: '...Ability to s...' == Line 639 has weird spacing: '... for multi...' == (5 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 (February 1, 2017) is 2633 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? 'RFC4609' on line 1235 looks like a reference -- Missing reference section? 'RFC7761' on line 1242 looks like a reference -- Missing reference section? 'RFC3376' on line 1216 looks like a reference -- Missing reference section? 'RFC3810' on line 1222 looks like a reference -- Missing reference section? 'RFC7450' on line 1239 looks like a reference -- Missing reference section? 'RFC2784' on line 1213 looks like a reference -- Missing reference section? 'BCP38' on line 1246 looks like a reference -- Missing reference section? 'RFC4271' on line 1225 looks like a reference -- Missing reference section? 'BCP41' on line 1250 looks like a reference -- Missing reference section? 'RFC4604' on line 1230 looks like a reference -- Missing reference section? 'MDH-04' on line 1259 looks like a reference -- Missing reference section? 'Traceroute' on line 1262 looks like a reference -- Missing reference section? 'RFC3618' on line 1219 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 14 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 1, 2017 Greg Shepherd 5 Toerless Eckert 6 Cisco 7 Ram Krishnan 8 Brocade 9 February 1, 2017 11 Use of Multicast Across Inter-Domain Peering Points 12 draft-ietf-mboned-interdomain-peering-bcp-07.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 1, 2017. 31 Copyright Notice 33 Copyright (c) 2017 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 Multicast Across Inter-Domain Peering Points February 2017 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 use of Source Specific Multicast (SSM) 63 across inter-domain peering points for a specified set of deployment 64 scenarios. The objective is to describe the setup process for 65 multicast-based delivery across administrative domains for these 66 scenarios and document supporting functionality to enable this 67 process. 69 Table of Contents 71 1. Introduction...................................................3 72 2. Overview of Inter-domain Multicast Application Transport.......4 73 3. Inter-domain Peering Point Requirements for Multicast..........6 74 3.1. Native Multicast..........................................6 75 3.2. Peering Point Enabled with GRE Tunnel.....................8 76 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 77 Enabled........................................................9 78 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 79 Enabled.......................................................10 80 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through 81 AD-2..........................................................12 82 4. Supporting Functionality......................................14 83 4.1. Network Interconnection Transport and Security Guidelines15 84 4.2. Routing Aspects and Related Guidelines...................15 85 4.2.1 Native Multicast Routing Aspects..................16 86 4.2.2 GRE Tunnel over Interconnecting Peering Point.....17 87 4.2.3 Routing Aspects with AMT Tunnels.....................17 88 4.3. Back Office Functions - Provisioning and Logging Guidelines 89 ..............................................................20 90 4.3.1 Provisioning Guidelines...........................20 91 4.3.2 Application Accounting Guidelines.................21 92 4.3.3 Log Management Guidelines.........................22 93 4.4. Operations - Service Performance and Monitoring Guidelines22 95 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 97 4.5. Client Reliability Models/Service Assurance Guidelines...25 98 5. Troubleshooting and Diagnostics...............................25 99 6. Security Considerations.......................................26 100 7. IANA Considerations...........................................27 101 8. Conclusions...................................................27 102 9. References....................................................27 103 9.1. Normative References.....................................27 104 9.2. Informative References...................................28 105 10. Acknowledgments..............................................29 107 1. Introduction 109 Content and data from several types of applications (e.g., live 110 video streaming, software downloads) are well suited for delivery 111 via multicast means. The use of multicast for delivering such 112 content/data offers significant savings for utilization of resources 113 in any given administrative domain. End user demand for such 114 content/data is growing. Often, this requires transporting the 115 content/data across administrative domains via inter-domain peering 116 points. 118 The objective of this Best Current Practices document is twofold: 119 o Describe the technical process and establish guidelines for 120 setting up multicast-based delivery of application content/data 121 across inter-domain peering points via a set of use cases. 122 o Catalog all required information exchange between the 123 administrative domains to support multicast-based delivery. This 124 enables operators to initiate necessary processes to support 125 inter-domain peering with multicast. 127 The scope and assumptions for this document are stated as follows: 129 o For the purpose of this document, the term "peering point" 130 refers to an interface between two networks/administrative 131 domains over which traffic is exchanged between them. A 132 Network-Network Interface (NNI) is an example of a peering 133 point. 134 o Administrative Domain 1 (AD-1) is enabled with native 135 multicast. A peering point exists between AD-1 and AD-2. 136 o It is understood that several protocols are available for this 137 purpose including PIM-SM [RFC4609], Protocol Independent 138 Multicast - Source Specific Multicast (PIM-SSM) [RFC7761], 139 Internet Group Management Protocol (IGMP) [RFC3376], and 140 Multicast Listener Discovery (MLD) [RFC3810]. 142 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 144 o As described in Section 2, the source IP address of the 145 multicast stream in the originating AD (AD-1) is known. Under 146 this condition, PIM-SSM use is beneficial as it allows the 147 receiver's upstream router to directly send a JOIN message to 148 the source without the need of invoking an intermediate 149 Rendezvous Point (RP). Use of SSM also presents an improved 150 threat mitigation profile against attack, as described in 151 [RFC4609]. Hence, in the case of inter-domain peering, it is 152 recommended to use only SSM protocols; the setup of inter- 153 domain peering for ASM (Any-Source Multicast) is not in scope 154 for this document. 155 o AD-1 and AD-2 are assumed to adopt compatible protocols. The 156 use of different protocols is beyond the scope of this 157 document. 158 o An Automatic Multicast Tunnel (AMT) [RFC7450] is setup at the 159 peering point if either the peering point or AD-2 is not 160 multicast enabled. It is assumed that an AMT Relay will be 161 available to a client for multicast delivery. The selection of 162 an optimal AMT relay by a client is out of scope for this 163 document. Note that AMT use is necessary only when native 164 multicast is unavailable in the peering point (Use Case 3.3) or 165 in the downstream administrative domain (Use Cases 3.4, and 166 3.5). 167 o The collection of billing data is assumed to be done at the 168 application level and is not considered to be a networking 169 issue. The settlements process for end user billing and/or 170 inter-provider billing is out of scope for this document. 171 o Inter-domain network connectivity troubleshooting is only 172 considered within the context of a cooperative process between 173 the two domains. 174 Thus, the primary purpose of this document is to describe a scenario 175 where two ADs interconnect via a direct connection to each other. 176 Security and operational aspects for exchanging traffic on a public 177 Internet Exchange Point (IXP) with a large shared broadcast domain 178 between many operators, is not in scope for this document. 180 This document also attempts to identify ways by which the peering 181 process can be improved. Development of new methods for improvement 182 is beyond the scope of this document. 184 2. Overview of Inter-domain Multicast Application Transport 186 A multicast-based application delivery scenario is as follows: 188 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 190 o Two independent administrative domains are interconnected via a 191 peering point. 192 o The peering point is either multicast enabled (end-to-end 193 native multicast across the two domains) or it is connected by 194 one of two possible tunnel types: 195 o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] 196 allowing multicast tunneling across the peering point, or 197 o An Automatic Multicast Tunnel (AMT) [RFC7450]. 198 o A service provider controls one or more application sources in 199 AD-1 which will send multicast IP packets for one or more 200 (S,G)s. It is assumed that the service being provided is 201 suitable for delivery via multicast (e.g. live video streaming 202 of popular events, software downloads to many devices, etc.), 203 and that the packet streams will be part of a suitable 204 multicast transport protocol. 205 o An End User (EU) controls a device connected to AD-2, which 206 runs an application client compatible with the service 207 provider's application source. 208 o The application client joins appropriate (S,G)s in order to 209 receive the data necessary to provide the service to the EU. 210 The mechanisms by which the application client learns the 211 appropriate (S,G)s are an implementation detail of the 212 application, and are out of scope for this document. 214 Note that domain 2 may be an independent network domain (e.g., Tier 215 1 network operator domain) or it could also be an Enterprise network 216 operated by a single customer. The peering point architecture and 217 requirements may have some unique aspects associated with the 218 Enterprise case. 220 The Use Cases describing various architectural configurations for 221 the multicast distribution along with associated requirements is 222 described in section 3. Unique aspects related to the Enterprise 223 network possibility will be described in this section. A 224 comprehensive list of pertinent information that needs to be 225 exchanged between the two domains to support various functions 226 enabling the application transport is provided in section 4. 228 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 230 3. Inter-domain Peering Point Requirements for Multicast 232 The transport of applications using multicast requires that the 233 inter-domain peering point is enabled to support such a process. 234 There are five Use Cases for consideration in this document. 236 3.1. Native Multicast 238 This Use Case involves end-to-end Native Multicast between the two 239 administrative domains and the peering point is also native 240 multicast enabled - Figure 1. 242 ------------------- ------------------- 243 / AD-1 \ / AD-2 \ 244 / (Multicast Enabled) \ / (Multicast Enabled) \ 245 / \ / \ 246 | +----+ | | | 247 | | | +------+ | | +------+ | +----+ 248 | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | 249 | | | +------+ | I1 | +------+ |I2 +----+ 250 \ +----+ / \ / 251 \ / \ / 252 \ / \ / 253 ------------------- ------------------- 255 AD = Administrative Domain (Independent Autonomous System) 256 AS = Application (e.g., Content) Multicast Source 257 BR = Border Router 258 I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) 259 I2 = AD-2 and EU Multicast Connection 261 Figure 1 - Content Distribution via End to End Native Multicast 263 Advantages of this configuration are: 265 o Most efficient use of bandwidth in both domains. 267 o Fewer devices in the path traversed by the multicast stream when 268 compared to unicast transmissions. 270 From the perspective of AD-1, the one disadvantage associated with 271 native multicast into AD-2 instead of individual unicast to every EU 273 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 275 in AD-2 is that it does not have the ability to count the number of 276 End Users as well as the transmitted bytes delivered to them. This 277 information is relevant from the perspective of customer billing and 278 operational logs. It is assumed that such data will be collected by 279 the application layer. The application layer mechanisms for 280 generating this information need to be robust enough such that all 281 pertinent requirements for the source provider and the AD operator 282 are satisfactorily met. The specifics of these methods are beyond 283 the scope of this document. 285 Architectural guidelines for this configuration are as follows: 287 a. Dual homing for peering points between domains is recommended as 288 a way to ensure reliability with full BGP table visibility. 290 b. If the peering point between AD-1 and AD-2 is a controlled network 291 environment, then bandwidth can be allocated accordingly by the 292 two domains to permit the transit of non-rate adaptive multicast 293 traffic. If this is not the case, then it is recommended that the 294 multicast traffic should support rate-adaption. 296 c. The sending and receiving of multicast traffic between two domains 297 is typically determined by local policies associated with each 298 domain. For example, if AD-1 is a service provider and AD-2 is an 299 enterprise, then AD-1 may support local policies for traffic 300 delivery to, but not traffic reception from AD-2. Another example 301 is the use of a policy by which AD-1 delivers specified content 302 to AD-2 only if such delivery has been accepted by contract. 304 d. Relevant information on multicast streams delivered to End Users 305 in AD-2 is assumed to be collected by available capabilities in 306 the application layer. The precise nature and formats of the 307 collected information will be determined by directives from the 308 source owner and the domain operators. 310 e. The interconnection of AD-1 and AD-2 should minimally follow 311 guidelines for traffic filtering between autonomous systems 312 [BCP38]. Filtering guidelines specific to the multicast control- 313 plane and data-plane are described in section 6. 315 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 317 3.2. Peering Point Enabled with GRE Tunnel 319 The peering point is not native multicast enabled in this Use Case. 320 There is a Generic Routing Encapsulation Tunnel provisioned over the 321 peering point. In this case, the interconnection I1 between AD-1 and 322 AD-2 in Figure 1 is multicast enabled via a Generic Routing 323 Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast 324 protocols across the interface. The routing configuration is 325 basically unchanged: Instead of BGP (SAFI2) across the native IP 326 multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across 327 the GRE tunnel. 329 Advantages of this configuration: 331 o Highly efficient use of bandwidth in both domains although not as 332 efficient as the fully native multicast Use Case. 334 o Fewer devices in the path traversed by the multicast stream when 335 compared to unicast transmissions. 337 o Ability to support only partial IP multicast deployments in AD-1 338 and/or AD-2. 340 o GRE is an existing technology and is relatively simple to 341 implement. 343 Disadvantages of this configuration: 345 o Per Use Case 3.1, current router technology cannot count the 346 number of end users or the number bytes transmitted. 348 o GRE tunnel requires manual configuration. 350 o The GRE must be established prior to stream starting. 352 o The GRE tunnel is often left pinned up. 354 Architectural guidelines for this configuration include the 355 following: 357 Guidelines (a) through (d) are the same as those described in Use 358 Case 3.1. Two additional guidelines are as follows: 360 e. GRE tunnels are typically configured manually between peering 361 points to support multicast delivery between domains. 363 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 365 f. It is recommended that the GRE tunnel (tunnel server) 366 configuration in the source network is such that it only 367 advertises the routes to the application sources and not to the 368 entire network. This practice will prevent unauthorized delivery 369 of applications through the tunnel (e.g., if application - e.g., 370 content - is not part of an agreed inter-domain partnership). 372 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 373 Enabled 375 Both administrative domains in this Use Case are assumed to be 376 native multicast enabled here; however the peering point is not. The 377 peering point is enabled with an Automatic Multicast Tunnel. The 378 basic configuration is depicted in Figure 2. 380 ------------------- ------------------- 381 / AD-1 \ / AD-2 \ 382 / (Multicast Enabled) \ / (Multicast Enabled) \ 383 / \ / \ 384 | +----+ | | | 385 | | | +------+ | | +------+ | +----+ 386 | | AS |------>| AR |-|---------|->| AG |-------------|-->| EU | 387 | | | +------+ | I1 | +------+ |I2 +----+ 388 \ +----+ / \ / 389 \ / \ / 390 \ / \ / 391 ------------------- ------------------- 393 AR = AMT Relay 394 AG = AMT Gateway 395 I1 = AMT Interconnection between AD-1 and AD-2 396 I2 = AD-2 and EU Multicast Connection 398 Figure 2 - AMT Interconnection between AD-1 and AD-2 400 Advantages of this configuration: 402 o Highly efficient use of bandwidth in AD-1. 404 o AMT is an existing technology and is relatively simple to 405 implement. Attractive properties of AMT include the following: 407 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 409 o Dynamic interconnection between Gateway-Relay pair across 410 the peering point. 412 o Ability to serve clients and servers with differing 413 policies. 415 Disadvantages of this configuration: 417 o Per Use Case 3.1 (AD-2 is native multicast), current router 418 technology cannot count the number of end users or the number of 419 bytes transmitted to all end users. 421 o Additional devices (AMT Gateway and Relay pairs) may be introduced 422 into the path if these services are not incorporated in the 423 existing routing nodes. 425 o Currently undefined mechanisms for the AG to automatically select 426 the optimal AR. 428 Architectural guidelines for this configuration are as follows: 430 Guidelines (a) through (d) are the same as those described in Use 431 Case 3.1. In addition, 433 e. It is recommended that AMT Relay and Gateway pairs be 434 configured at the peering points to support multicast delivery 435 between domains. AMT tunnels will then configure dynamically 436 across the peering points once the Gateway in AD-2 receives the 437 (S, G) information from the EU. 439 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 441 In this AMT Use Case, the second administrative domain AD-2 is not 442 multicast enabled. This implies that the interconnection between AD- 443 2 and the End User is also not multicast enabled as depicted in 444 Figure 3. 446 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 448 ------------------- ------------------- 449 / AD-1 \ / AD-2 \ 450 / (Multicast Enabled) \ / (Non-Multicast \ 451 / \ / Enabled) \ 452 | +----+ | | | 453 | | | +------+ | | | +----+ 454 | | AS |------>| AR |-|---------|-----------------------|-->|EU/G| 455 | | | +------+ | | |I2 +----+ 456 \ +----+ / \ / 457 \ / \ / 458 \ / \ / 459 ------------------- ------------------- 461 AS = Application Multicast Source 462 AR = AMT Relay 463 EU/G = Gateway client embedded in EU device 464 I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast 465 Enabled AD-2. 467 Figure 3 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 469 This Use Case is equivalent to having unicast distribution of the 470 application through AD-2. The total number of AMT tunnels would be 471 equal to the total number of End Users requesting the application. 472 The peering point thus needs to accommodate the total number of AMT 473 tunnels between the two domains. Each AMT tunnel can provide the 474 data usage associated with each End User. 476 Advantages of this configuration: 478 o Highly efficient use of bandwidth in AD-1. 480 o AMT is an existing technology and is relatively simple to 481 implement. Attractive properties of AMT include the following: 483 o Dynamic interconnection between Gateway-Relay pair across 484 the peering point. 486 o Ability to serve clients and servers with differing 487 policies. 489 o Each AMT tunnel serves as a count for each End User and is also 490 able to track data usage (bytes) delivered to the EU. 492 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 494 Disadvantages of this configuration: 496 o Additional devices (AMT Gateway and Relay pairs) are introduced 497 into the transport path. 499 o Assuming multiple peering points between the domains, the EU 500 Gateway needs to be able to find the "correct" AMT Relay in AD- 501 1. 503 Architectural guidelines for this configuration are as follows: 505 Guidelines (a) through (c) are the same as those described in Use 506 Case 3.1. 508 d. It is recommended that proper procedures are implemented such 509 that the AMT Gateway at the End User device is able to find the 510 correct AMT Relay in AD-1 across the peering points. The 511 application client in the EU device is expected to supply the (S, 512 G) information to the Gateway for this purpose. 514 e. The AMT tunnel capabilities are expected to be sufficient for 515 the purpose of collecting relevant information on the multicast 516 streams delivered to End Users in AD-2. 518 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 520 This is a variation of Use Case 3.4 as follows: 522 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 524 ------------------- ------------------- 525 / AD-1 \ / AD-2 \ 526 / (Multicast Enabled) \ / (Non-Multicast \ 527 / \ / Enabled) \ 528 | +----+ | |+--+ +--+ | 529 | | | +------+ | ||AG| |AG| | +----+ 530 | | AS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| 531 | | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ 532 \ +----+ / \+--+ +--+ / 533 \ / \ / 534 \ / \ / 535 ------------------- ------------------- 537 AS = Application Source 538 AR = AMT Relay in AD-1 539 AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point 540 I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 541 AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge 542 I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 543 EU/G = Gateway client embedded in EU device 544 I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 546 Figure 4 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 548 Use Case 3.4 results in several long AMT tunnels crossing the entire 549 network of AD-2 linking the EU device and the AMT Relay in AD-1 550 through the peering point. Depending on the number of End Users, 551 there is a likelihood of an unacceptably large number of AMT tunnels 552 - and unicast streams - through the peering point. This situation 553 can be alleviated as follows: 555 o Provisioning of strategically located AMT nodes at the edges of 556 AD-2. An AMT node comprises co-location of an AMT Gateway and an 557 AMT Relay. One such node is at the AD-2 side of the peering point 558 (node AGAR1 in Figure 4). 560 o Single AMT tunnel established across peering point linking AMT 561 Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. 563 o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to 564 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 566 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 568 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 in 569 Figure 4. 571 o AMT tunnels linking EU device (via Gateway client embedded in 572 device) and AMT Relay in appropriate AMT node at edge of AD-2: 573 e.g., I3 linking EU Gateway in device to AMT Relay in AMT node 574 AGAR2. 576 The advantage for such a chained set of AMT tunnels is that the 577 total number of unicast streams across AD-2 is significantly reduced 578 thus freeing up bandwidth. Additionally, there will be a single 579 unicast stream across the peering point instead of possibly, an 580 unacceptably large number of such streams per Use Case 3.4. However, 581 this implies that several AMT tunnels will need to be dynamically 582 configured by the various AMT Gateways based solely on the (S,G) 583 information received from the application client at the EU device. A 584 suitable mechanism for such dynamic configurations is therefore 585 critical. 587 Architectural guidelines for this configuration are as follows: 589 Guidelines (a) through (c) are the same as those described in Use 590 Case 3.1. 592 d. It is recommended that proper procedures are implemented such 593 that the various AMT Gateways (at the End User devices and the AMT 594 nodes in AD-2) are able to find the correct AMT Relay in other AMT 595 nodes as appropriate. The application client in the EU device is 596 expected to supply the (S, G) information to the Gateway for this 597 purpose. 599 e. The AMT tunnel capabilities are expected to be sufficient for 600 the purpose of collecting relevant information on the multicast 601 streams delivered to End Users in AD-2. 603 4. Supporting Functionality 605 Supporting functions and related interfaces over the peering point 606 that enable the multicast transport of the application are listed in 607 this section. Critical information parameters that need to be 608 exchanged in support of these functions are enumerated along with 609 guidelines as appropriate. Specific interface functions for 610 consideration are as follows. 612 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 614 4.1. Network Interconnection Transport and Security Guidelines 616 The term "Network Interconnection Transport" refers to the 617 interconnection points between the two Administrative Domains. The 618 following is a representative set of attributes that will need to be 619 agreed to between the two administrative domains to support 620 multicast delivery. 622 o Number of Peering Points. 624 o Peering Point Addresses and Locations. 626 o Connection Type - Dedicated for Multicast delivery or shared with 627 other services. 629 o Connection Mode - Direct connectivity between the two AD's or via 630 another ISP. 632 o Peering Point Protocol Support - Multicast protocols that will be 633 used for multicast delivery will need to be supported at these 634 points. Examples of protocols include eBGP [RFC4271] and MBGP 635 [RFC4271]. 637 o Bandwidth Allocation - If shared with other services, then there 638 needs to be a determination of the share of bandwidth reserved 639 for multicast delivery. When determining the appropriate 640 bandwidth allocation, parties should consider that design of a 641 multicast protocol suitable for live video streaming which is 642 consistent with Congestion Control Principles [BCP41], especially 643 in the presence of potentially malicious receivers, is still an 644 open research problem. 646 o QoS Requirements - Delay/latency specifications that need to be 647 specified in an SLA. 649 o AD Roles and Responsibilities - the role played by each AD for 650 provisioning and maintaining the set of peering points to support 651 multicast delivery. 653 4.2. Routing Aspects and Related Guidelines 655 The main objective for multicast delivery routing is to ensure that 656 the End User receives the multicast stream from the "most optimal" 657 source [INF_ATIS_10] which typically: 659 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 661 o Maximizes the multicast portion of the transport and minimizes 662 any unicast portion of the delivery, and 664 o Minimizes the overall combined network(s) route distance. 666 This routing objective applies to both Native and AMT; the actual 667 methodology of the solution will be different for each. Regardless, 668 the routing solution is expected to be: 670 o Scalable, 672 o Avoid/minimize new protocol development or modifications, and 674 o Be robust enough to achieve high reliability and automatically 675 adjust to changes/problems in the multicast infrastructure. 677 For both Native and AMT environments, having a source as close as 678 possible to the EU network is most desirable; therefore, in some 679 cases, an AD may prefer to have multiple sources near different 680 peering points, but that is entirely an implementation issue. 682 4.2.1 Native Multicast Routing Aspects 684 Native multicast simply requires that the Administrative Domains 685 coordinate and advertise the correct source address(es) at their 686 network interconnection peering points(i.e., border routers). An 687 example of multicast delivery via a Native Multicast process across 688 two administrative Domains is as follows assuming that the 689 interconnecting peering points are also multicast enabled: 691 o Appropriate information is obtained by the EU client who is a 692 subscriber to AD-2 (see Use Case 3.1). This information is in 693 the form of metadata and it contains instructions directing the 694 EU client to launch an appropriate application if necessary, and 695 also additional information for the application about the source 696 location and the group (or stream) id in the form of the "S,G" 697 data. The "S" portion provides the name or IP address of the 698 source of the multicast stream. The metadata may also contain 699 alternate delivery information such as specifying the unicast 700 address of the stream. 702 o The client uses the join message with S,G to join the multicast 703 stream [RFC4604]. 705 To facilitate this process, the two AD's need to do the following: 707 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 709 o Advertise the source id(s) over the Peering Points. 711 o Exchange relevant Peering Point information such as Capacity and 712 Utilization. 714 o Implement compatible multicast protocols to ensure proper 715 multicast delivery across the peering points. 717 4.2.2 GRE Tunnel over Interconnecting Peering Point 719 If the interconnecting peering point is not multicast enabled and 720 both ADs are multicast enabled, then a simple solution is to 721 provision a GRE tunnel between the two ADs - see Use Case 3.2.2. 722 The termination points of the tunnel will usually be a network 723 engineering decision, but generally will be between the border 724 routers or even between the AD 2 border router and the AD 1 source 725 (or source access router). The GRE tunnel would allow end-to-end 726 native multicast or AMT multicast to traverse the interface. 727 Coordination and advertisement of the source IP is still required. 729 The two AD's need to follow the same process as described in 4.2.1 730 to facilitate multicast delivery across the Peering Points. 732 4.2.3 Routing Aspects with AMT Tunnels 734 Unlike Native (with or without GRE), an AMT Multicast environment is 735 more complex. It presents a dual layered problem because there are 736 two criteria that should be simultaneously met: 738 o Find the closest AMT relay to the end-user that also has 739 multicast connectivity to the content source, and 741 o Minimize the AMT unicast tunnel distance. 743 There are essentially two components to the AMT specification: 745 o AMT Relays: These serve the purpose of tunneling UDP multicast 746 traffic to the receivers (i.e., End Points). The AMT Relay will 747 receive the traffic natively from the multicast media source and 748 will replicate the stream on behalf of the downstream AMT 749 Gateways, encapsulating the multicast packets into unicast 750 packets and sending them over the tunnel toward the AMT Gateway. 751 In addition, the AMT Relay may perform various usage and 752 activity statistics collection. This results in moving the 753 replication point closer to the end user, and cuts down on 755 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 757 traffic across the network. Thus, the linear costs of adding 758 unicast subscribers can be avoided. However, unicast replication 759 is still required for each requesting endpoint within the 760 unicast-only network. 762 o AMT Gateway (GW): The Gateway will reside on an on End-Point - 763 this may be a Personal Computer (PC) or a Set Top Box (STB). The 764 AMT Gateway receives join and leave requests from the 765 Application via an Application Programming Interface (API). In 766 this manner, the Gateway allows the endpoint to conduct itself 767 as a true Multicast End-Point. The AMT Gateway will encapsulate 768 AMT messages into UDP packets and send them through a tunnel 769 (across the unicast-only infrastructure) to the AMT Relay. 771 The simplest AMT Use Case (section 3.3) involves peering points that 772 are not multicast enabled between two multicast enabled ADs. An AMT 773 tunnel is deployed between an AMT Relay on the AD 1 side of the 774 peering point and an AMT Gateway on the AD 2 side of the peering 775 point. One advantage to this arrangement is that the tunnel is 776 established on an as needed basis and need not be a provisioned 777 element. The two ADs can coordinate and advertise special AMT Relay 778 Anycast addresses with each other - though they may alternately 779 decide to simply provision Relay addresses, though this would not be 780 an optimal solution in terms of scalability. 782 Use Cases 3.4 and 3.5 describe more complicated AMT situations as 783 AD-2 is not multicast enabled. For these cases, the End User device 784 needs to be able to setup an AMT tunnel in the most optimal manner. 785 There are many methods by which relay selection can be done 786 including the use of DNS based queries and static lookup tables 787 [RFC7450]. The choice of the method is implementation dependent and 788 is up to the network operators. Comparison of various methods is out 789 of scope for this document; it is for further study. 791 An illustrative example of a relay selection based on DNS queries 792 and Anycast IP addresses process for Use Cases 3.4 and 3.5 is 793 described here. Using an Anycast IP address for AMT Relays allows 794 for all AMT Gateways to find the "closest" AMT Relay - the nearest 795 edge of the multicast topology of the source. Note that this is 796 strictly illustrative; the choice of the method is up to the network 797 operators. The basic process is as follows: 799 o Appropriate metadata is obtained by the EU client application. The 800 metadata contains instructions directing the EU client to an 801 ordered list of particular destinations to seek the requested 802 stream and, for multicast, specifies the source location and the 803 group (or stream) ID in the form of the "S,G" data. The "S" 805 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 807 portion provides the URI (name or IP address) of the source of the 808 multicast stream and the "G" identifies the particular stream 809 originated by that source. The metadata may also contain alternate 810 delivery information such as the address of the unicast form of 811 the content to be used, for example, if the multicast stream 812 becomes unavailable. 814 o Using the information from the metadata, and possibly information 815 provisioned directly in the EU client, a DNS query is initiated in 816 order to connect the EU client/AMT Gateway to an AMT Relay. 818 o Query results are obtained, and may return an Anycast address or a 819 specific unicast address of a relay. Multiple relays will 820 typically exist. The Anycast address is a routable "pseudo- 821 address" shared among the relays that can gain multicast access to 822 the source. 824 o If a specific IP address unique to a relay was not obtained, the 825 AMT Gateway then sends a message (e.g., the discovery message) to 826 the Anycast address such that the network is making the routing 827 choice of particular relay - e.g., closest relay to the EU. (Note 828 that in IPv6 there is a specific Anycast format and Anycast is 829 inherent in IPv6 routing, whereas in IPv4 Anycast is handled via 830 provisioning in the network. Details are out of scope for this 831 document.) 833 o The contacted AMT Relay then returns its specific unicast IP 834 address (after which the Anycast address is no longer required). 835 Variations may exist as well. 837 o The AMT Gateway uses that unicast IP address to initiate a three- 838 way handshake with the AMT Relay. 840 o AMT Gateway provides "S,G" to the AMT Relay (embedded in AMT 841 protocol messages). 843 o AMT Relay receives the "S,G" information and uses the S,G to join 844 the appropriate multicast stream, if it has not already subscribed 845 to that stream. 847 o AMT Relay encapsulates the multicast stream into the tunnel 848 between the Relay and the Gateway, providing the requested content 849 to the EU. 851 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 853 4.3. Back Office Functions - Provisioning and Logging Guidelines 855 Back Office refers to the following: 857 o Servers and Content Management systems that support the delivery 858 of applications via multicast and interactions between ADs. 859 o Functionality associated with logging, reporting, ordering, 860 provisioning, maintenance, service assurance, settlement, etc. 862 4.3.1 Provisioning Guidelines 864 Resources for basic connectivity between ADs Providers need to be 865 provisioned as follows: 867 o Sufficient capacity must be provisioned to support multicast-based 868 delivery across ADs. 869 o Sufficient capacity must be provisioned for connectivity between 870 all supporting back-offices of the ADs as appropriate. This 871 includes activating proper security treatment for these back- 872 office connections (gateways, firewalls, etc) as appropriate. 873 o Routing protocols as needed, e.g. configuring routers to support 874 these. 876 Provisioning aspects related to Multicast-Based inter-domain 877 delivery are as follows. 879 The ability to receive requested application via multicast is 880 triggered via receipt of the necessary metadata. Hence, this 881 metadata must be provided to the EU regarding multicast URL - and 882 unicast fallback if applicable. AD-2 must enable the delivery of 883 this metadata to the EU and provision appropriate resources for this 884 purpose. 886 Native multicast functionality is assumed to be available across 887 many ISP backbones, peering and access networks. If however, native 888 multicast is not an option (Use Cases 3.4 and 3.5), then: 890 o EU must have multicast client to use AMT multicast obtained either 891 from Application Source (per agreement with AD-1) or from AD-1 or 892 AD-2 (if delegated by the Application Source). 893 o If provided by AD-1/AD-2, then the EU could be redirected to a 894 client download site (note: this could be an Application Source 895 site). If provided by the Application Source, then this Source 897 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 899 would have to coordinate with AD-1 to ensure the proper client is 900 provided (assuming multiple possible clients). 901 o Where AMT Gateways support different application sets, all AD-2 902 AMT Relays need to be provisioned with all source & group 903 addresses for streams it is allowed to join. 904 o DNS across each AD must be provisioned to enable a client GW to 905 locate the optimal AMT Relay (i.e. longest multicast path and 906 shortest unicast tunnel) with connectivity to the content's 907 multicast source. 909 Provisioning Aspects Related to Operations and Customer Care are 910 stated as follows. 912 Each AD provider is assumed to provision operations and customer 913 care access to their own systems. 915 AD-1's operations and customer care functions must have visibility 916 to what is happening in AD-2's network or to the service provided by 917 AD-2, sufficient to verify their mutual goals and operations, e.g. 918 to know how the EU's are being served. This can be done in two ways: 920 o Automated interfaces are built between AD-1 and AD-2 such that 921 operations and customer care continue using their own systems. This 922 requires coordination between the two AD's with appropriate 923 provisioning of necessary resources. 924 o AD-1's operations and customer care personnel are provided access 925 directly to AD-2's system. In this scenario, additional provisioning 926 in these systems will be needed to provide necessary access. 927 Additional provisioning must be agreed to by the two AD-2s to support 928 this option. 930 4.3.2 Application Accounting Guidelines 932 All interactions between pairs of ADs can be discovered and/or be 933 associated with the account(s) utilized for delivered applications. 934 Supporting guidelines are as follows: 936 o A unique identifier is recommended to designate each master 937 account. 938 o AD-2 is expected to set up "accounts" (logical facility generally 939 protected by login/password/credentials) for use by AD-1. Multiple 940 accounts and multiple types/partitions of accounts can apply, e.g. 941 customer accounts, security accounts, etc. 943 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 945 4.3.3 Log Management Guidelines 947 Successful delivery of applications via multicast between pairs of 948 interconnecting ADs requires that appropriate logs will be exchanged 949 between them in support. Associated guidelines are as follows. 951 AD-2 needs to supply logs to AD-1 per existing contract(s). Examples 952 of log types include the following: 954 o Usage information logs at aggregate level. 955 o Usage failure instances at an aggregate level. 956 o Grouped or sequenced application access. 957 performance/behavior/failure at an aggregate level to support 958 potential Application Provider-driven strategies. Examples of 959 aggregate levels include grouped video clips, web pages, and sets 960 of software download. 961 o Security logs, aggregated or summarized according to agreement 962 (with additional detail potentially provided during security 963 events, by agreement). 964 o Access logs (EU), when needed for troubleshooting. 965 o Application logs (what is the application doing), when needed for 966 shared troubleshooting. 967 o Syslogs (network management), when needed for shared 968 troubleshooting. 970 The two ADs may supply additional security logs to each other as 971 agreed to by contract(s). Examples include the following: 973 o Information related to general security-relevant activity which 974 may be of use from a protective or response perspective, such as 975 types and counts of attacks detected, related source information, 976 related target information, etc. 977 o Aggregated or summarized logs according to agreement (with 978 additional detail potentially provided during security events, by 979 agreement). 981 4.4. Operations - Service Performance and Monitoring Guidelines 983 Service Performance refers to monitoring metrics related to 984 multicast delivery via probes. The focus is on the service provided 985 by AD-2 to AD-1 on behalf of all multicast application sources 986 (metrics may be specified for SLA use or otherwise). Associated 987 guidelines are as follows: 989 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 991 o Both AD's are expected to monitor, collect, and analyze service 992 performance metrics for multicast applications. AD-2 provides 993 relevant performance information to AD-1; this enables AD-1 to 994 create an end-to-end performance view on behalf of the multicast 995 application source. 997 o Both AD's are expected to agree on the type of probes to be used 998 to monitor multicast delivery performance. For example, AD-2 may 999 permit AD-1's probes to be utilized in the AD-2 multicast service 1000 footprint. Alternately, AD-2 may deploy its own probes and relay 1001 performance information back to AD-1. 1003 o In the event of performance degradation (SLA violation), AD-1 may 1004 have to compensate the multicast application source per SLA 1005 agreement. As appropriate, AD-1 may seek compensation from AD-2 1006 if the cause of the degradation is in AD-2's network. 1008 Service Monitoring generally refers to a service (as a whole) 1009 provided on behalf of a particular multicast application source 1010 provider. It thus involves complaints from End Users when service 1011 problems occur. EU's direct their complaints to the source provider; 1012 in turn the source provider submits these complaints to AD-1. The 1013 responsibility for service delivery lies with AD-1; as such AD-1 1014 will need to determine where the service problem is occurring - its 1015 own network or in AD-2. It is expected that each AD will have tools 1016 to monitor multicast service status in its own network. 1018 o Both AD's will determine how best to deploy multicast service 1019 monitoring tools. Typically, each AD will deploy its own set of 1020 monitoring tools; in which case, both AD's are expected to inform 1021 each other when multicast delivery problems are detected. 1023 o AD-2 may experience some problems in its network. For example, 1024 for the AMT Use Cases, one or more AMT Relays may be experiencing 1025 difficulties. AD-2 may be able to fix the problem by rerouting 1026 the multicast streams via alternate AMT Relays. If the fix is not 1027 successful and multicast service delivery degrades, then AD-2 1028 needs to report the issue to AD-1. 1030 o When problem notification is received from a multicast 1031 application source, AD-1 determines whether the cause of the 1032 problem is within its own network or within the AD-2 domain. If 1033 the cause is within the AD-2 domain, then AD-1 supplies all 1035 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1037 necessary information to AD-2. Examples of supporting information 1038 include the following: 1040 o Kind of problem(s). 1042 o Starting point & duration of problem(s). 1044 o Conditions in which problem(s) occur. 1046 o IP address blocks of affected users. 1048 o ISPs of affected users. 1050 o Type of access e.g., mobile versus desktop. 1052 o Locations of affected EUs. 1054 o Both AD's conduct some form of root cause analysis for multicast 1055 service delivery problems. Examples of various factors for 1056 consideration include: 1058 o Verification that the service configuration matches the 1059 product features. 1061 o Correlation and consolidation of the various customer 1062 problems and resource troubles into a single root service 1063 problem. 1065 o Prioritization of currently open service problems, giving 1066 consideration to problem impact, service level agreement, 1067 etc. 1069 o Conduction of service tests, including one time tests or a 1070 series of tests over a period of time. 1072 o Analysis of test results. 1074 o Analysis of relevant network fault or performance data. 1076 o Analysis of the problem information provided by the customer 1077 (CP). 1079 o Once the cause of the problem has been determined and the problem 1080 has been fixed, both AD's need to work jointly to verify and 1081 validate the success of the fix. 1083 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1085 o Faults in service could lead to SLA violation for which the 1086 multicast application source provider may have to be compensated 1087 by AD-1. Subsequently, AD-1 may have to be compensated by AD-2 1088 based on the contract. 1090 4.5. Client Reliability Models/Service Assurance Guidelines 1092 There are multiple options for instituting reliability 1093 architectures, most are at the application level. Both AD's should 1094 work those out with their contract/agreement and with the multicast 1095 application source providers. 1097 Network reliability can also be enhanced by the two AD's by 1098 provisioning alternate delivery mechanisms via unicast means. 1100 5. Troubleshooting and Diagnostics 1102 Any service provider supporting multicast delivery of content should 1103 have the capability to collect diagnostics as part of multicast 1104 troubleshooting practices and resolve network issues accordingly. 1105 Issues may become apparent or identified either through network 1106 monitoring functions or by customer reported problems as described 1107 in section 4.4. 1109 It is expected that multicast diagnostics will be collected 1110 according to currently established practices [MDH-04]. However, 1111 given that inter-domain creates a significant interdependence of 1112 proper networking functionality between providers there does exist a 1113 need for providers to be able to signal/alert each other if there 1114 are any issues noted by either one. 1116 Service providers may also wish to allow limited read-only 1117 administrative access to their routers via a looking-glass style 1118 router proxy to facilitate the debugging of multicast control state 1119 and peering status. Software implementations for this purpose is 1120 readily available [Traceroute], [draft-MTraceroute] and can be 1121 easily extended to provide access to commonly-used multicast 1122 troubleshooting commands in a secure manner. 1124 The specifics of the notification and alerts are beyond the scope of 1125 this document, but general guidelines are similar to those described 1126 in section 4.4 (Service Performance and Monitoring). Some general 1127 communications issues are stated as follows. 1129 o Appropriate communications channels will be established between 1130 the customer service and operations groups from both AD's to 1132 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1134 facilitate information sharing related to diagnostic 1135 troubleshooting. 1137 o A default resolution period may be considered to resolve open 1138 issues. Alternately, mutually acceptable resolution periods 1139 could be established depending on the severity of the 1140 identified trouble. 1142 6. Security Considerations 1144 From a security perspective, normal security procedures are expected 1145 to be followed by each AD to facilitate multicast delivery to 1146 registered and authenticated end users. Additionally: 1148 o Encryption - Peering point links may be encrypted per agreement 1149 if dedicated for multicast delivery. 1151 o Security Breach Mitigation Plan - In the event of a security 1152 breach, the two AD's are expected to have a mitigation plan for 1153 shutting down the peering point and directing multicast traffic 1154 over alternated peering points. It is also expected that 1155 appropriate information will be shared for the purpose of securing 1156 the identified breach. 1158 DRM and Application Accounting, Authorization and Authentication 1159 should be the responsibility of the multicast application source 1160 provider and/or AD-1. AD-1 needs to work out the appropriate 1161 agreements with the source provider. 1163 Network has no DRM responsibilities, but might have authentication 1164 and authorization obligations. These though are consistent with 1165 normal operations of a CDN to insure end user reliability, security 1166 and network security. 1168 AD-1 and AD-2 should have mechanisms in place to ensure proper 1169 accounting for the volume of bytes delivered through the peering 1170 point and separately the number of bytes delivered to EUs. For 1171 example, [BCP38] style filtering could be deployed by both AD's to 1172 ensure that only legitimately sourced multicast content is exchanged 1173 between them. 1175 Authentication and authorization of EU to receive multicast content 1176 is done at the application layer between the client application and 1177 the source. This may involve some kind of token authentication and 1178 is done at the application layer independently of the two AD's. If 1179 there are problems related to failure of token authentication when 1181 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1183 end-users are supported by AD-2, then some means of validating 1184 proper working of the token authentication process (e.g., back-end 1185 servers querying the multicast application source provider's token 1186 authentication server are communicating properly) should be 1187 considered. Implementation details are beyond the scope of this 1188 document. 1190 7. IANA Considerations 1192 No considerations identified in this document 1194 8. Conclusions 1196 This Best Current Practice document provides detailed Use Case 1197 scenarios for the transmission of applications via multicast across 1198 peering points between two Administrative Domains. A detailed set of 1199 guidelines supporting the delivery is provided for all Use Cases. 1201 For Use Cases involving AMT tunnels (cases 3.4 and 3.5), it is 1202 recommended that proper procedures are implemented such that the 1203 various AMT Gateways (at the End User devices and the AMT nodes in 1204 AD-2) are able to find the correct AMT Relay in other AMT nodes as 1205 appropriate. Section 4.3 provides an overview of one method that 1206 finds the optimal Relay-Gateway combination via the use of an 1207 Anycast IP address for AMT Relays. 1209 9. References 1211 9.1. Normative References 1213 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 1214 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 1216 [RFC3376] B. Cain, et al, "Internet Group Management Protocol, 1217 Version 3", RFC 3376, October 2002 1219 [RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol", 1220 RFC 3618, October 2003 1222 [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery 1223 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004 1225 [RFC4271] Y. Rekhter, et al, "A Border Gateway Protocol 4 (BGP-4)", 1226 RFC 4271, January 2006 1228 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1230 [RFC4604] H. Holbrook, et al, "Using Internet Group Management 1231 Protocol Version 3 (IGMPv3) and Multicast Listener Discovery 1232 Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, 1233 August 2006 1235 [RFC4609] P. Savola, et al, "Protocol Independent Multicast - Sparse 1236 Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", 1237 RFC 4609, August 2006 1239 [RFC7450] G. Bumgardner, "Automatic Multicast Tunneling", RFC 7450, 1240 February 2015 1242 [RFC7761] B. Fenner, et al, "Protocol Independent Multicast - Sparse 1243 Mode (PIM-SM): Protocol Specification (Revised), RFC 7761, March 1244 2016 1246 [BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating 1247 Denial of Service Attacks which employ IP Source Address Spoofing", 1248 BCP: 38, May 2000 1250 [BCP41] S. Floyd, "Congestion Control Principles", BCP 41, September 1251 2000 1253 9.2. Informative References 1255 [INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a 1256 Multi-Party Federation Environment", ATIS Standard A-0200010, 1257 December 2012 1259 [MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D 1260 draft-ietf-mboned-mdh-04.txt, May 2000 1262 [Traceroute] http://traceroute.org/#source%20code 1264 [draft-MTraceroute] H. Asaeda, K, Meyer, and W. Lee, "Mtrace Version 1265 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace- 1266 v2-16, October 2016, work in progress 1268 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1270 10. Acknowledgments 1272 The authors would like to thank the following individuals for their 1273 suggestions, comments, and corrections: 1275 Mikael Abrahamsson 1277 Hitoshi Asaeda 1279 Dale Carder 1281 Tim Chown 1283 Leonard Giuliano 1285 Jake Holland 1287 Joel Jaeggli 1289 Albert Manfredi 1291 Stig Venaas 1293 IETF I-D Multicast Across Inter-Domain Peering Points February 2017 1295 Authors' Addresses 1297 Percy S. Tarapore 1298 AT&T 1299 Phone: 1-732-420-4172 1300 Email: tarapore@att.com 1302 Robert Sayko 1303 AT&T 1304 Phone: 1-732-420-3292 1305 Email: rs1983@att.com 1307 Greg Shepherd 1308 Cisco 1309 Phone: 1310 Email: shep@cisco.com 1312 Toerless Eckert 1313 Cisco 1314 Phone: 1315 Email: eckert@cisco.com 1317 Ram Krishnan 1318 Brocade 1319 Phone: 1320 Email: ramk@brocade.com