idnits 2.17.00 (12 Aug 2021) /tmp/idnits14297/draft-ietf-mboned-interdomain-peering-bcp-14.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 date (October 30, 2017) is 1657 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 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) == Outdated reference: A later version (-05) exists of draft-ietf-mboned-mdh-04 == Outdated reference: draft-ietf-mboned-mtrace-v2 has been published as RFC 8487 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBONED Working Group P. Tarapore, Ed. 3 Internet-Draft R. Sayko 4 Intended status: Best Current Practice AT&T 5 Expires: May 3, 2018 G. Shepherd 6 Cisco 7 T. Eckert, Ed. 8 Huawei 9 R. Krishnan 10 SupportVectors 11 October 30, 2017 13 Use of Multicast Across Inter-Domain Peering Points 14 draft-ietf-mboned-interdomain-peering-bcp-14 16 Abstract 18 This document examines the use of Source Specific Multicast (SSM) 19 across inter-domain peering points for a specified set of deployment 20 scenarios. The objective is to describe the setup process for 21 multicast-based delivery across administrative domains for these 22 scenarios and document supporting functionality to enable this 23 process. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 3, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Overview of Inter-domain Multicast Application Transport . . 5 61 3. Inter-domain Peering Point Requirements for Multicast . . . . 6 62 3.1. Native Multicast . . . . . . . . . . . . . . . . . . . . 7 63 3.2. Peering Point Enabled with GRE Tunnel . . . . . . . . . . 8 64 3.3. Peering Point Enabled with an AMT - Both Domains 65 Multicast Enabled . . . . . . . . . . . . . . . . . . . . 10 66 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 67 Enabled . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through 69 AD-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4. Functional Guidelines . . . . . . . . . . . . . . . . . . . . 16 71 4.1. Network Interconnection Transport Guidelines . . . . . . 16 72 4.1.1. Bandwidth Management . . . . . . . . . . . . . . . . 16 73 4.2. Routing Aspects and Related Guidelines . . . . . . . . . 18 74 4.2.1. Native Multicast Routing Aspects . . . . . . . . . . 19 75 4.2.2. GRE Tunnel over Interconnecting Peering Point . . . . 19 76 4.2.3. Routing Aspects with AMT Tunnels . . . . . . . . . . 20 77 4.2.4. Public Peering Routing Aspects . . . . . . . . . . . 22 78 4.3. Back Office Functions - Provisioning and Logging 79 Guidelines . . . . . . . . . . . . . . . . . . . . . . . 23 80 4.3.1. Provisioning Guidelines . . . . . . . . . . . . . . . 24 81 4.3.2. Interdomain Authentication Guidelines . . . . . . . . 25 82 4.3.3. Log Management Guidelines . . . . . . . . . . . . . . 26 83 4.4. Operations - Service Performance and Monitoring 84 Guidelines . . . . . . . . . . . . . . . . . . . . . . . 27 85 4.5. Client Reliability Models/Service Assurance Guidelines . 29 86 4.6. Application Accounting Guidelines . . . . . . . . . . . . 29 87 5. Troubleshooting and Diagnostics . . . . . . . . . . . . . . . 29 88 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 89 6.1. DoS attacks (against state and bandwidth) . . . . . . . . 30 90 6.2. Content Security . . . . . . . . . . . . . . . . . . . . 32 91 6.3. Peering Encryption . . . . . . . . . . . . . . . . . . . 34 92 6.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 34 93 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 96 10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 37 97 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 98 11.1. Normative References . . . . . . . . . . . . . . . . . . 39 99 11.2. Informative References . . . . . . . . . . . . . . . . . 40 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 102 1. Introduction 104 Content and data from several types of applications (e.g., live video 105 streaming, software downloads) are well suited for delivery via 106 multicast means. The use of multicast for delivering such content or 107 other data offers significant savings of utilization of resources in 108 any given administrative domain. End user demand for such content or 109 other data is growing. Often, this requires transporting the content 110 or other data across administrative domains via inter-domain peering 111 points. 113 The objective of this Best Current Practices document is twofold: 115 o Describe the technical process and establish guidelines for 116 setting up multicast-based delivery of application content or 117 other data across inter-domain peering points via a set of use 118 cases. 120 o Catalog all required information exchange between the 121 administrative domains to support multicast-based delivery. This 122 enables operators to initiate necessary processes to support 123 inter-domain peering with multicast. 125 The scope and assumptions for this document are as follows: 127 o Administrative Domain 1 (AD-1) sources content to one or more End 128 Users (EUs) in one or more Administrative Domain 2 (AD-2). AD-1 129 and AD-2 want to use IP multicast to allow supporting large and 130 growing EU populations with minimum amount of duplicated traffic 131 to send across network links. 133 o This document does not detail the case where EUs are 134 originating content. To support that additional service, it is 135 recommended to use some method (outside the scope of this 136 document) by which the content from EUs is transmitted to the 137 application in AD-1 that this document refers to as the 138 multicast source and let it send out the traffic as IP 139 multicast. From that point on, the descriptions in this 140 document apply, except that they are not complete because they 141 do not cover the transport or operational aspects of the leg 142 from EU to AD-1. 144 o This document does not detail the case where AD-1 and AD-2 are 145 not directly connected to each other but only via one or more 146 AD-3 (transit providers). The cases described in this document 147 where tunnels are used between AD-1 and AD-2 can be applied to 148 such scenarios, but SLA ("Service Level Agreement") control for 149 example would be different. Other additional issues will 150 likely exist as well in such scenarios. This is for further 151 study. 153 o For the purpose of this document, the term "peering point" refers 154 to a network connection ("link") between two administrative 155 network domains over which traffic is exchanged between them. 156 This is also referred to as a Network-to-Network Interface (NNI). 157 Unless otherwise noted, the peering point is assumed to be a 158 private peering point, where the network connection is a 159 physically or virtually isolated network connection solely between 160 AD-1 and AD-2. The other case is that of a broadcast peering 161 point which is a common option in public Internet Exchange Points 162 (IXP). See Section 4.2.2 for more details about that option. 164 o Administrative Domain 1 (AD-1) is enabled with native multicast. 165 A peering point exists between AD-1 and AD-2. 167 o It is understood that several protocols are available for this 168 purpose including PIM-SM and Protocol Independent Multicast - 169 Source Specific Multicast (PIM-SSM) [RFC7761], Internet Group 170 Management Protocol (IGMP) [RFC3376], and Multicast Listener 171 Discovery (MLD) [RFC3810]. 173 o As described in Section 2, the source IP address of the multicast 174 stream in the originating AD (AD-1) is known. Under this 175 condition, PIM-SSM use is beneficial as it allows the receiver's 176 upstream router to directly send a JOIN message to the source 177 without the need of invoking an intermediate Rendezvous Point 178 (RP). Use of SSM also presents an improved threat mitigation 179 profile against attack, as described in [RFC4609]. Hence, in the 180 case of inter-domain peering, it is recommended to use only SSM 181 protocols; the setup of inter- domain peering for ASM (Any-Source 182 Multicast) is not in scope for this document. 184 o The rest of the document assumes that PIM-SSM and BGP are used 185 across the peering point plus AMT and/or GRE according to 186 scenario. The use of other protocols is beyond the scope of this 187 document. 189 o An Automatic Multicast Tunnel (AMT) [RFC7450] is setup at the 190 peering point if either the peering point or AD-2 is not multicast 191 enabled. It is assumed that an AMT Relay will be available to a 192 client for multicast delivery. The selection of an optimal AMT 193 relay by a client is out of scope for this document. Note that 194 AMT use is necessary only when native multicast is unavailable in 195 the peering point (Use Case 3.3) or in the downstream 196 administrative domain (Use Cases 3.4, and 3.5). 198 o The collection of billing data is assumed to be done at the 199 application level and is not considered to be a networking issue. 200 The settlements process for end user billing and/or inter-provider 201 billing is out of scope for this document. 203 o Inter-domain network connectivity troubleshooting is only 204 considered within the context of a cooperative process between the 205 two domains. 207 This document also attempts to identify ways by which the peering 208 process can be improved. Development of new methods for improvement 209 is beyond the scope of this document. 211 2. Overview of Inter-domain Multicast Application Transport 213 A multicast-based application delivery scenario is as follows: 215 o Two independent administrative domains are interconnected via a 216 peering point. 218 o The peering point is either multicast enabled (end-to-end native 219 multicast across the two domains) or it is connected by one of two 220 possible tunnel types: 222 o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] allowing 223 multicast tunneling across the peering point, or 225 o An Automatic Multicast Tunnel (AMT) [RFC7450]. 227 o A service provider controls one or more application sources in 228 AD-1 which will send multicast IP packets via one or more (S,G)s 229 (multicast traffic flows, see Section 4.2.1 if you are unfamiliar 230 with IP multicast). It is assumed that the service being provided 231 is suitable for delivery via multicast (e.g. live video streaming 232 of popular events, software downloads to many devices, etc.), and 233 that the packet streams will carried by a suitable multicast 234 transport protocol. 236 o An End User (EU) controls a device connected to AD-2, which runs 237 an application client compatible with the service provider's 238 application source. 240 o The application client joins appropriate (S,G)s in order to 241 receive the data necessary to provide the service to the EU. The 242 mechanisms by which the application client learns the appropriate 243 (S,G)s are an implementation detail of the application, and are 244 out of scope for this document. 246 The assumption here is that AD-1 has ultimate responsibility for 247 delivering the multicast based service on behalf of the content 248 source(s). All relevant interactions between the two domains 249 described in this document are based on this assumption. 251 Note that domain 2 may be an independent network domain (e.g.: Tier 1 252 network operator domain). Alternately, domain 2 could also be an 253 Enterprise network domain operated by a single customer of AD-1. The 254 peering point architecture and requirements may have some unique 255 aspects associated with the Enterprise case. 257 The Use Cases describing various architectural configurations for the 258 multicast distribution along with associated requirements is 259 described in section 3. Unique aspects related to the Enterprise 260 network possibility will be described in this section. Section 4 261 contains a comprehensive list of pertinent information that needs to 262 be exchanged between the two domains in order to support functions to 263 enable the application transport. 265 Note that domain 2 may be an independent network domain (e.g., Tier 1 266 network operator domain). Alternately, domain 2 could also be an 267 Enterprise network domain operated by a single customer. 269 The Use Cases describing various architectural configurations for the 270 multicast distribution along with associated requirements is 271 described in Section 3. The peering point architecture and 272 requirements may have some unique aspects associated with the 273 Enterprise case. These unique aspects will also be described in 274 Section 3. Section 4 contains a comprehensive list of pertinent 275 information that needs to be exchanged between the two domains in 276 order to support functions to enable the application transport. 278 3. Inter-domain Peering Point Requirements for Multicast 280 The transport of applications using multicast requires that the 281 inter-domain peering point is enabled to support such a process. 282 There are five Use Cases for consideration in this document. 284 3.1. Native Multicast 286 This Use Case involves end-to-end Native Multicast between the two 287 administrative domains and the peering point is also native multicast 288 enabled - see Figure 1. 290 ------------------- ------------------- 291 / AD-1 \ / AD-2 \ 292 / (Multicast Enabled) \ / (Multicast Enabled) \ 293 / \ / \ 294 | +----+ | | | 295 | | | +------+ | | +------+ | +----+ 296 | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | 297 | | | +------+ | I1 | +------+ |I2 +----+ 298 \ +----+ / \ / 299 \ / \ / 300 \ / \ / 301 ------------------- ------------------- 303 AD = Administrative Domain (Independent Autonomous System) 304 AS = Application (e.g., Content) Multicast Source 305 BR = Border Router 306 I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) 307 I2 = AD-2 and EU Multicast Connection 309 Figure 1: Content Distribution via End to End Native Multicast 311 Advantages of this configuration are: 313 o Most efficient use of bandwidth in both domains. 315 o Fewer devices in the path traversed by the multicast stream when 316 compared to an AMT enabled peering point. 318 From the perspective of AD-1, the one disadvantage associated with 319 native multicast into AD-2 instead of individual unicast to every EU 320 in AD-2 is that it does not have the ability to count the number of 321 End Users as well as the transmitted bytes delivered to them. This 322 information is relevant from the perspective of customer billing and 323 operational logs. It is assumed that such data will be collected by 324 the application layer. The application layer mechanisms for 325 generating this information need to be robust enough such that all 326 pertinent requirements for the source provider and the AD operator 327 are satisfactorily met. The specifics of these methods are beyond 328 the scope of this document. 330 Architectural guidelines for this configuration are as follows: 332 a. Dual homing for peering points between domains is recommended as 333 a way to ensure reliability with full BGP table visibility. 335 b. If the peering point between AD-1 and AD-2 is a controlled 336 network environment, then bandwidth can be allocated accordingly 337 by the two domains to permit the transit of non- rate adaptive 338 multicast traffic. If this is not the case, then the multicast 339 traffic must support rate-adaption (see [BCP145]). 341 c. The sending and receiving of multicast traffic between two 342 domains is typically determined by local policies associated with 343 each domain. For example, if AD-1 is a service provider and AD-2 344 is an enterprise, then AD-1 may support local policies for 345 traffic delivery to, but not traffic reception from, AD-2. 346 Another example is the use of a policy by which AD-1 delivers 347 specified content to AD-2 only if such delivery has been accepted 348 by contract. 350 d. Relevant information on multicast streams delivered to End Users 351 in AD-2 is assumed to be collected by available capabilities in 352 the application layer. The precise nature and formats of the 353 collected information will be determined by directives from the 354 source owner and the domain operators. 356 3.2. Peering Point Enabled with GRE Tunnel 358 The peering point is not native multicast enabled in this Use Case. 359 There is a Generic Routing Encapsulation Tunnel provisioned over the 360 peering point. See Figure 2. 362 ------------------- ------------------- 363 / AD-1 \ / AD-2 \ 364 / (Multicast Enabled) \ / (Multicast Enabled) \ 365 / \ / \ 366 | +----+ +---+ | (I1) | +---+ | 367 | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ 368 | | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU | 369 | | | +--+ <.......|........|........>+--+ |I2 +----+ 370 \ +----+ / I1 \ / 371 \ / GRE \ / 372 \ / Tunnel \ / 373 ------------------- ------------------- 375 AD = Administrative Domain (Independent Autonomous System) 376 AS = Application (e.g., Content) Multicast Source 377 uBR = unicast Border Router - not necessarily multicast enabled 378 may be the same router as BR 379 BR = Border Router - for multicast 380 I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) 381 I2 = AD-2 and EU Multicast Connection 383 Figure 2: Content Distribution via GRE Tunnel 385 In this case, the interconnection I1 between AD-1 and AD-2 in 386 Figure 2 is multicast enabled via a Generic Routing Encapsulation 387 Tunnel (GRE) [RFC2784] between the two BR and encapsulating the 388 multicast protocols across it. 390 Normally, this approach is choosen if the uBR physcially connected to 391 the peering link can or should not be enabled for IP multicast. This 392 approach may also be beneficial if BR and uBR are the same device, 393 but the peering link is a broadcast domain (IXP), see Figure 6. 395 The routing configuration is basically unchanged: Instead of BGP 396 (SAFI2) across the native IP multicast link between AD-1 and AD-2, 397 BGP (SAFI2) is now run across the GRE tunnel. 399 Advantages of this configuration: 401 o Highly efficient use of bandwidth in both domains, although not as 402 efficient as the fully native multicast Use Case. 404 o Fewer devices in the path traversed by the multicast stream when 405 compared to an AMT enabled peering point. 407 o Ability to support partial and/or incremental IP multicast 408 deployments in AD- 1 and/or AD-2: Only the path(s) between AS/BR 409 (AD-1) and BR/EU (AD-2) need to be multicast enabled. The uBRs 410 may not support IP multicast or enabling it could be seen as 411 operationally risky on that important edge node whereas dedicated 412 BR nodes for IP multicast may be more acceptable at least 413 initially. BR can also be located such that only parts of the 414 domain may need to support native IP multicast (e.g.: only the 415 core in AD-1 but not edge networks towards uBR). 417 o GRE is an existing technology and is relatively simple to 418 implement. 420 Disadvantages of this configuration: 422 o Per Use Case 3.1, current router technology cannot count the 423 number of end users or the number bytes transmitted. 425 o GRE tunnel requires manual configuration. 427 o The GRE must be established prior to stream starting. 429 o The GRE tunnel is often left pinned up. 431 Architectural guidelines for this configuration include the 432 following: 434 Guidelines (a) through (d) are the same as those described in Use 435 Case 3.1. Two additional guidelines are as follows: 437 e. GRE tunnels are typically configured manually between peering 438 points to support multicast delivery between domains. 440 f. It is recommended that the GRE tunnel (tunnel server) 441 configuration in the source network is such that it only 442 advertises the routes to the application sources and not to the 443 entire network. This practice will prevent unauthorized delivery 444 of applications through the tunnel (e.g., if application - e.g., 445 content - is not part of an agreed inter-domain partnership). 447 3.3. Peering Point Enabled with an AMT - Both Domains Multicast Enabled 449 Both administrative domains in this Use Case are assumed to be native 450 multicast enabled here; however, the peering point is not. 452 The peering point is enabled with an Automatic Multicast Tunnel. The 453 basic configuration is depicted in Figure 2. 455 ------------------- ------------------- 456 / AD-1 \ / AD-2 \ 457 / (Multicast Enabled) \ / (Multicast Enabled) \ 458 / \ / \ 459 | +----+ +---+ | I1 | +---+ | 460 | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ 461 | | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU | 462 | | | +--+ <.......|........|........>+--+ |I2 +----+ 463 \ +----+ / AMT \ / 464 \ / Tunnel \ / 465 \ / \ / 466 ------------------- ------------------- 468 AD = Administrative Domain (Independent Autonomous System) 469 AS = Application (e.g., Content) Multicast Source 470 AR = AMT Relay 471 AG = AMT Gateway 472 uBR = unicast Border Router - not multicast enabled 473 otherwise AR=uBR (AD-1), uBR=AG (AD-2) 474 I1 = AMT Interconnection between AD-1 and AD-2 475 I2 = AD-2 and EU Multicast Connection 477 Figure 3: - AMT Interconnection between AD-1 and AD-2 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 the 487 peering point. 489 o Ability to serve clients and servers with differing policies. 491 Disadvantages of this configuration: 493 o Per Use Case 3.1 (AD-2 is native multicast), current router 494 technology cannot count the number of end users or the number of 495 bytes transmitted to all end users. 497 o Additional devices (AMT Gateway and Relay pairs) may be introduced 498 into the path if these services are not incorporated in the 499 existing routing nodes. 501 o Currently undefined mechanisms for the AG to automatically select 502 the optimal AR. 504 Architectural guidelines for this configuration are as follows: 506 Guidelines (a) through (d) are the same as those described in Use 507 Case 3.1. In addition, 509 e. It is recommended that AMT Relay and Gateway pairs be configured 510 at the peering points to support multicast delivery between 511 domains. AMT tunnels will then configure dynamically across the 512 peering points once the Gateway in AD-2 receives the (S, G) 513 information from the EU. 515 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 517 In this AMT Use Case, the second administrative domain AD-2 is not 518 multicast enabled. Hence, the interconnection between AD-2 and the 519 End User is also not multicast enabled. This Use Case is depicted in 520 Figure 3. 522 ------------------- ------------------- 523 / AD-1 \ / AD-2 \ 524 / (Multicast Enabled) \ / (Non Multicast \ 525 / \ / Enabled) \ N(large) 526 | +----+ +---+ | | +---+ | #EU 527 | | | +--+ |uBR|-|--------|-|uBR| | +----+ 528 | | AS |-->|AR| +---+-| | +---+ ................>|EU/G| 529 | | | +--+ <.......|........|........... |I2 +----+ 530 \ +----+ / N x AMT\ / 531 \ / Tunnel \ / 532 \ / \ / 533 ------------------- ------------------- 535 AS = Application Multicast Source 536 uBR = unicast Border Router - not multicast enabled, 537 otherwise AR = uBR (in AD-1). 538 AR = AMT Relay 539 EU/G = Gateway client embedded in EU device 540 I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast 541 Enabled AD-2. 543 Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 545 This Use Case is equivalent to having unicast distribution of the 546 application through AD-2. The total number of AMT tunnels would be 547 equal to the total number of End Users requesting the application. 548 The peering point thus needs to accommodate the total number of AMT 549 tunnels between the two domains. Each AMT tunnel can provide the 550 data usage associated with each End User. 552 Advantages of this configuration: 554 o Efficient use of bandwidth in AD-1 (The closer AR is to uBR, the 555 more efficient). 557 o Ability for AD-1 to introduce IP multicast based content delivery 558 without any support by network devices in AD-2: Only application 559 side in the EU device needs to perform AMT gateway library 560 functionality to receive traffic from AMT relay. 562 o Allows for AD-2 to "upgrade" to Use Case 3.5 (see below) at a 563 later time without any change in AD-1 at that time. 565 o AMT is an existing technology and is relatively simple to 566 implement. Attractive properties of AMT include the following: 568 o Dynamic interconnection between Gateway-Relay pair across the 569 peering point. 571 o Ability to serve clients and servers with differing policies. 573 o Each AMT tunnel serves as a count for each End User and is also 574 able to track data usage (bytes) delivered to the EU. 576 Disadvantages of this configuration: 578 o Additional devices (AMT Gateway and Relay pairs) are introduced 579 into the transport path. 581 o Assuming multiple peering points between the domains, the EU 582 Gateway needs to be able to find the "correct" AMT Relay in AD-1. 584 Architectural guidelines for this configuration are as follows: 586 Guidelines (a) through (c) are the same as those described in Use 587 Case 3.1. 589 d. It is necessary that proper procedures are implemented such that 590 the AMT Gateway at the End User device is able to find the correct 591 AMT Relay for each (S,G) content stream. Standard mechanisms for 592 that selection are still subject to ongoing work. This includes 593 use of anycast gateway addresses, anycast DNS names, explicit 594 configuration that is mapping (S,G) to a relay address or letting 595 the application in the EU/G provide the relay address to the 596 embedded AMT gateway function. 598 e. The AMT tunnel capabilities are expected to be sufficient for the 599 purpose of collecting relevant information on the multicast 600 streams delivered to End Users in AD-2. 602 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 604 This is a variation of Use Case 3.4 as follows: 606 ------------------- ------------------- 607 / AD-1 \ / AD-2 \ 608 / (Multicast Enabled) \ / (Non Multicast \ 609 / +---+ \ (I1) / +---+ Enabled) \ 610 | +----+ |uBR|-|--------|-|uBR| | 611 | | | +--+ +---+ | | +---+ +---+ | +----+ 612 | | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G| 613 | | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+ 614 \ +----+ / I1 \ |AR1| I2 +---+ / 615 \ / single \+---+ / 616 \ / AMT Tunnel \ / 617 ------------------- ------------------- 619 uBR = unicast Border Router - not multicast enabled 620 otherwise AR=uBR (AD-1) or ubr=AGAR1 (AD-2) 621 AS = Application Source 622 AR = AMT Relay in AD-1 623 AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point 624 I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 625 AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge 626 I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 627 EU/G = Gateway client embedded in EU device 628 I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 630 Figure 5: AMT Tunnel Connecting AMT Relay and Relays 632 Use Case 3.4 results in several long AMT tunnels crossing the entire 633 network of AD-2 linking the EU device and the AMT Relay in AD-1 634 through the peering point. Depending on the number of End Users, 635 there is a likelihood of an unacceptably high amount of traffic due 636 to the large number of AMT tunnels - and unicast streams - through 637 the peering point. This situation can be alleviated as follows: 639 o Provisioning of strategically located AMT nodes in AD-2 AD-2. An 640 AMT node comprises co-location of an AMT Gateway and an AMT Relay. 641 No change is required by AD-1 compared to 3.4. This can be done 642 whenever AD-2 seems fit (too much traffic across peering point. 644 o One such node is at the AD-2 side of the peering point (node AGAR1 645 in above Figure). 647 o Single AMT tunnel established across peering point linking AMT 648 Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. 650 o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to 651 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 652 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 in 653 Figure 4. 655 o AMT tunnels linking EU device (via Gateway client embedded in 656 device) and AMT Relay in appropriate AMT node at edge of AD-2: 657 e.g., I3 linking EU Gateway in device to AMT Relay in AMT node 658 AGAR2. 660 o In the most simple option (not shown), AD-2 only deploys a single 661 AGAR1 and lets EU/G build AMT tunnels directly to it. This setup 662 already solves the problem of replicated traffic across the 663 peering point. As soon as there is need to support more AMT 664 tunnels to EU/G, then additional AGAR2 nodes can be deployed by 665 AD-2. 667 The advantage for such a chained set of AMT tunnels is that the total 668 number of unicast streams across AD-2 is significantly reduced, thus 669 freeing up bandwidth. Additionally, there will be a single unicast 670 stream across the peering point instead of possibly, an unacceptably 671 large number of such streams per Use Case 3.4. However, this implies 672 that several AMT tunnels will need to be dynamically configured by 673 the various AMT Gateways based solely on the (S,G) information 674 received from the application client at the EU device. A suitable 675 mechanism for such dynamic configurations is therefore critical. 677 Architectural guidelines for this configuration are as follows: 679 Guidelines (a) through (c) are the same as those described in Use 680 Case 3.1. 682 d. It is necessary that proper procedures are implemented such that 683 the various AMT Gateways (at the End User devices and the AMT 684 nodes in AD-2) are able to find the correct AMT Relay in other AMT 685 nodes as appropriate. Standard mechanisms for that selection are 686 still subject to ongoing work. This includes use of anycast 687 gateway addresses, anycast DNS names, or explicit configuration 688 that is mapping (S,G) to a relay address. On the EU/G, this 689 mapping information may come from the application. 691 e. The AMT tunnel capabilities are expected to be sufficient for the 692 purpose of collecting relevant information on the multicast 693 streams delivered to End Users in AD-2. 695 4. Functional Guidelines 697 Supporting functions and related interfaces over the peering point 698 that enable the multicast transport of the application are listed in 699 this section. Critical information parameters that need to be 700 exchanged in support of these functions are enumerated, along with 701 guidelines as appropriate. Specific interface functions for 702 consideration are as follows. 704 4.1. Network Interconnection Transport Guidelines 706 The term "Network Interconnection Transport" refers to the 707 interconnection points between the two Administrative Domains. The 708 following is a representative set of attributes that will need to be 709 agreed to between the two administrative domains to support multicast 710 delivery. 712 o Number of Peering Points. 714 o Peering Point Addresses and Locations. 716 o Connection Type - Dedicated for Multicast delivery or shared with 717 other services. 719 o Connection Mode - Direct connectivity between the two AD's or via 720 another ISP. 722 o Peering Point Protocol Support - Multicast protocols that will be 723 used for multicast delivery will need to be supported at these 724 points. Examples of protocols include eBGP [RFC4760] and MBGP 725 [RFC4760]. 727 o Bandwidth Allocation - If shared with other services, then there 728 needs to be a determination of the share of bandwidth reserved for 729 multicast delivery. See section 4.1.1 below for more details. 731 o QoS Requirements - Delay and/or latency specifications that need 732 to be specified in an SLA. 734 o AD Roles and Responsibilities - the role played by each AD for 735 provisioning and maintaining the set of peering points to support 736 multicast delivery. 738 4.1.1. Bandwidth Management 740 Like IP unicast traffic, IP multicast traffic carried across non- 741 controlled networks must comply to Congestion Control Principles as 742 described in [BCP41] and explained in detail for UDP IP multicast in 743 [BCP145]. 745 Non-controlled networks (such as the Internet) are those where there 746 is no policy for managing bandwidth other than best effort with fair 747 share of bandwidth under congestion. As a simplified rule of thumb, 748 complying to congestion control principles means to reduce bandwidth 749 under congestion in a way that is fair to competing competing 750 (typically TCP) flow ("rate adaptive"). 752 In many instances, multicast content delivery evolves from intra- 753 domain deployments where it is handled as a controlled network 754 service and of not complyng to congestion control principles. It was 755 given a reserved amount of bandwidth and admitted to the network so 756 that congestion never occurs. Therefore the congestion control issue 757 should be given specific attention when evolving to an interdomain 758 peering deployment. 760 In the case where end-to-end IP multicast traffic passes across the 761 network of two ADs (and their subsidiaries/customers), both ADs must 762 agree on a consistent traffic management policy. If for example AD-1 763 sources non congestion aware IP multicast traffic and AD-2 carries it 764 as best effort traffic across links shared with other Internet 765 traffic and subject to congestion, this will not work: Under 766 congestion, some amount of that traffic will be dropped, rendering 767 the remaining packets often as undecodeable garbage clogging up the 768 network in AD-2 and because this is not congestion aware, the loss 769 does not reduce this rate. Competing traffic will not get their fair 770 share under congestion, and EUs will be frusted by extremely bad 771 quality of both their IP multicast and other (e.g.: TCP) traffic. 772 Note that this is not an IP multicast technology issue, but solely a 773 transport/application layer issue: The problem would equally happen 774 if AD-1 would send non-rate adaptive unicast traffic,, for example 775 legacy IPTV video-on-demand traffic which typically is also non 776 congestion aware. Because rate adaption in IP unicast video is 777 commonplace today because of ABR (Adaptive Bitrate Video), it is very 778 unlikely for this to happen though in reality with IP unicast. 780 While the rules for traffic management apply whether or not IP 781 multicast is tunneled or not, the one feature that can make AMT 782 tunnels more difficult is the unpredictability of bandwidth 783 requirements across underlying links because of the way they can be 784 used: With native IP multicast or GRE tunnels, the amount of 785 bandwidth depends on the amount of content, not the number of EUs - 786 and is therefore easier to plan for. AMT tunnels terminating in EU/G 787 on the other hand scale with the number of EUs. In the vicinity of 788 the AMT relay they can introduce very large amount of replicated 789 traffic and it is not always feasible to provision enough bandwidth 790 for all possible EU to get the highest quality for all their content 791 during peak utilization in such setups - unless the AMT relays are 792 very close to the EU edge. Therefore it is also recommended to use 793 IP multicast rate adaptation even inside controlled networks when 794 using AMT tunnels directly to EU/G. 796 Note that rate-adaptive IP multicast traffic in general does not mean 797 that the sender is reducing the bitrate, but rather that the EUs that 798 experience congestion are joining to a lower bitrate (S,G) stream of 799 the content, similar to adaptive bitrate streaming over TCP. 800 Migration from non rate-adaptive to rate adaptive bitrate in IP 801 multicast does therefore also change the dynamic (S,G) join behavior 802 in the network resulting in potentially higher performance 803 requirement for IP multicast protocols (IGMP/PIM), especially on the 804 last hops where dynamic changes occur (including AMT gateway/relays): 805 In non rate-adaptive IP multicast, only "channel change" causes state 806 change, in rate-adaptive also the congestion situation causes state 807 change. 809 Even though not fully specified in this document, peerings that rely 810 on GRE/AMT tunnels may be across one or more transit ADs instead of 811 an exclusive (non-shared, L1/L2) path. Unless those transit ADs are 812 explicitly contracted to provide other than "best effort" transit for 813 the tunneled traffic, the IP multicast traffic tunneled must be rate 814 adaptive to not violate BCP41 across those transit ADs. 816 4.2. Routing Aspects and Related Guidelines 818 The main objective for multicast delivery routing is to ensure that 819 the End User receives the multicast stream from the "most optimal" 820 source [INF_ATIS_10] which typically: 822 o Maximizes the multicast portion of the transport and minimizes any 823 unicast portion of the delivery, and 825 o Minimizes the overall combined network(s) route distance. 827 This routing objective applies to both Native and AMT; the actual 828 methodology of the solution will be different for each. Regardless, 829 the routing solution is expected: 831 o To be scalable, 833 o To avoid or minimize new protocol development or modifications, 834 and 836 o To be robust enough to achieve high reliability and automatically 837 adjust to changes and problems in the multicast infrastructure. 839 For both Native and AMT environments, having a source as close as 840 possible to the EU network is most desirable; therefore, in some 841 cases, an AD may prefer to have multiple sources near different 842 peering points. However, that is entirely an implementation issue. 844 4.2.1. Native Multicast Routing Aspects 846 Native multicast simply requires that the Administrative Domains 847 coordinate and advertise the correct source address(es) at their 848 network interconnection peering points(i.e., border routers). An 849 example of multicast delivery via a Native Multicast process across 850 two Administrative Domains is as follows assuming that the 851 interconnecting peering points are also multicast enabled: 853 o Appropriate information is obtained by the EU client who is a 854 subscriber to AD-2 (see Use Case 3.1). This information is in the 855 form of metadata and it contains instructions directing the EU 856 client to launch an appropriate application if necessary, as well 857 as additional information for the application about the source 858 location and the group (or stream) id in the form of the "S,G" 859 data. The "S" portion provides the name or IP address of the 860 source of the multicast stream. The metadata may also contain 861 alternate delivery information such as specifying the unicast 862 address of the stream. 864 o The client uses the join message with S,G to join the multicast 865 stream [RFC4604]. To facilitate this process, the two AD's need 866 to do the following: 868 o Advertise the source id(s) over the Peering Points. 870 o Exchange relevant Peering Point information such as Capacity 871 and Utilization. 873 o Implement compatible multicast protocols to ensure proper 874 multicast delivery across the peering points. 876 4.2.2. GRE Tunnel over Interconnecting Peering Point 878 If the interconnecting peering point is not multicast enabled and 879 both AD's are multicast enabled, then a simple solution is to 880 provision a GRE tunnel between the two AD's - see Use Case 3.2.2. 881 The termination points of the tunnel will usually be a network 882 engineering decision, but generally will be between the border 883 routers or even between the AD 2 border router and the AD 1 source 884 (or source access router). The GRE tunnel would allow end-to-end 885 native multicast or AMT multicast to traverse the interface. 886 Coordination and advertisement of the source IP is still required. 888 The two AD's need to follow the same process as described in 4.2.1 to 889 facilitate multicast delivery across the Peering Points. 891 4.2.3. Routing Aspects with AMT Tunnels 893 Unlike Native Multicast (with or without GRE), an AMT Multicast 894 environment is more complex. It presents a dual layered problem 895 because there are two criteria that should be simultaneously met: 897 o Find the closest AMT relay to the end-user that also has multicast 898 connectivity to the content source, and 900 o Minimize the AMT unicast tunnel distance. 902 There are essentially two components to the AMT specification 904 AMT Relays: These serve the purpose of tunneling UDP multicast 905 traffic to the receivers (i.e., End-Points). The AMT Relay will 906 receive the traffic natively from the multicast media source and 907 will replicate the stream on behalf of the downstream AMT 908 Gateways, encapsulating the multicast packets into unicast packets 909 and sending them over the tunnel toward the AMT Gateway. In 910 addition, the AMT Relay may perform various usage and activity 911 statistics collection. This results in moving the replication 912 point closer to the end user, and cuts down on traffic across the 913 network. Thus, the linear costs of adding unicast subscribers can 914 be avoided. However, unicast replication is still required for 915 each requesting End-Point within the unicast-only network. 917 AMT Gateway (GW): The Gateway will reside on an End-Point - this 918 could be any type of IP host such as a Personal Computer (PC), 919 mobile phone, Set Top Box (STB) or appliances. The AMT Gateway 920 receives join and leave requests from the Application via an 921 Application Programming Interface (API). In this manner, the 922 Gateway allows the End-Point to conduct itself as a true Multicast 923 End-Point. The AMT Gateway will encapsulate AMT messages into UDP 924 packets and send them through a tunnel (across the unicast-only 925 infrastructure) to the AMT Relay. 927 The simplest AMT Use Case (section 3.3) involves peering points that 928 are not multicast enabled between two multicast enabled AD's. An AMT 929 tunnel is deployed between an AMT Relay on the AD 1 side of the 930 peering point and an AMT Gateway on the AD 2 side of the peering 931 point. One advantage to this arrangement is that the tunnel is 932 established on an as needed basis and need not be a provisioned 933 element. The two AD's can coordinate and advertise special AMT Relay 934 Anycast addresses with each other. Alternately, they may decide to 935 simply provision Relay addresses, though this would not be an optimal 936 solution in terms of scalability. 938 Use Cases 3.4 and 3.5 describe more complicated AMT situations as 939 AD-2 is not multicast enabled. For these cases, the End User device 940 needs to be able to setup an AMT tunnel in the most optimal manner. 941 There are many methods by which relay selection can be done including 942 the use of DNS based queries and static lookup tables [RFC7450]. The 943 choice of the method is implementation dependent and is up to the 944 network operators. Comparison of various methods is out of scope for 945 this document; it is for further study. 947 An illustrative example of a relay selection based on DNS queries and 948 Anycast IP addresses process for Use Cases 3.4 and 3.5 is described 949 here. Using an Anycast IP address for AMT Relays allows for all AMT 950 Gateways to find the "closest" AMT Relay - the nearest edge of the 951 multicast topology of the source. Note that this is strictly 952 illustrative; the choice of the method is up to the network 953 operators. The basic process is as follows: 955 o Appropriate metadata is obtained by the EU client application. 956 The metadata contains instructions directing the EU client to an 957 ordered list of particular destinations to seek the requested 958 stream and, for multicast, specifies the source location and the 959 group (or stream) ID in the form of the "S,G" data. The "S" 960 portion provides the URI (name or IP address) of the source of the 961 multicast stream and the "G" identifies the particular stream 962 originated by that source. The metadata may also contain 963 alternate delivery information such as the address of the unicast 964 form of the content to be used, for example, if the multicast 965 stream becomes unavailable. 967 o Using the information from the metadata, and possibly information 968 provisioned directly in the EU client, a DNS query is initiated in 969 order to connect the EU client/AMT Gateway to an AMT Relay. 971 o Query results are obtained, and may return an Anycast address or a 972 specific unicast address of a relay. Multiple relays will 973 typically exist. The Anycast address is a routable "pseudo- 974 address" shared among the relays that can gain multicast access to 975 the source. 977 o If a specific IP address unique to a relay was not obtained, the 978 AMT Gateway then sends a message (e.g., the discovery message) to 979 the Anycast address such that the network is making the routing 980 choice of particular relay - e.g., closest relay to the EU. 981 Details are outside the scope for this document. See [RFC4786]. 983 o The contacted AMT Relay then returns its specific unicast IP 984 address (after which the Anycast address is no longer required). 985 Variations may exist as well. 987 o The AMT Gateway uses that unicast IP address to initiate a three- 988 way handshake with the AMT Relay. 990 o AMT Gateway provides "S,G" to the AMT Relay (embedded in AMT 991 protocol messages). 993 o AMT Relay receives the "S,G" information and uses the S,G to join 994 the appropriate multicast stream, if it has not already subscribed 995 to that stream. 997 o AMT Relay encapsulates the multicast stream into the tunnel 998 between the Relay and the Gateway, providing the requested content 999 to the EU. 1001 4.2.4. Public Peering Routing Aspects 1003 AD-1a AD-1b 1004 BR BR 1005 | | 1006 --+-+---------------+-+-- broadcast peering point LAN 1007 | | 1008 BR BR 1009 AD-2a AD-2b 1011 Figure 6: Broadcast Peering Point 1013 A broadcast peering point is an L2 subnet connecting 3 or more ADs. 1014 It is common in IXPs and usually consists of ethernet switch(es) 1015 operated by the IXP connecting to BRs operated by the ADs. 1017 In an example setup domain AD-2a peers with AD-1a and wants to 1018 receive IP multicast from it. Likewise AD-2b peers with AD-1b and 1019 wants to receive IP multicast from it. 1021 Assume one or more IP multicast (S,G) traffic streams can be served 1022 by both AD-1a and AD-1b, for example because both AD-1a and AD-1b do 1023 contract this content from the same content source. 1025 In this case, AD-2a and AD-2b can not control anymore which upstream 1026 domain, AD-1a or AD-1b will forward this (S,G) into the LAN. AD-2a 1027 BR requests the (S,G) from AD-1a BR and AD-2b BR requests the same 1028 (S,G) from AD-1b BR. To avoid duplicate packets, an (S,G) can be 1029 forwarded by only one router onto the LAN, and PIM-SM/PIM-SSM detects 1030 requests for duplicate transmission and resolve it via the so-called 1031 "assert" protocol operation which results in only one BR forwarding 1032 the traffic. Assume this is AD-1a BR. AD-2b will then receive the 1033 multicast traffic unexpectedly from a provider with whom it does not 1034 have a mutual agreement for the traffic. Quality issues in EUs 1035 behind AD-2b caused by AD-1a will cause a lot of responsiblity and 1036 troubleshooting issues. 1038 In face of this technical issues, we describe the following options 1039 how IP multicast can be carried across broadcast peering point LANs: 1041 1. IP multicast is tunneled across the LAN. Any of the GRE/AMT 1042 tunneling solutions mentioned in this document are applicable. 1043 This is the one case where specifically a GRE tunnel between the 1044 upstream BR (e.g.: AD-1a) and downstream BR (e.g.: AD-2a) is 1045 recommended as opposed to tunneling across uBRs which are not the 1046 actual BRs. 1048 2. The LAN has only one upstream AD that is sourcing IP multicast 1049 and native IP multicast is used. This is an efficient way to 1050 distribute the same IP multicast content to multiple downstream 1051 ADs. Misbehaving downstream BRs can still disrupt the delivery 1052 of IP multicast from the upstream BR to other downstream BRs, 1053 therefore strict rules must be follow to prohibit that case. The 1054 downstream BRs must ensure that they will always consider only 1055 the upstream BR as a source for multicast traffic: e.g.: no BGP 1056 SAFI-2 peerings between the downstream ADs across the peering 1057 point LAN, so that only the upstream BR is the only possible 1058 next-hop reachable across this LAN. And routing policies 1059 configured to avoid fall back to the use of SAFI-1 (unicast) 1060 routes for IP multicast if unicast BGP peering is not limited in 1061 the same way. 1063 3. The LAN has multiple upstreams, but they are federated and agree 1064 on a consistent policy for IP multicast traffic across the LAN. 1065 One policy is that each possible source is only announced by one 1066 upstream BR. Another policy is that sources are redundantly 1067 announced (problematic case mentioned in above example), but the 1068 upstream domains also provide mutual operational insight to help 1069 troubleshooting (outside the scope of this document). 1071 4.3. Back Office Functions - Provisioning and Logging Guidelines 1073 Back Office refers to the following: 1075 o Servers and Content Management systems that support the delivery 1076 of applications via multicast and interactions between AD's. 1078 o Functionality associated with logging, reporting, ordering, 1079 provisioning, maintenance, service assurance, settlement, etc. 1081 4.3.1. Provisioning Guidelines 1083 Resources for basic connectivity between AD's Providers need to be 1084 provisioned as follows: 1086 o Sufficient capacity must be provisioned to support multicast-based 1087 delivery across AD's. 1089 o Sufficient capacity must be provisioned for connectivity between 1090 all supporting back-offices of the AD's as appropriate. This 1091 includes activating proper security treatment for these back- 1092 office connections (gateways, firewalls, etc) as appropriate. 1094 o Routing protocols as needed, e.g. configuring routers to support 1095 these. 1097 Provisioning aspects related to Multicast-Based inter-domain delivery 1098 are as follows. 1100 The ability to receive requested application via multicast is 1101 triggered via receipt of the necessary metadata. Hence, this 1102 metadata must be provided to the EU regarding multicast URL - and 1103 unicast fallback if applicable. AD-2 must enable the delivery of 1104 this metadata to the EU and provision appropriate resources for this 1105 purpose. 1107 Native multicast functionality is assumed to be available across many 1108 ISP backbones, peering and access networks. If, however, native 1109 multicast is not an option (Use Cases 3.4 and 3.5), then: 1111 o EU must have multicast client to use AMT multicast obtained either 1112 from Application Source (per agreement with AD-1) or from AD-1 or 1113 AD-2 (if delegated by the Application Source). 1115 o If provided by AD-1/AD-2, then the EU could be redirected to a 1116 client download site (note: this could be an Application Source 1117 site). If provided by the Application Source, then this Source 1118 would have to coordinate with AD-1 to ensure the proper client is 1119 provided (assuming multiple possible clients). 1121 o Where AMT Gateways support different application sets, all AD-2 1122 AMT Relays need to be provisioned with all source & group 1123 addresses for streams it is allowed to join. 1125 o DNS across each AD must be provisioned to enable a client GW to 1126 locate the optimal AMT Relay (i.e. longest multicast path and 1127 shortest unicast tunnel) with connectivity to the content's 1128 multicast source. 1130 Provisioning Aspects Related to Operations and Customer Care are 1131 stated as follows. 1133 Each AD provider is assumed to provision operations and customer care 1134 access to their own systems. 1136 AD-1's operations and customer care functions must have visibility to 1137 what is happening in AD-2's network or to the service provided by AD- 1138 2, sufficient to verify their mutual goals and operations, e.g. to 1139 know how the EU's are being served. This can be done in two ways: 1141 o Automated interfaces are built between AD-1 and AD-2 such that 1142 operations and customer care continue using their own systems. 1143 This requires coordination between the two AD's with appropriate 1144 provisioning of necessary resources. 1146 o AD-1's operations and customer care personnel are provided access 1147 directly to AD-2's system. In this scenario, additional 1148 provisioning in these systems will be needed to provide necessary 1149 access. Additional provisioning must be agreed to by the two AD's 1150 to support this option. 1152 4.3.2. Interdomain Authentication Guidelines 1154 All interactions between pairs of AD's can be discovered and/or be 1155 associated with the account(s) utilized for delivered applications. 1156 Supporting guidelines are as follows: 1158 o A unique identifier is recommended to designate each master 1159 account. 1161 o AD-2 is expected to set up "accounts" (logical facility generally 1162 protected by credentials such as login passwords) for use by AD-1. 1163 Multiple accounts and multiple types or partitions of accounts can 1164 apply, e.g. customer accounts, security accounts, etc. 1166 The reason to specifically mention the need for AD-1 to initiate 1167 interactions with AD-2 (and use some account for that), as opposed to 1168 the opposite direction is based on the recommended workflow initiated 1169 by customers (see Section 4.4): The customer contacts content source 1170 (part of AD-1), when AD-1 sees the need to propagate the issue, it 1171 will interact with AD-2 using the aforementioned guidelines. 1173 4.3.3. Log Management Guidelines 1175 Successful delivery (in terms of user experience) of applications or 1176 content via multicast between pairs of interconnecting AD's can be 1177 improved through the ability to exchange appropriate logs for various 1178 workflows - troubleshooting, accounting and billing, traffic and 1179 content transmission optimization, content and application 1180 development optimization and so on. 1182 The basic model as explained in before is that the content source and 1183 on its behalf AD-1 take over primary responsibility for customer 1184 experience and the AD-2's support this. The application/content 1185 owner is the only participant who has and needs full insight into the 1186 application level and can map the customer application experience to 1187 the network traffic flows - which it then with the help of AD-2 or 1188 logs from AD-2 can analyze and interpret. 1190 The main difference between unicast delivery and multicast delivery 1191 is that the content source can infer a lot more about downstream 1192 network problems from a unicasted stream than from a multicasted 1193 stream: The multicasted stream is not per-EU except after the last 1194 replication, which is in most cases not in AD-1. Logs from the 1195 application, including the receiver side at the EU, can provide 1196 insight, but can not help to fully isolate network problems because 1197 of the IP multicast per-application operational state built across 1198 AD-1 and AD-2 (aka: the (S,G) state and any other feature operational 1199 state such as DiffServ QoS). 1201 See Section 7 for more discussions about the privacy considerations 1202 of the model described here. 1204 Different type of logs are known to help support operations in AD-1 1205 when provided by AD-2. This could be done as part of AD-1/AD-2 1206 contracts. Note that except for implied multicast specific elements, 1207 the options listed here are not unique or novel for IP multicast, but 1208 they are more important for services novel to the operators than for 1209 operationally well established services (such as unicast). Therefore 1210 we detail them as follows: 1212 o Usage information logs at aggregate level. 1214 o Usage failure instances at an aggregate level. 1216 o Grouped or sequenced application access. performance, behavior 1217 and failure at an aggregate level to support potential Application 1218 Provider-driven strategies. Examples of aggregate levels include 1219 grouped video clips, web pages, and sets of software download. 1221 o Security logs, aggregated or summarized according to agreement 1222 (with additional detail potentially provided during security 1223 events, by agreement). 1225 o Access logs (EU), when needed for troubleshooting. 1227 o Application logs (what is the application doing), when needed for 1228 shared troubleshooting. 1230 o Syslogs (network management), when needed for shared 1231 troubleshooting. 1233 The two AD's may supply additional security logs to each other as 1234 agreed to by contract(s). Examples include the following: 1236 o Information related to general security-relevant activity which 1237 may be of use from a protective or response perspective, such as 1238 types and counts of attacks detected, related source information, 1239 related target information, etc. 1241 o Aggregated or summarized logs according to agreement (with 1242 additional detail potentially provided during security events, by 1243 agreement). 1245 4.4. Operations - Service Performance and Monitoring Guidelines 1247 Service Performance refers to monitoring metrics related to multicast 1248 delivery via probes. The focus is on the service provided by AD-2 to 1249 AD-1 on behalf of all multicast application sources (metrics may be 1250 specified for SLA use or otherwise). Associated guidelines are as 1251 follows: 1253 o Both AD's are expected to monitor, collect, and analyze service 1254 performance metrics for multicast applications. AD-2 provides 1255 relevant performance information to AD-1; this enables AD-1 to 1256 create an end-to-end performance view on behalf of the multicast 1257 application source. 1259 o Both AD's are expected to agree on the type of probes to be used 1260 to monitor multicast delivery performance. For example, AD-2 may 1261 permit AD-1's probes to be utilized in the AD-2 multicast service 1262 footprint. Alternately, AD-2 may deploy its own probes and relay 1263 performance information back to AD-1. 1265 Service Monitoring generally refers to a service (as a whole) 1266 provided on behalf of a particular multicast application source 1267 provider. It thus involves complaints from End Users when service 1268 problems occur. EUs direct their complaints to the source provider; 1269 in turn the source provider submits these complaints to AD-1. The 1270 responsibility for service delivery lies with AD-1; as such AD-1 will 1271 need to determine where the service problem is occurring - its own 1272 network or in AD-2. It is expected that each AD will have tools to 1273 monitor multicast service status in its own network. 1275 o Both AD's will determine how best to deploy multicast service 1276 monitoring tools. Typically, each AD will deploy its own set of 1277 monitoring tools; in which case, both AD's are expected to inform 1278 each other when multicast delivery problems are detected. 1280 o AD-2 may experience some problems in its network. For example, 1281 for the AMT Use Cases, one or more AMT Relays may be experiencing 1282 difficulties. AD-2 may be able to fix the problem by rerouting 1283 the multicast streams via alternate AMT Relays. If the fix is not 1284 successful and multicast service delivery degrades, then AD-2 1285 needs to report the issue to AD-1. 1287 o When problem notification is received from a multicast application 1288 source, AD-1 determines whether the cause of the problem is within 1289 its own network or within the AD-2 domain. If the cause is within 1290 the AD-2 domain, then AD-1 supplies all necessary information to 1291 AD-2. Examples of supporting information include the following: 1293 o Kind of problem(s). 1295 o Starting point & duration of problem(s). 1297 o Conditions in which problem(s) occur. 1299 o IP address blocks of affected users. 1301 o ISPs of affected users. 1303 o Type of access e.g., mobile versus desktop. 1305 o Network locations of affected EUs. 1307 o Both AD's conduct some form of root cause analysis for multicast 1308 service delivery problems. Examples of various factors for 1309 consideration include: 1311 o Verification that the service configuration matches the product 1312 features. 1314 o Correlation and consolidation of the various customer problems 1315 and resource troubles into a single root service problem. 1317 o Prioritization of currently open service problems, giving 1318 consideration to problem impact, service level agreement, etc. 1320 o Conduction of service tests, including one time tests or a 1321 series of tests over a period of time. 1323 o Analysis of test results. 1325 o Analysis of relevant network fault or performance data. 1327 o Analysis of the problem information provided by the customer 1328 (CP). 1330 o Once the cause of the problem has been determined and the problem 1331 has been fixed, both AD's need to work jointly to verify and 1332 validate the success of the fix. 1334 4.5. Client Reliability Models/Service Assurance Guidelines 1336 There are multiple options for instituting reliability architectures, 1337 most are at the application level. Both AD's should work those out 1338 with their contract or agreement and with the multicast application 1339 source providers. 1341 Network reliability can also be enhanced by the two AD's by 1342 provisioning alternate delivery mechanisms via unicast means. 1344 4.6. Application Accounting Guidelines 1346 Application level accounting needs to be handled differently in the 1347 application than in IP unicast because the source side does not 1348 directly deliver packets to individual receivers. Instead, this 1349 needs to be signalled back by the receiver to the source. 1351 For network transport diagnostics, AD-1 and AD-2 should have 1352 mechanisms in place to ensure proper accounting for the volume of 1353 bytes delivered through the peering point and separately the number 1354 of bytes delivered to EUs. 1356 5. Troubleshooting and Diagnostics 1358 Any service provider supporting multicast delivery of content should 1359 have the capability to collect diagnostics as part of multicast 1360 troubleshooting practices and resolve network issues accordingly. 1361 Issues may become apparent or identified either through network 1362 monitoring functions or by customer reported problems as described in 1363 section 4.4. 1365 It is recommended that multicast diagnostics will be performed 1366 leveraging established operational practices such as those documented 1367 in [MDH-04]. However, given that inter-domain multicast creates a 1368 significant interdependence of proper networking functionality 1369 between providers there does exist a need for providers to be able to 1370 signal (or otherwise alert) each other if there are any issues noted 1371 by either one. 1373 Service providers may also wish to allow limited read-only 1374 administrative access to their routers to their AD peers for 1375 troubleshooting. Of specific interest are access to active 1376 troubleshooting tools especially [Traceroute] and 1377 [I-D.ietf-mboned-mtrace-v2]. 1379 Another option is to include this functionality into the IP multicast 1380 receiver application on the EU device and allow for these diagnostics 1381 to be remotely used by support operations. Note though that AMT does 1382 not allow to pass traceroute or mtrace requests, therefore 1383 troubleshooting in the presence of AMT does not work as well end-to- 1384 end as it can with native (or even GRE encapsulated) IP multicast, 1385 especially wrt. to traceroute and mtrace. Instead, troubleshooting 1386 directly on the actual network devices is then more likely necessary. 1388 The specifics of the notification and alerts are beyond the scope of 1389 this document, but general guidelines are similar to those described 1390 in section 4.4 (Service Performance and Monitoring). Some general 1391 communications issues are stated as follows. 1393 o Appropriate communications channels will be established between 1394 the customer service and operations groups from both AD's to 1395 facilitate information sharing related to diagnostic 1396 troubleshooting. 1398 o A default resolution period may be considered to resolve open 1399 issues. Alternately, mutually acceptable resolution periods could 1400 be established depending on the severity of the identified 1401 trouble. 1403 6. Security Considerations 1405 6.1. DoS attacks (against state and bandwidth) 1407 Reliable operations of IP multicast requires some basic protection 1408 against DoS (Denial of Service) attacks. 1410 SSM IP multicast is self protecting against attacks from illicit 1411 sources. Their traffic will not be forwarded beyond the first hop 1412 router because that would require (S,G) memership reports from 1413 receiver. Traffic from sources will only be forwarded from the valid 1414 source because RPF ("Reverse Path Forwarding") is part of the 1415 protocols. One can say that [BCP38] style protection against spoofed 1416 source traffic is therefore built into PIM-SM/PIM-SSM. 1418 Receivers can attack SSM IP multicast by originating such (S,G) 1419 membership reports. This can result in a DoS attack against state 1420 through the creation of a large number of (S,G) states that create 1421 high control plane load or even inhibit later creation of valid 1422 (S,G). In conjunction with collaborating illicit sources it can also 1423 result in illicit sources traffic being forwarded. 1425 Today, these type of attacks are usually mitigated by explicitly 1426 defining the set of permissible (S,G) on e.g.: the last hop routers 1427 in replicating IP multicast to EUs; For example via (S,G) Access 1428 Control Lists applied to IGMP/MLD membership state creation. Each AD 1429 is expected to prohibit (S,G) state creation for invalid sources 1430 inside their own AD. 1432 In the peering case, AD-2 is without further information not aware of 1433 the set of valid (S,G) from AD-1, so this set needs to be 1434 communicated via operational procedures from AD-1 to AD-2 to provide 1435 protection against this type of DoS attacks. Future work could 1436 signal this information in an automated way: BGP extensions, DNS 1437 Resource Records or backend automation between AD-1 and AD-2. 1438 Backend automation is the short term most viable solution because it 1439 does not require router software extensions like the other two. 1440 Observation of traffic flowing via (S,G) state could also be used to 1441 automate recognition of invalid (S,G) state created by receivers in 1442 the absence of explicit information from AD-1. 1444 The second DoS attack through (S,G) membership reports is when 1445 receivers create too much valid (S,G) state to attack bandwidth 1446 available to other EU. Consider the uplink into a last-hop-router 1447 connecting to 100 EU. If one EU joins to more multicast content than 1448 what fits into this link, then this would impact also the quality of 1449 the same content for the other 99 EU. If traffic is not rate 1450 adaptive, the effects are even worse. 1452 The mitigation is the same as what is often employed for unicast: 1453 Policing of per-EU total amont of traffic. Unlike unicast though, 1454 this can not be done anywhere along the path (e.g.: on an arbitrary 1455 bottleneck link), but it has to happen at the point of last 1456 replication to the different EU. Simple solutions such as limiting 1457 the maximum number of joined (S,G) per EU are readily available, 1458 solutions that consider bandwidth consumed exist as vendor specific 1459 feature in routers. Note that this is primarily a non-peering issue 1460 in AD-2, it only becomes a peering issue if the peering-link itself 1461 is not big enough to carry all possible content from AD-1 or in case 1462 3.4 where the AMT relay in AD-1 is that last replication point. 1464 Limiting the amount of (S,G) state per EU is also a good first 1465 measure to prohibit too much undesired "empty" state to be built 1466 (state not carrying traffic), but it would not suffice in case of 1467 DDoS attack - viruses that impact a large number of EU devices. 1469 6.2. Content Security 1471 Content confidentiality, DRM (Digital Restrictions Management), 1472 authentication and authorization are optional based on the content 1473 delivered. For content that is "FTA" (Free To Air), the following 1474 considerations can be ignored and content can be sent unencrypted and 1475 without EU authentication and authorization. Note though that the 1476 mechanisms described here may also be desireable by the application 1477 source to better track users even if the content itself would not 1478 require it. 1480 For interdomain content, there are at least two models for content 1481 confidentiality, DRM and end-user authentication and authorization: 1483 In the classical (IP)TV model, responsibility is per-domain and 1484 content is and can be passed on unencrypted. AD-1 delivers content 1485 to AD-2, AD-2 can further process the content including features like 1486 ad-insertion and AD-2 is the sole point of contact regarding the 1487 contact for its EUs. In this document, we do not consider this case 1488 because it typically involves higher than network layer service 1489 aspects operated by AD-2 and this document focusses on the network 1490 layer AD-1/AD-2 peering case, but not the application layer peering 1491 case. Nevertheless, this model can be derived through additional 1492 work from what is describe here. 1494 The other case is the one in which content confidentiality, DRM, end- 1495 user authentication and authorization are end-to-end: 1496 responsibilities of the multicast application source provider and 1497 receiver application. This is the model assumed here. It is also 1498 the model used in Internet OTT video delivery. We discuss the 1499 threads incurred in this model due to the use of IP multicast in AD- 1500 1/AD-2 and across the peering. 1502 End-to-end encryption enables end-to-end EU authentication and 1503 authorization: The EU may be able to IGMP/MLD join and receive the 1504 content, but it can only decrypt it when it receives the decryption 1505 key from the content source in AD-1. The key is the authorization. 1506 Keeping that key to itself and prohibiting playout of the decrypted 1507 content to non-copy-protected interfaces are typical DRM features in 1508 that receiver application or EU device operating system. 1510 End-to-end ecnryption is continuously attacked. Keys may be subject 1511 to brute force attack so that content can be decrypted potentially 1512 later, or keys are extracted from the EU application/device and 1513 shared with other unauthenticated receivers. One important class of 1514 content is where the value is in live consumption, such as sports or 1515 other event (concert) streaming. Extraction of keying material from 1516 compromised authenticated EU and sharing with unauthenticated EU is 1517 not sufficient. It is also necessary for those unauthenticated EUs 1518 to get a streaming copy of the content itself. In unicast streaming, 1519 they can not get such a copy from the content source (because they 1520 can not authenticate) and because of asymmetric bandwidths, it is 1521 often impossible to get the content from compromised EUs to large 1522 number of unauthenticated EUs. EUs behind classical 16 Mbps down, 1 1523 Mbps up ADSL links are the best example. With increasing broadband 1524 access speeds unicast peer-to-peer copying of content becomes easier, 1525 but it likely will always be easily detectable by the ADs because of 1526 its traffic patterns and volume. 1528 When IP multicast is being used without additionals security, AD-2 is 1529 not aware which EU is authenticated for which content. Any 1530 unauthenticated EU in AD-2 could therefore get a copy of the 1531 encrypted content without suspicion by AD-2 or AD-1 and either live- 1532 deode it in the presence of compromised authenticated EU and key 1533 sharing, or later decrypt it in the presence of federated brute force 1534 key cracking. 1536 To mitigate this issue, the last replication point that is creating 1537 (S,G) copies to EUs would need to permit those copies only after 1538 authentication of EUs. This would establish the same authenticated 1539 EU only copy deliver thast is used in unicast. 1541 Schemes for per EU IP multicast authentication/authorization (and in 1542 result non-delivery/copying of per-content IP multicast traffic) have 1543 been built in the past and are deployed in service providers for 1544 intradomain IPTV services, but no standard exist for this. For 1545 example, there is no standardized radius attribute for authenticating 1546 the IGMP/MLD filter set, but implementations of this exist. The 1547 authors are specifically also not aware of schemes where the same 1548 authentication credentials used to get the encryption key from the 1549 content source could also be used to authenticate and authorize the 1550 network layer IP multicast replication for the content. Such schemes 1551 are technically not difficult to build and would avoid creating and 1552 maintaining a separate network forwarding authentication/ 1553 authorization scheme decoupled from the end-to-end authentication/ 1554 authorization system of the application. 1556 If delivery of such high value content in conjunction with the 1557 peering described here is desired, the short term recommendations are 1558 for sources to clearly isolate the source and group addresses used 1559 for different content bundles, communicate those (S,G) patterns from 1560 AD-1 to the AD-2 and let AD-2 leverage existing per-EU 1561 authentication/ authorization mechanisms in network devices to 1562 establish filters for (S,G) sets to each EU. 1564 6.3. Peering Encryption 1566 Encryption at peering points for multicast delivery may be used per 1567 agreement between AD-1/AD-2. 1569 In the case of a private peering link, IP multicast does not have 1570 attack vectors on a peering link different from those of IP unicast, 1571 but the content owner may have defined high bars against 1572 unauthenticated copying of even the end-to-end encrypted content, and 1573 in this case AD-1/AD-2 can agree on additional transport encryption 1574 across that peering link. In the case of a broadcast peering 1575 connection (e.g.: IXP), transport encryption is also the easiest way 1576 to prohibit unauthenticated copies by other ADs on the same peering 1577 point. 1579 If peering is across a tunnel going across intermittent transit ADs 1580 (not discused in detail in this document), then encryption of that 1581 tunnel traffic is recommended. It not only prohibits possible 1582 "leakage" of content, but also to protects the the information what 1583 content is being consumed in AD-2 (aggregated privacy protection). 1585 See the following subsection for reasons why the peering point may 1586 also need to be encrypted for operational reasons. 1588 6.4. Operational Aspects 1590 Section 4.3.3 discusses exchange of log information, this section 1591 discussed exchange of (S,G) information and Section 7 discusses 1592 exhange of program information. All these operational pieces of data 1593 should by default be exchanged via authenticated and encrypted peer- 1594 to-peer communication protocols between AD-1 and AD-2 so that only 1595 the intended recipient in the peers AD have access to it. Even 1596 exposure of the least sensitive information to third parties opens up 1597 attack vectors. Putting for example valid (S,G) information into DNS 1598 (as opposed to passing it via secured channels from AD-1 to AD-2) to 1599 allow easier filtering of invalid (S,G) would also allow attackers to 1600 easier identify valid (S,G) and change their attack vector. 1602 From the perspective of the ADs, security is most critical for the 1603 log information as it provides operational insight into the 1604 originating AD, but it also contains sensitive user data: 1606 Sensitive user data exported from AD-2 to AD-1 as part of logs could 1607 be as much as the equivalent of 5-tuple unicast traffic flow 1608 accounting (but not more, e.g.: no application level information). 1609 As mentioned in Section 7, in unicast, AD-1 could capture these 1610 traffic statistics itself because this is all about AD-1 originated 1611 traffic flows to EU receivers in AD-2, and operationally passing it 1612 from AD-2 to AD-1 may be necessary when IP multicast is used because 1613 of the replication happening in AD-2. 1615 Nevertheless, passing such traffic statistics inside AD-1 from a 1616 capturing router to a backend system is likely less subject to third 1617 party attacks then passing it interdomain from AD-2 to AD-1, so more 1618 diligence needs to be applied to secure it. 1620 If any protocols used for the operational information exchange are 1621 not easily secured at transport layer or higher (because of the use 1622 of legacy products or protocols in the network), then AD-1 and AD-2 1623 can also consider to ensure that all operational data exchange goes 1624 across the same peering point as the traffic and use network layer 1625 encryption of the peering point as discussed in before to protect it. 1627 End-to-end authentication and authorization of EU may involve some 1628 kind of token authentication and is done at the application layer 1629 independently of the two AD's. If there are problems related to 1630 failure of token authentication when end-users are supported by AD-2, 1631 then some means of validating proper working of the token 1632 authentication process (e.g., back-end servers querying the multicast 1633 application source provider's token authentication server are 1634 communicating properly) should be considered. Implementation details 1635 are beyond the scope of this document. 1637 Security Breach Mitigation Plan - In the event of a security breach, 1638 the two AD's are expected to have a mitigation plan for shutting down 1639 the peering point and directing multicast traffic over alternative 1640 peering points. It is also expected that appropriate information 1641 will be shared for the purpose of securing the identified breach. 1643 7. Privacy Considerations 1645 The described flow of information about content and the end-user 1646 described in this document aims to maintain privacy: 1648 AD-1 is operating on behalf (or owns) the content source and is 1649 therefore part of the content-consumption relationship with the end- 1650 user. The privacy considerations between the EU and AD-1 are 1651 therefore in general (exception see below) the same as if no IP 1652 multicast was used, especially because for any privacy conscious 1653 content, end-to-end encryption can and should be used. 1655 Interdomain multicast transport service related information is 1656 provided by the AD-2 operators to AD-1. AD-2 is not required to gain 1657 additional insight into the user behavior through this process that 1658 it would not already have without the service collaboration with AD-1 1659 - unless AD-1 and AD-2 agree on it and get approval from the EU. 1661 For example, if it is deemed beneficial for EU to directly get 1662 support from AD-2 then it would in general be necessary for AD-2 to 1663 be aware of the mapping between content and network (S,G) state so 1664 that AD-2 knows which (S,G) to troubleshoot when the EU complains 1665 about problems with a specific content. The degree to which this 1666 dissemination is done by AD-1 explicitly to meet privacy expectations 1667 of EUs is typically easy to assess by AD-1. Two simple examples: 1669 For a sports content bundle, every EU will happily click on the "i 1670 approve that the content program information is shared with your 1671 service provider" button, to ensure best service reliability because 1672 service conscious AD-2 would likely also try to ensure that high 1673 value content, such as the (S,G) for SuperBowl like content would be 1674 the first to receive care in case of network issues. 1676 If the content in question was one where the EU expected more 1677 privacy, the EU should prefer a content bundle that included this 1678 content in a large variety of other content, have all content end-to- 1679 end encrypted and the programming information not be shared with AD-2 1680 to maximize privacy. Nevertheless, the privacy of the EU against 1681 AD-2 observing traffic would still be lower than in the equivalent 1682 setup using unicast, because in unicast, AD-2 could not correlate 1683 which EUs are watching the same content and use that to deduce the 1684 content. Note that even the setup in Section 3.4 where AD-2 is not 1685 involved in IP multicast at all does not provide privacy against this 1686 level of analysis by AD-2 because there is no transport layer 1687 encryption in AMT and therefore AD-2 can correlate by onpath traffic 1688 analysis who is consuming the same content from an AMT relay from 1689 both the (S,G) join messages in AMT and the identical content 1690 segments (that where replicated at the AMT relay). 1692 In summary: Because only content to be consumed by multiple EUs is 1693 carried via IP multicast here, and all that content can be end-to-end 1694 encrypted, the only IP multicast specific privacy consideration is 1695 for AD-2 to know or reconstruct what content an EU is consuming. For 1696 content for which this is undesirable, some form of protections as 1697 explained above are possible, but ideally, the model of Section 3.4 1698 could be used in conjunction with future work adding e.g.: dTLS 1699 [RFC6347] encryption between AMT relay and EU. 1701 Note that IP multicast by nature would permit the EU privacy against 1702 the countent source operator because unlike unicast, the content 1703 source does not natively know which EU is consuming which content: In 1704 all cases where AD-2 provides replication, only AD-2 does know this 1705 directly. This document does not attempt to describe a model that 1706 does maintain such level of privacy against the content source but 1707 only against exposure to intermediate parties, in this case AD-2. 1709 8. IANA Considerations 1711 No considerations identified in this document. 1713 9. Acknowledgments 1715 The authors would like to thank the following individuals for their 1716 suggestions, comments, and corrections: 1718 Mikael Abrahamsson 1720 Hitoshi Asaeda 1722 Dale Carder 1724 Tim Chown 1726 Leonard Giuliano 1728 Jake Holland 1730 Joel Jaeggli 1732 Albert Manfredi 1734 Stig Venaas 1736 Henrik Levkowetz 1738 10. Change log [RFC Editor: Please remove] 1740 Please see discussion on mailing list for changes before -11. 1742 -11: version in IESG review. 1744 -12: XML'ified version of -11, committed solely to make rfcdiff 1745 easier. XML versions hosted on https://www.github.com/toerless/ 1746 peering-bcp 1748 -13: 1750 o IESG feedback. Complete details in: 1751 https://raw.githubusercontent.com/toerless/peering-bcp/master/11- 1752 iesg-review-reply.txt 1754 o Ben Campbell: Location information about EU (End User) is Network 1755 Locatio information 1757 o Ben Campbell: Added explanation of assumption to introduction that 1758 traffic is sourced from AD-1 to (one or many) AD-2, mentioned that 1759 sourcing from EU is out of scope. 1761 o Introduction: moved up bullet points about exchanges and transit 1762 to clean up flow of assumptions. 1764 o Ben Campbell: Added picture for the GRE case, visualized tunnels 1765 in all pictures. 1767 o Ben Campbell: See 13-discus.txt on github for more details of 1768 changes for this review. 1770 o Alissia Cooper: Added more explanation for Log Management, 1771 explained privacy context. 1773 o Alissia Cooper: removed pre pre-RFC5378 disclaimer. 1775 o Alissia Cooper: removed mentioning of potential mutual 1776 compensation between domains if the other violates SLA. 1778 o Mirja Kuehlewind: created section 4.1.1 to discuss congestion 1779 control more detailled, adding reference to BCP145, removed stub 1780 CC paragraphs from section 3.1 (principle applies to every section 1781 3.x, and did not want to duplicate text between 3.x and 4.x). 1783 o Mirja Kuehlewind: removed section 8 (conclusion). Text was not 1784 very good, not important to hae conclusion, maybe bring back with 1785 better text if strong interest. 1787 o Introduced section about broadcast peering points because there 1788 where too many places already where references to that case 1789 existed (4.2.4). 1791 o Introduced section about privact considerations because of comment 1792 by Ben Campbell and Alissa Cooper. 1794 o Rewrote security considerations and structured it into key 1795 aspects: DoS attacks, content protection, peering point encryption 1796 and operational aspects. 1798 o Kathleen Moriarty: Added operational aspects to security section 1799 (also for Alissia), e.g.: covering securing the exchange of 1800 operational data between ADs. 1802 o Spencer Dawkins: Various editorial fixes. Removed BCP38 text from 1803 section 3, superceeded be explanation of PIM-SM RPF check to 1804 provide equvialent security to BCP38 in security section 7.1). 1806 o Eric Roscorla: (fixed from other reviews already). 1808 o Adam Roach: Fixed up text about MDH-04, added reference to 1809 RFC4786. 1811 -13: Fix for Mirja's review on must for congestion control. 1813 11. References 1815 11.1. Normative References 1817 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1818 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1819 DOI 10.17487/RFC2784, March 2000, 1820 . 1822 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1823 Thyagarajan, "Internet Group Management Protocol, Version 1824 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1825 . 1827 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1828 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1829 DOI 10.17487/RFC3810, June 2004, 1830 . 1832 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1833 "Multiprotocol Extensions for BGP-4", RFC 4760, 1834 DOI 10.17487/RFC4760, January 2007, 1835 . 1837 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1838 Group Management Protocol Version 3 (IGMPv3) and Multicast 1839 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1840 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1841 August 2006, . 1843 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1844 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1845 Routing Security Issues and Enhancements", RFC 4609, 1846 DOI 10.17487/RFC4609, October 2006, 1847 . 1849 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1850 DOI 10.17487/RFC7450, February 2015, 1851 . 1853 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1854 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1855 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1856 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1857 2016, . 1859 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1860 Defeating Denial of Service Attacks which employ IP Source 1861 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1862 May 2000, . 1864 [BCP41] Floyd, S., "Congestion Control Principles", BCP 41, 1865 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1866 . 1868 [BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1869 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1870 March 2017, . 1872 11.2. Informative References 1874 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1875 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1876 December 2006, . 1878 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1879 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1880 January 2012, . 1882 [INF_ATIS_10] 1883 "CDN Interconnection Use Cases and Requirements in a 1884 Multi-Party Federation Environment", ATIS Standard 1885 A-0200010, December 2012. 1887 [MDH-04] Thaler, D. and others, "Multicast Debugging Handbook", 1888 IETF I-D draft-ietf-mboned-mdh-04.txt, May 2000. 1890 [Traceroute] 1891 , . 1893 [I-D.ietf-mboned-mtrace-v2] 1894 Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: 1895 Traceroute Facility for IP Multicast", draft-ietf-mboned- 1896 mtrace-v2-20 (work in progress), October 2017. 1898 Authors' Addresses 1900 Percy S. Tarapore (editor) 1901 AT&T 1903 Phone: 1-732-420-4172 1904 Email: tarapore@att.com 1906 Robert Sayko 1907 AT&T 1909 Phone: 1-732-420-3292 1910 Email: rs1983@att.com 1912 Greg Shepherd 1913 Cisco 1915 Email: shep@cisco.com 1917 Toerless Eckert (editor) 1918 Futurewei Technologies Inc. 1920 Email: tte+ietf@cs.fau.de 1922 Ram Krishnan 1923 SupportVectors 1925 Email: ramkri123@gmail.com