idnits 2.17.1 draft-ietf-mboned-interdomain-peering-bcp-13.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 27, 2017) is 2372 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: A later version (-26) exists of draft-ietf-mboned-mtrace-v2-20 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: April 30, 2018 G. Shepherd 6 Cisco 7 T. Eckert, Ed. 8 Huawei 9 R. Krishnan 10 SupportVectors 11 October 27, 2017 13 Use of Multicast Across Inter-Domain Peering Points 14 draft-ietf-mboned-interdomain-peering-bcp-13 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 April 30, 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 it is 339 recommended that the multicast traffic should support rate- 340 adaption. 342 c. The sending and receiving of multicast traffic between two 343 domains is typically determined by local policies associated with 344 each domain. For example, if AD-1 is a service provider and AD-2 345 is an enterprise, then AD-1 may support local policies for 346 traffic delivery to, but not traffic reception from, AD-2. 347 Another example is the use of a policy by which AD-1 delivers 348 specified content to AD-2 only if such delivery has been accepted 349 by contract. 351 d. Relevant information on multicast streams delivered to End Users 352 in AD-2 is assumed to be collected by available capabilities in 353 the application layer. The precise nature and formats of the 354 collected information will be determined by directives from the 355 source owner and the domain operators. 357 3.2. Peering Point Enabled with GRE Tunnel 359 The peering point is not native multicast enabled in this Use Case. 360 There is a Generic Routing Encapsulation Tunnel provisioned over the 361 peering point. See Figure 2. 363 ------------------- ------------------- 364 / AD-1 \ / AD-2 \ 365 / (Multicast Enabled) \ / (Multicast Enabled) \ 366 / \ / \ 367 | +----+ +---+ | (I1) | +---+ | 368 | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ 369 | | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU | 370 | | | +--+ <.......|........|........>+--+ |I2 +----+ 371 \ +----+ / I1 \ / 372 \ / GRE \ / 373 \ / Tunnel \ / 374 ------------------- ------------------- 376 AD = Administrative Domain (Independent Autonomous System) 377 AS = Application (e.g., Content) Multicast Source 378 uBR = unicast Border Router - not necessarily multicast enabled 379 may be the same router as BR 380 BR = Border Router - for multicast 381 I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) 382 I2 = AD-2 and EU Multicast Connection 384 Figure 2: Content Distribution via GRE Tunnel 386 In this case, the interconnection I1 between AD-1 and AD-2 in 387 Figure 2 is multicast enabled via a Generic Routing Encapsulation 388 Tunnel (GRE) [RFC2784] between the two BR and encapsulating the 389 multicast protocols across it. 391 Normally, this approach is choosen if the uBR physcially connected to 392 the peering link can or should not be enabled for IP multicast. This 393 approach may also be beneficial if BR and uBR are the same device, 394 but the peering link is a broadcast domain (IXP), see Figure 6. 396 The routing configuration is basically unchanged: Instead of BGP 397 (SAFI2) across the native IP multicast link between AD-1 and AD-2, 398 BGP (SAFI2) is now run across the GRE tunnel. 400 Advantages of this configuration: 402 o Highly efficient use of bandwidth in both domains, although not as 403 efficient as the fully native multicast Use Case. 405 o Fewer devices in the path traversed by the multicast stream when 406 compared to an AMT enabled peering point. 408 o Ability to support partial and/or incremental IP multicast 409 deployments in AD- 1 and/or AD-2: Only the path(s) between AS/BR 410 (AD-1) and BR/EU (AD-2) need to be multicast enabled. The uBRs 411 may not support IP multicast or enabling it could be seen as 412 operationally risky on that important edge node whereas dedicated 413 BR nodes for IP multicast may be more acceptable at least 414 initially. BR can also be located such that only parts of the 415 domain may need to support native IP multicast (e.g.: only the 416 core in AD-1 but not edge networks towards uBR). 418 o GRE is an existing technology and is relatively simple to 419 implement. 421 Disadvantages of this configuration: 423 o Per Use Case 3.1, current router technology cannot count the 424 number of end users or the number bytes transmitted. 426 o GRE tunnel requires manual configuration. 428 o The GRE must be established prior to stream starting. 430 o The GRE tunnel is often left pinned up. 432 Architectural guidelines for this configuration include the 433 following: 435 Guidelines (a) through (d) are the same as those described in Use 436 Case 3.1. Two additional guidelines are as follows: 438 e. GRE tunnels are typically configured manually between peering 439 points to support multicast delivery between domains. 441 f. It is recommended that the GRE tunnel (tunnel server) 442 configuration in the source network is such that it only 443 advertises the routes to the application sources and not to the 444 entire network. This practice will prevent unauthorized delivery 445 of applications through the tunnel (e.g., if application - e.g., 446 content - is not part of an agreed inter-domain partnership). 448 3.3. Peering Point Enabled with an AMT - Both Domains Multicast Enabled 450 Both administrative domains in this Use Case are assumed to be native 451 multicast enabled here; however, the peering point is not. 453 The peering point is enabled with an Automatic Multicast Tunnel. The 454 basic configuration is depicted in Figure 2. 456 ------------------- ------------------- 457 / AD-1 \ / AD-2 \ 458 / (Multicast Enabled) \ / (Multicast Enabled) \ 459 / \ / \ 460 | +----+ +---+ | I1 | +---+ | 461 | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ 462 | | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU | 463 | | | +--+ <.......|........|........>+--+ |I2 +----+ 464 \ +----+ / AMT \ / 465 \ / Tunnel \ / 466 \ / \ / 467 ------------------- ------------------- 469 AD = Administrative Domain (Independent Autonomous System) 470 AS = Application (e.g., Content) Multicast Source 471 AR = AMT Relay 472 AG = AMT Gateway 473 uBR = unicast Border Router - not multicast enabled 474 otherwise AR=uBR (AD-1), uBR=AG (AD-2) 475 I1 = AMT Interconnection between AD-1 and AD-2 476 I2 = AD-2 and EU Multicast Connection 478 Figure 3: - AMT Interconnection between AD-1 and AD-2 480 Advantages of this configuration: 482 o Highly efficient use of bandwidth in AD-1. 484 o AMT is an existing technology and is relatively simple to 485 implement. Attractive properties of AMT include the following: 487 o Dynamic interconnection between Gateway-Relay pair across the 488 peering point. 490 o Ability to serve clients and servers with differing policies. 492 Disadvantages of this configuration: 494 o Per Use Case 3.1 (AD-2 is native multicast), current router 495 technology cannot count the number of end users or the number of 496 bytes transmitted to all end users. 498 o Additional devices (AMT Gateway and Relay pairs) may be introduced 499 into the path if these services are not incorporated in the 500 existing routing nodes. 502 o Currently undefined mechanisms for the AG to automatically select 503 the optimal AR. 505 Architectural guidelines for this configuration are as follows: 507 Guidelines (a) through (d) are the same as those described in Use 508 Case 3.1. In addition, 510 e. It is recommended that AMT Relay and Gateway pairs be configured 511 at the peering points to support multicast delivery between 512 domains. AMT tunnels will then configure dynamically across the 513 peering points once the Gateway in AD-2 receives the (S, G) 514 information from the EU. 516 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 518 In this AMT Use Case, the second administrative domain AD-2 is not 519 multicast enabled. Hence, the interconnection between AD-2 and the 520 End User is also not multicast enabled. This Use Case is depicted in 521 Figure 3. 523 ------------------- ------------------- 524 / AD-1 \ / AD-2 \ 525 / (Multicast Enabled) \ / (Non Multicast \ 526 / \ / Enabled) \ N(large) 527 | +----+ +---+ | | +---+ | #EU 528 | | | +--+ |uBR|-|--------|-|uBR| | +----+ 529 | | AS |-->|AR| +---+-| | +---+ ................>|EU/G| 530 | | | +--+ <.......|........|........... |I2 +----+ 531 \ +----+ / N x AMT\ / 532 \ / Tunnel \ / 533 \ / \ / 534 ------------------- ------------------- 536 AS = Application Multicast Source 537 uBR = unicast Border Router - not multicast enabled, 538 otherwise AR = uBR (in AD-1). 539 AR = AMT Relay 540 EU/G = Gateway client embedded in EU device 541 I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast 542 Enabled AD-2. 544 Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 546 This Use Case is equivalent to having unicast distribution of the 547 application through AD-2. The total number of AMT tunnels would be 548 equal to the total number of End Users requesting the application. 549 The peering point thus needs to accommodate the total number of AMT 550 tunnels between the two domains. Each AMT tunnel can provide the 551 data usage associated with each End User. 553 Advantages of this configuration: 555 o Efficient use of bandwidth in AD-1 (The closer AR is to uBR, the 556 more efficient). 558 o Ability for AD-1 to introduce IP multicast based content delivery 559 without any support by network devices in AD-2: Only application 560 side in the EU device needs to perform AMT gateway library 561 functionality to receive traffic from AMT relay. 563 o Allows for AD-2 to "upgrade" to Use Case 3.5 (see below) at a 564 later time without any change in AD-1 at that time. 566 o AMT is an existing technology and is relatively simple to 567 implement. Attractive properties of AMT include the following: 569 o Dynamic interconnection between Gateway-Relay pair across the 570 peering point. 572 o Ability to serve clients and servers with differing policies. 574 o Each AMT tunnel serves as a count for each End User and is also 575 able to track data usage (bytes) delivered to the EU. 577 Disadvantages of this configuration: 579 o Additional devices (AMT Gateway and Relay pairs) are introduced 580 into the transport path. 582 o Assuming multiple peering points between the domains, the EU 583 Gateway needs to be able to find the "correct" AMT Relay in AD-1. 585 Architectural guidelines for this configuration are as follows: 587 Guidelines (a) through (c) are the same as those described in Use 588 Case 3.1. 590 d. It is necessary that proper procedures are implemented such that 591 the AMT Gateway at the End User device is able to find the correct 592 AMT Relay for each (S,G) content stream. Standard mechanisms for 593 that selection are still subject to ongoing work. This includes 594 use of anycast gateway addresses, anycast DNS names, explicit 595 configuration that is mapping (S,G) to a relay address or letting 596 the application in the EU/G provide the relay address to the 597 embedded AMT gateway function. 599 e. The AMT tunnel capabilities are expected to be sufficient for the 600 purpose of collecting relevant information on the multicast 601 streams delivered to End Users in AD-2. 603 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 605 This is a variation of Use Case 3.4 as follows: 607 ------------------- ------------------- 608 / AD-1 \ / AD-2 \ 609 / (Multicast Enabled) \ / (Non Multicast \ 610 / +---+ \ (I1) / +---+ Enabled) \ 611 | +----+ |uBR|-|--------|-|uBR| | 612 | | | +--+ +---+ | | +---+ +---+ | +----+ 613 | | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G| 614 | | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+ 615 \ +----+ / I1 \ |AR1| I2 +---+ / 616 \ / single \+---+ / 617 \ / AMT Tunnel \ / 618 ------------------- ------------------- 620 uBR = unicast Border Router - not multicast enabled 621 otherwise AR=uBR (AD-1) or ubr=AGAR1 (AD-2) 622 AS = Application Source 623 AR = AMT Relay in AD-1 624 AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point 625 I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 626 AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge 627 I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 628 EU/G = Gateway client embedded in EU device 629 I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 631 Figure 5: AMT Tunnel Connecting AMT Relay and Relays 633 Use Case 3.4 results in several long AMT tunnels crossing the entire 634 network of AD-2 linking the EU device and the AMT Relay in AD-1 635 through the peering point. Depending on the number of End Users, 636 there is a likelihood of an unacceptably high amount of traffic due 637 to the large number of AMT tunnels - and unicast streams - through 638 the peering point. This situation can be alleviated as follows: 640 o Provisioning of strategically located AMT nodes in AD-2 AD-2. An 641 AMT node comprises co-location of an AMT Gateway and an AMT Relay. 642 No change is required by AD-1 compared to 3.4. This can be done 643 whenever AD-2 seems fit (too much traffic across peering point. 645 o One such node is at the AD-2 side of the peering point (node AGAR1 646 in above Figure). 648 o Single AMT tunnel established across peering point linking AMT 649 Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. 651 o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to 652 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 653 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 in 654 Figure 4. 656 o AMT tunnels linking EU device (via Gateway client embedded in 657 device) and AMT Relay in appropriate AMT node at edge of AD-2: 658 e.g., I3 linking EU Gateway in device to AMT Relay in AMT node 659 AGAR2. 661 o In the most simple option (not shown), AD-2 only deploys a single 662 AGAR1 and lets EU/G build AMT tunnels directly to it. This setup 663 already solves the problem of replicated traffic across the 664 peering point. As soon as there is need to support more AMT 665 tunnels to EU/G, then additional AGAR2 nodes can be deployed by 666 AD-2. 668 The advantage for such a chained set of AMT tunnels is that the total 669 number of unicast streams across AD-2 is significantly reduced, thus 670 freeing up bandwidth. Additionally, there will be a single unicast 671 stream across the peering point instead of possibly, an unacceptably 672 large number of such streams per Use Case 3.4. However, this implies 673 that several AMT tunnels will need to be dynamically configured by 674 the various AMT Gateways based solely on the (S,G) information 675 received from the application client at the EU device. A suitable 676 mechanism for such dynamic configurations is therefore critical. 678 Architectural guidelines for this configuration are as follows: 680 Guidelines (a) through (c) are the same as those described in Use 681 Case 3.1. 683 d. It is necessary that proper procedures are implemented such that 684 the various AMT Gateways (at the End User devices and the AMT 685 nodes in AD-2) are able to find the correct AMT Relay in other AMT 686 nodes as appropriate. Standard mechanisms for that selection are 687 still subject to ongoing work. This includes use of anycast 688 gateway addresses, anycast DNS names, or explicit configuration 689 that is mapping (S,G) to a relay address. On the EU/G, this 690 mapping information may come from the application. 692 e. The AMT tunnel capabilities are expected to be sufficient for the 693 purpose of collecting relevant information on the multicast 694 streams delivered to End Users in AD-2. 696 4. Functional Guidelines 698 Supporting functions and related interfaces over the peering point 699 that enable the multicast transport of the application are listed in 700 this section. Critical information parameters that need to be 701 exchanged in support of these functions are enumerated, along with 702 guidelines as appropriate. Specific interface functions for 703 consideration are as follows. 705 4.1. Network Interconnection Transport Guidelines 707 The term "Network Interconnection Transport" refers to the 708 interconnection points between the two Administrative Domains. The 709 following is a representative set of attributes that will need to be 710 agreed to between the two administrative domains to support multicast 711 delivery. 713 o Number of Peering Points. 715 o Peering Point Addresses and Locations. 717 o Connection Type - Dedicated for Multicast delivery or shared with 718 other services. 720 o Connection Mode - Direct connectivity between the two AD's or via 721 another ISP. 723 o Peering Point Protocol Support - Multicast protocols that will be 724 used for multicast delivery will need to be supported at these 725 points. Examples of protocols include eBGP [RFC4760] and MBGP 726 [RFC4760]. 728 o Bandwidth Allocation - If shared with other services, then there 729 needs to be a determination of the share of bandwidth reserved for 730 multicast delivery. See section 4.1.1 below for more details. 732 o QoS Requirements - Delay and/or latency specifications that need 733 to be specified in an SLA. 735 o AD Roles and Responsibilities - the role played by each AD for 736 provisioning and maintaining the set of peering points to support 737 multicast delivery. 739 4.1.1. Bandwidth Management 741 Like IP unicast traffic, IP multicast traffic carried across non- 742 controlled networks must comply to Congestion Control Principles as 743 described in [BCP41] and explained in detail for UDP IP multicast in 744 [BCP145]. 746 Non-controlled networks (such as the Internet) are those where there 747 is no policy for managing bandwidth other than best effort with fair 748 share of bandwidth under congestion. As a simplified rule of thumb, 749 complying to congestion control principles means to reduce bandwidth 750 under congestion in a way that is fair to competing competing 751 (typically TCP) flow ("rate adaptive"). 753 In many instances, multicast content delivery evolves from intra- 754 domain deployments where it is handled as a controlled network 755 service and of not complyng to congestion control principles. It was 756 given a reserved amount of bandwidth and admitted to the network so 757 that congestion never occurs. Therefore the congestion control issue 758 should be given specific attention when evolving to an interdomain 759 peering deployment. 761 In the case where end-to-end IP multicast traffic passes across the 762 network of two ADs (and their subsidiaries/customers), both ADs must 763 agree on a consistent traffic management policy. If for example AD-1 764 sources non congestion aware IP multicast traffic and AD-2 carries it 765 as best effort traffic across links shared with other Internet 766 traffic and subject to congestion, this will not work: Under 767 congestion, some amount of that traffic will be dropped, rendering 768 the remaining packets often as undecodeable garbage clogging up the 769 network in AD-2 and because this is not congestion aware, the loss 770 does not reduce this rate. Competing traffic will not get their fair 771 share under congestion, and EUs will be frusted by extremely bad 772 quality of both their IP multicast and other (e.g.: TCP) traffic. 773 Note that this is not an IP multicast technology issue, but solely a 774 transport/application layer issue: The problem would equally happen 775 if AD-1 would send non-rate adaptive unicast traffic,, for example 776 legacy IPTV video-on-demand traffic which typically is also non 777 congestion aware. Because rate adaption in IP unicast video is 778 commonplace today because of ABR (Adaptive Bitrate Video), it is very 779 unlikely for this to happen though in reality with IP unicast. 781 While the rules for traffic management apply whether or not IP 782 multicast is tunneled or not, the one feature that can make AMT 783 tunnels more difficult is the unpredictability of bandwidth 784 requirements across underlying links because of the way they can be 785 used: With native IP multicast or GRE tunnels, the amount of 786 bandwidth depends on the amount of content, not the number of EUs - 787 and is therefore easier to plan for. AMT tunnels terminating in EU/G 788 on the other hand scale with the number of EUs. In the vicinity of 789 the AMT relay they can introduce very large amount of replicated 790 traffic and it is not always feasible to provision enough bandwidth 791 for all possible EU to get the highest quality for all their content 792 during peak utilization in such setups - unless the AMT relays are 793 very close to the EU edge. Therefore it is also recommended to use 794 IP multicast rate adaptation even inside controlled networks when 795 using AMT tunnels directly to EU/G. 797 Note that rate-adaptive IP multicast traffic in general does not mean 798 that the sender is reducing the bitrate, but rather that the EUs that 799 experience congestion are joining to a lower bitrate (S,G) stream of 800 the content, similar to adaptive bitrate streaming over TCP. 801 Migration from non rate-adaptive to rate adaptive bitrate in IP 802 multicast does therefore also change the dynamic (S,G) join behavior 803 in the network resulting in potentially higher performance 804 requirement for IP multicast protocols (IGMP/PIM), especially on the 805 last hops where dynamic changes occur (including AMT gateway/relays): 806 In non rate-adaptive IP multicast, only "channel change" causes state 807 change, in rate-adaptive also the congestion situation causes state 808 change. 810 Even though not fully specified in this document, peerings that rely 811 on GRE/AMT tunnels may be across one or more transit ADs instead of 812 an exclusive (non-shared, L1/L2) path. Unless those transit ADs are 813 explicitly contracted to provide other than "best effort" transit for 814 the tunneled traffic, the IP multicast traffic tunneled must be rate 815 adaptive to not violate BCP41 across those transit ADs. 817 4.2. Routing Aspects and Related Guidelines 819 The main objective for multicast delivery routing is to ensure that 820 the End User receives the multicast stream from the "most optimal" 821 source [INF_ATIS_10] which typically: 823 o Maximizes the multicast portion of the transport and minimizes any 824 unicast portion of the delivery, and 826 o Minimizes the overall combined network(s) route distance. 828 This routing objective applies to both Native and AMT; the actual 829 methodology of the solution will be different for each. Regardless, 830 the routing solution is expected: 832 o To be scalable, 834 o To avoid or minimize new protocol development or modifications, 835 and 837 o To be robust enough to achieve high reliability and automatically 838 adjust to changes and problems in the multicast infrastructure. 840 For both Native and AMT environments, having a source as close as 841 possible to the EU network is most desirable; therefore, in some 842 cases, an AD may prefer to have multiple sources near different 843 peering points. However, that is entirely an implementation issue. 845 4.2.1. Native Multicast Routing Aspects 847 Native multicast simply requires that the Administrative Domains 848 coordinate and advertise the correct source address(es) at their 849 network interconnection peering points(i.e., border routers). An 850 example of multicast delivery via a Native Multicast process across 851 two Administrative Domains is as follows assuming that the 852 interconnecting peering points are also multicast enabled: 854 o Appropriate information is obtained by the EU client who is a 855 subscriber to AD-2 (see Use Case 3.1). This information is in the 856 form of metadata and it contains instructions directing the EU 857 client to launch an appropriate application if necessary, as well 858 as additional information for the application about the source 859 location and the group (or stream) id in the form of the "S,G" 860 data. The "S" portion provides the name or IP address of the 861 source of the multicast stream. The metadata may also contain 862 alternate delivery information such as specifying the unicast 863 address of the stream. 865 o The client uses the join message with S,G to join the multicast 866 stream [RFC4604]. To facilitate this process, the two AD's need 867 to do the following: 869 o Advertise the source id(s) over the Peering Points. 871 o Exchange relevant Peering Point information such as Capacity 872 and Utilization. 874 o Implement compatible multicast protocols to ensure proper 875 multicast delivery across the peering points. 877 4.2.2. GRE Tunnel over Interconnecting Peering Point 879 If the interconnecting peering point is not multicast enabled and 880 both AD's are multicast enabled, then a simple solution is to 881 provision a GRE tunnel between the two AD's - see Use Case 3.2.2. 882 The termination points of the tunnel will usually be a network 883 engineering decision, but generally will be between the border 884 routers or even between the AD 2 border router and the AD 1 source 885 (or source access router). The GRE tunnel would allow end-to-end 886 native multicast or AMT multicast to traverse the interface. 887 Coordination and advertisement of the source IP is still required. 889 The two AD's need to follow the same process as described in 4.2.1 to 890 facilitate multicast delivery across the Peering Points. 892 4.2.3. Routing Aspects with AMT Tunnels 894 Unlike Native Multicast (with or without GRE), an AMT Multicast 895 environment is more complex. It presents a dual layered problem 896 because there are two criteria that should be simultaneously met: 898 o Find the closest AMT relay to the end-user that also has multicast 899 connectivity to the content source, and 901 o Minimize the AMT unicast tunnel distance. 903 There are essentially two components to the AMT specification 905 AMT Relays: These serve the purpose of tunneling UDP multicast 906 traffic to the receivers (i.e., End-Points). The AMT Relay will 907 receive the traffic natively from the multicast media source and 908 will replicate the stream on behalf of the downstream AMT 909 Gateways, encapsulating the multicast packets into unicast packets 910 and sending them over the tunnel toward the AMT Gateway. In 911 addition, the AMT Relay may perform various usage and activity 912 statistics collection. This results in moving the replication 913 point closer to the end user, and cuts down on traffic across the 914 network. Thus, the linear costs of adding unicast subscribers can 915 be avoided. However, unicast replication is still required for 916 each requesting End-Point within the unicast-only network. 918 AMT Gateway (GW): The Gateway will reside on an End-Point - this 919 could be any type of IP host such as a Personal Computer (PC), 920 mobile phone, Set Top Box (STB) or appliances. The AMT Gateway 921 receives join and leave requests from the Application via an 922 Application Programming Interface (API). In this manner, the 923 Gateway allows the End-Point to conduct itself as a true Multicast 924 End-Point. The AMT Gateway will encapsulate AMT messages into UDP 925 packets and send them through a tunnel (across the unicast-only 926 infrastructure) to the AMT Relay. 928 The simplest AMT Use Case (section 3.3) involves peering points that 929 are not multicast enabled between two multicast enabled AD's. An AMT 930 tunnel is deployed between an AMT Relay on the AD 1 side of the 931 peering point and an AMT Gateway on the AD 2 side of the peering 932 point. One advantage to this arrangement is that the tunnel is 933 established on an as needed basis and need not be a provisioned 934 element. The two AD's can coordinate and advertise special AMT Relay 935 Anycast addresses with each other. Alternately, they may decide to 936 simply provision Relay addresses, though this would not be an optimal 937 solution in terms of scalability. 939 Use Cases 3.4 and 3.5 describe more complicated AMT situations as 940 AD-2 is not multicast enabled. For these cases, the End User device 941 needs to be able to setup an AMT tunnel in the most optimal manner. 942 There are many methods by which relay selection can be done including 943 the use of DNS based queries and static lookup tables [RFC7450]. The 944 choice of the method is implementation dependent and is up to the 945 network operators. Comparison of various methods is out of scope for 946 this document; it is for further study. 948 An illustrative example of a relay selection based on DNS queries and 949 Anycast IP addresses process for Use Cases 3.4 and 3.5 is described 950 here. Using an Anycast IP address for AMT Relays allows for all AMT 951 Gateways to find the "closest" AMT Relay - the nearest edge of the 952 multicast topology of the source. Note that this is strictly 953 illustrative; the choice of the method is up to the network 954 operators. The basic process is as follows: 956 o Appropriate metadata is obtained by the EU client application. 957 The metadata contains instructions directing the EU client to an 958 ordered list of particular destinations to seek the requested 959 stream and, for multicast, specifies the source location and the 960 group (or stream) ID in the form of the "S,G" data. The "S" 961 portion provides the URI (name or IP address) of the source of the 962 multicast stream and the "G" identifies the particular stream 963 originated by that source. The metadata may also contain 964 alternate delivery information such as the address of the unicast 965 form of the content to be used, for example, if the multicast 966 stream becomes unavailable. 968 o Using the information from the metadata, and possibly information 969 provisioned directly in the EU client, a DNS query is initiated in 970 order to connect the EU client/AMT Gateway to an AMT Relay. 972 o Query results are obtained, and may return an Anycast address or a 973 specific unicast address of a relay. Multiple relays will 974 typically exist. The Anycast address is a routable "pseudo- 975 address" shared among the relays that can gain multicast access to 976 the source. 978 o If a specific IP address unique to a relay was not obtained, the 979 AMT Gateway then sends a message (e.g., the discovery message) to 980 the Anycast address such that the network is making the routing 981 choice of particular relay - e.g., closest relay to the EU. 982 Details are outside the scope for this document. See [RFC4786]. 984 o The contacted AMT Relay then returns its specific unicast IP 985 address (after which the Anycast address is no longer required). 986 Variations may exist as well. 988 o The AMT Gateway uses that unicast IP address to initiate a three- 989 way handshake with the AMT Relay. 991 o AMT Gateway provides "S,G" to the AMT Relay (embedded in AMT 992 protocol messages). 994 o AMT Relay receives the "S,G" information and uses the S,G to join 995 the appropriate multicast stream, if it has not already subscribed 996 to that stream. 998 o AMT Relay encapsulates the multicast stream into the tunnel 999 between the Relay and the Gateway, providing the requested content 1000 to the EU. 1002 4.2.4. Public Peering Routing Aspects 1004 AD-1a AD-1b 1005 BR BR 1006 | | 1007 --+-+---------------+-+-- broadcast peering point LAN 1008 | | 1009 BR BR 1010 AD-2a AD-2b 1012 Figure 6: Broadcast Peering Point 1014 A broadcast peering point is an L2 subnet connecting 3 or more ADs. 1015 It is common in IXPs and usually consists of ethernet switch(es) 1016 operated by the IXP connecting to BRs operated by the ADs. 1018 In an example setup domain AD-2a peers with AD-1a and wants to 1019 receive IP multicast from it. Likewise AD-2b peers with AD-1b and 1020 wants to receive IP multicast from it. 1022 Assume one or more IP multicast (S,G) traffic streams can be served 1023 by both AD-1a and AD-1b, for example because both AD-1a and AD-1b do 1024 contract this content from the same content source. 1026 In this case, AD-2a and AD-2b can not control anymore which upstream 1027 domain, AD-1a or AD-1b will forward this (S,G) into the LAN. AD-2a 1028 BR requests the (S,G) from AD-1a BR and AD-2b BR requests the same 1029 (S,G) from AD-1b BR. To avoid duplicate packets, an (S,G) can be 1030 forwarded by only one router onto the LAN, and PIM-SM/PIM-SSM detects 1031 requests for duplicate transmission and resolve it via the so-called 1032 "assert" protocol operation which results in only one BR forwarding 1033 the traffic. Assume this is AD-1a BR. AD-2b will then receive the 1034 multicast traffic unexpectedly from a provider with whom it does not 1035 have a mutual agreement for the traffic. Quality issues in EUs 1036 behind AD-2b caused by AD-1a will cause a lot of responsiblity and 1037 troubleshooting issues. 1039 In face of this technical issues, we describe the following options 1040 how IP multicast can be carried across broadcast peering point LANs: 1042 1. IP multicast is tunneled across the LAN. Any of the GRE/AMT 1043 tunneling solutions mentioned in this document are applicable. 1044 This is the one case where specifically a GRE tunnel between the 1045 upstream BR (e.g.: AD-1a) and downstream BR (e.g.: AD-2a) is 1046 recommended as opposed to tunneling across uBRs which are not the 1047 actual BRs. 1049 2. The LAN has only one upstream AD that is sourcing IP multicast 1050 and native IP multicast is used. This is an efficient way to 1051 distribute the same IP multicast content to multiple downstream 1052 ADs. Misbehaving downstream BRs can still disrupt the delivery 1053 of IP multicast from the upstream BR to other downstream BRs, 1054 therefore strict rules must be follow to prohibit that case. The 1055 downstream BRs must ensure that they will always consider only 1056 the upstream BR as a source for multicast traffic: e.g.: no BGP 1057 SAFI-2 peerings between the downstream ADs across the peering 1058 point LAN, so that only the upstream BR is the only possible 1059 next-hop reachable across this LAN. And routing policies 1060 configured to avoid fall back to the use of SAFI-1 (unicast) 1061 routes for IP multicast if unicast BGP peering is not limited in 1062 the same way. 1064 3. The LAN has multiple upstreams, but they are federated and agree 1065 on a consistent policy for IP multicast traffic across the LAN. 1066 One policy is that each possible source is only announced by one 1067 upstream BR. Another policy is that sources are redundantly 1068 announced (problematic case mentioned in above example), but the 1069 upstream domains also provide mutual operational insight to help 1070 troubleshooting (outside the scope of this document). 1072 4.3. Back Office Functions - Provisioning and Logging Guidelines 1074 Back Office refers to the following: 1076 o Servers and Content Management systems that support the delivery 1077 of applications via multicast and interactions between AD's. 1079 o Functionality associated with logging, reporting, ordering, 1080 provisioning, maintenance, service assurance, settlement, etc. 1082 4.3.1. Provisioning Guidelines 1084 Resources for basic connectivity between AD's Providers need to be 1085 provisioned as follows: 1087 o Sufficient capacity must be provisioned to support multicast-based 1088 delivery across AD's. 1090 o Sufficient capacity must be provisioned for connectivity between 1091 all supporting back-offices of the AD's as appropriate. This 1092 includes activating proper security treatment for these back- 1093 office connections (gateways, firewalls, etc) as appropriate. 1095 o Routing protocols as needed, e.g. configuring routers to support 1096 these. 1098 Provisioning aspects related to Multicast-Based inter-domain delivery 1099 are as follows. 1101 The ability to receive requested application via multicast is 1102 triggered via receipt of the necessary metadata. Hence, this 1103 metadata must be provided to the EU regarding multicast URL - and 1104 unicast fallback if applicable. AD-2 must enable the delivery of 1105 this metadata to the EU and provision appropriate resources for this 1106 purpose. 1108 Native multicast functionality is assumed to be available across many 1109 ISP backbones, peering and access networks. If, however, native 1110 multicast is not an option (Use Cases 3.4 and 3.5), then: 1112 o EU must have multicast client to use AMT multicast obtained either 1113 from Application Source (per agreement with AD-1) or from AD-1 or 1114 AD-2 (if delegated by the Application Source). 1116 o If provided by AD-1/AD-2, then the EU could be redirected to a 1117 client download site (note: this could be an Application Source 1118 site). If provided by the Application Source, then this Source 1119 would have to coordinate with AD-1 to ensure the proper client is 1120 provided (assuming multiple possible clients). 1122 o Where AMT Gateways support different application sets, all AD-2 1123 AMT Relays need to be provisioned with all source & group 1124 addresses for streams it is allowed to join. 1126 o DNS across each AD must be provisioned to enable a client GW to 1127 locate the optimal AMT Relay (i.e. longest multicast path and 1128 shortest unicast tunnel) with connectivity to the content's 1129 multicast source. 1131 Provisioning Aspects Related to Operations and Customer Care are 1132 stated as follows. 1134 Each AD provider is assumed to provision operations and customer care 1135 access to their own systems. 1137 AD-1's operations and customer care functions must have visibility to 1138 what is happening in AD-2's network or to the service provided by AD- 1139 2, sufficient to verify their mutual goals and operations, e.g. to 1140 know how the EU's are being served. This can be done in two ways: 1142 o Automated interfaces are built between AD-1 and AD-2 such that 1143 operations and customer care continue using their own systems. 1144 This requires coordination between the two AD's with appropriate 1145 provisioning of necessary resources. 1147 o AD-1's operations and customer care personnel are provided access 1148 directly to AD-2's system. In this scenario, additional 1149 provisioning in these systems will be needed to provide necessary 1150 access. Additional provisioning must be agreed to by the two AD's 1151 to support this option. 1153 4.3.2. Interdomain Authentication Guidelines 1155 All interactions between pairs of AD's can be discovered and/or be 1156 associated with the account(s) utilized for delivered applications. 1157 Supporting guidelines are as follows: 1159 o A unique identifier is recommended to designate each master 1160 account. 1162 o AD-2 is expected to set up "accounts" (logical facility generally 1163 protected by credentials such as login passwords) for use by AD-1. 1164 Multiple accounts and multiple types or partitions of accounts can 1165 apply, e.g. customer accounts, security accounts, etc. 1167 The reason to specifically mention the need for AD-1 to initiate 1168 interactions with AD-2 (and use some account for that), as opposed to 1169 the opposite direction is based on the recommended workflow initiated 1170 by customers (see Section 4.4): The customer contacts content source 1171 (part of AD-1), when AD-1 sees the need to propagate the issue, it 1172 will interact with AD-2 using the aforementioned guidelines. 1174 4.3.3. Log Management Guidelines 1176 Successful delivery (in terms of user experience) of applications or 1177 content via multicast between pairs of interconnecting AD's can be 1178 improved through the ability to exchange appropriate logs for various 1179 workflows - troubleshooting, accounting and billing, traffic and 1180 content transmission optimization, content and application 1181 development optimization and so on. 1183 The basic model as explained in before is that the content source and 1184 on its behalf AD-1 take over primary responsibility for customer 1185 experience and the AD-2's support this. The application/content 1186 owner is the only participant who has and needs full insight into the 1187 application level and can map the customer application experience to 1188 the network traffic flows - which it then with the help of AD-2 or 1189 logs from AD-2 can analyze and interpret. 1191 The main difference between unicast delivery and multicast delivery 1192 is that the content source can infer a lot more about downstream 1193 network problems from a unicasted stream than from a multicasted 1194 stream: The multicasted stream is not per-EU except after the last 1195 replication, which is in most cases not in AD-1. Logs from the 1196 application, including the receiver side at the EU, can provide 1197 insight, but can not help to fully isolate network problems because 1198 of the IP multicast per-application operational state built across 1199 AD-1 and AD-2 (aka: the (S,G) state and any other feature operational 1200 state such as DiffServ QoS). 1202 See Section 7 for more discussions about the privacy considerations 1203 of the model described here. 1205 Different type of logs are known to help support operations in AD-1 1206 when provided by AD-2. This could be done as part of AD-1/AD-2 1207 contracts. Note that except for implied multicast specific elements, 1208 the options listed here are not unique or novel for IP multicast, but 1209 they are more important for services novel to the operators than for 1210 operationally well established services (such as unicast). Therefore 1211 we detail them as follows: 1213 o Usage information logs at aggregate level. 1215 o Usage failure instances at an aggregate level. 1217 o Grouped or sequenced application access. performance, behavior 1218 and failure at an aggregate level to support potential Application 1219 Provider-driven strategies. Examples of aggregate levels include 1220 grouped video clips, web pages, and sets of software download. 1222 o Security logs, aggregated or summarized according to agreement 1223 (with additional detail potentially provided during security 1224 events, by agreement). 1226 o Access logs (EU), when needed for troubleshooting. 1228 o Application logs (what is the application doing), when needed for 1229 shared troubleshooting. 1231 o Syslogs (network management), when needed for shared 1232 troubleshooting. 1234 The two AD's may supply additional security logs to each other as 1235 agreed to by contract(s). Examples include the following: 1237 o Information related to general security-relevant activity which 1238 may be of use from a protective or response perspective, such as 1239 types and counts of attacks detected, related source information, 1240 related target information, etc. 1242 o Aggregated or summarized logs according to agreement (with 1243 additional detail potentially provided during security events, by 1244 agreement). 1246 4.4. Operations - Service Performance and Monitoring Guidelines 1248 Service Performance refers to monitoring metrics related to multicast 1249 delivery via probes. The focus is on the service provided by AD-2 to 1250 AD-1 on behalf of all multicast application sources (metrics may be 1251 specified for SLA use or otherwise). Associated guidelines are as 1252 follows: 1254 o Both AD's are expected to monitor, collect, and analyze service 1255 performance metrics for multicast applications. AD-2 provides 1256 relevant performance information to AD-1; this enables AD-1 to 1257 create an end-to-end performance view on behalf of the multicast 1258 application source. 1260 o Both AD's are expected to agree on the type of probes to be used 1261 to monitor multicast delivery performance. For example, AD-2 may 1262 permit AD-1's probes to be utilized in the AD-2 multicast service 1263 footprint. Alternately, AD-2 may deploy its own probes and relay 1264 performance information back to AD-1. 1266 Service Monitoring generally refers to a service (as a whole) 1267 provided on behalf of a particular multicast application source 1268 provider. It thus involves complaints from End Users when service 1269 problems occur. EUs direct their complaints to the source provider; 1270 in turn the source provider submits these complaints to AD-1. The 1271 responsibility for service delivery lies with AD-1; as such AD-1 will 1272 need to determine where the service problem is occurring - its own 1273 network or in AD-2. It is expected that each AD will have tools to 1274 monitor multicast service status in its own network. 1276 o Both AD's will determine how best to deploy multicast service 1277 monitoring tools. Typically, each AD will deploy its own set of 1278 monitoring tools; in which case, both AD's are expected to inform 1279 each other when multicast delivery problems are detected. 1281 o AD-2 may experience some problems in its network. For example, 1282 for the AMT Use Cases, one or more AMT Relays may be experiencing 1283 difficulties. AD-2 may be able to fix the problem by rerouting 1284 the multicast streams via alternate AMT Relays. If the fix is not 1285 successful and multicast service delivery degrades, then AD-2 1286 needs to report the issue to AD-1. 1288 o When problem notification is received from a multicast application 1289 source, AD-1 determines whether the cause of the problem is within 1290 its own network or within the AD-2 domain. If the cause is within 1291 the AD-2 domain, then AD-1 supplies all necessary information to 1292 AD-2. Examples of supporting information include the following: 1294 o Kind of problem(s). 1296 o Starting point & duration of problem(s). 1298 o Conditions in which problem(s) occur. 1300 o IP address blocks of affected users. 1302 o ISPs of affected users. 1304 o Type of access e.g., mobile versus desktop. 1306 o Network locations of affected EUs. 1308 o Both AD's conduct some form of root cause analysis for multicast 1309 service delivery problems. Examples of various factors for 1310 consideration include: 1312 o Verification that the service configuration matches the product 1313 features. 1315 o Correlation and consolidation of the various customer problems 1316 and resource troubles into a single root service problem. 1318 o Prioritization of currently open service problems, giving 1319 consideration to problem impact, service level agreement, etc. 1321 o Conduction of service tests, including one time tests or a 1322 series of tests over a period of time. 1324 o Analysis of test results. 1326 o Analysis of relevant network fault or performance data. 1328 o Analysis of the problem information provided by the customer 1329 (CP). 1331 o Once the cause of the problem has been determined and the problem 1332 has been fixed, both AD's need to work jointly to verify and 1333 validate the success of the fix. 1335 4.5. Client Reliability Models/Service Assurance Guidelines 1337 There are multiple options for instituting reliability architectures, 1338 most are at the application level. Both AD's should work those out 1339 with their contract or agreement and with the multicast application 1340 source providers. 1342 Network reliability can also be enhanced by the two AD's by 1343 provisioning alternate delivery mechanisms via unicast means. 1345 4.6. Application Accounting Guidelines 1347 Application level accounting needs to be handled differently in the 1348 application than in IP unicast because the source side does not 1349 directly deliver packets to individual receivers. Instead, this 1350 needs to be signalled back by the receiver to the source. 1352 For network transport diagnostics, AD-1 and AD-2 should have 1353 mechanisms in place to ensure proper accounting for the volume of 1354 bytes delivered through the peering point and separately the number 1355 of bytes delivered to EUs. 1357 5. Troubleshooting and Diagnostics 1359 Any service provider supporting multicast delivery of content should 1360 have the capability to collect diagnostics as part of multicast 1361 troubleshooting practices and resolve network issues accordingly. 1362 Issues may become apparent or identified either through network 1363 monitoring functions or by customer reported problems as described in 1364 section 4.4. 1366 It is recommended that multicast diagnostics will be performed 1367 leveraging established operational practices such as those documented 1368 in [MDH-04]. However, given that inter-domain multicast creates a 1369 significant interdependence of proper networking functionality 1370 between providers there does exist a need for providers to be able to 1371 signal (or otherwise alert) each other if there are any issues noted 1372 by either one. 1374 Service providers may also wish to allow limited read-only 1375 administrative access to their routers to their AD peers for 1376 troubleshooting. Of specific interest are access to active 1377 troubleshooting tools especially [Traceroute] and 1378 [I-D.ietf-mboned-mtrace-v2]. 1380 Another option is to include this functionality into the IP multicast 1381 receiver application on the EU device and allow for these diagnostics 1382 to be remotely used by support operations. Note though that AMT does 1383 not allow to pass traceroute or mtrace requests, therefore 1384 troubleshooting in the presence of AMT does not work as well end-to- 1385 end as it can with native (or even GRE encapsulated) IP multicast, 1386 especially wrt. to traceroute and mtrace. Instead, troubleshooting 1387 directly on the actual network devices is then more likely necessary. 1389 The specifics of the notification and alerts are beyond the scope of 1390 this document, but general guidelines are similar to those described 1391 in section 4.4 (Service Performance and Monitoring). Some general 1392 communications issues are stated as follows. 1394 o Appropriate communications channels will be established between 1395 the customer service and operations groups from both AD's to 1396 facilitate information sharing related to diagnostic 1397 troubleshooting. 1399 o A default resolution period may be considered to resolve open 1400 issues. Alternately, mutually acceptable resolution periods could 1401 be established depending on the severity of the identified 1402 trouble. 1404 6. Security Considerations 1406 6.1. DoS attacks (against state and bandwidth) 1408 Reliable operations of IP multicast requires some basic protection 1409 against DoS (Denial of Service) attacks. 1411 SSM IP multicast is self protecting against attacks from illicit 1412 sources. Their traffic will not be forwarded beyond the first hop 1413 router because that would require (S,G) memership reports from 1414 receiver. Traffic from sources will only be forwarded from the valid 1415 source because RPF ("Reverse Path Forwarding") is part of the 1416 protocols. One can say that [BCP38] style protection against spoofed 1417 source traffic is therefore built into PIM-SM/PIM-SSM. 1419 Receivers can attack SSM IP multicast by originating such (S,G) 1420 membership reports. This can result in a DoS attack against state 1421 through the creation of a large number of (S,G) states that create 1422 high control plane load or even inhibit later creation of valid 1423 (S,G). In conjunction with collaborating illicit sources it can also 1424 result in illicit sources traffic being forwarded. 1426 Today, these type of attacks are usually mitigated by explicitly 1427 defining the set of permissible (S,G) on e.g.: the last hop routers 1428 in replicating IP multicast to EUs; For example via (S,G) Access 1429 Control Lists applied to IGMP/MLD membership state creation. Each AD 1430 is expected to prohibit (S,G) state creation for invalid sources 1431 inside their own AD. 1433 In the peering case, AD-2 is without further information not aware of 1434 the set of valid (S,G) from AD-1, so this set needs to be 1435 communicated via operational procedures from AD-1 to AD-2 to provide 1436 protection against this type of DoS attacks. Future work could 1437 signal this information in an automated way: BGP extensions, DNS 1438 Resource Records or backend automation between AD-1 and AD-2. 1439 Backend automation is the short term most viable solution because it 1440 does not require router software extensions like the other two. 1441 Observation of traffic flowing via (S,G) state could also be used to 1442 automate recognition of invalid (S,G) state created by receivers in 1443 the absence of explicit information from AD-1. 1445 The second DoS attack through (S,G) membership reports is when 1446 receivers create too much valid (S,G) state to attack bandwidth 1447 available to other EU. Consider the uplink into a last-hop-router 1448 connecting to 100 EU. If one EU joins to more multicast content than 1449 what fits into this link, then this would impact also the quality of 1450 the same content for the other 99 EU. If traffic is not rate 1451 adaptive, the effects are even worse. 1453 The mitigation is the same as what is often employed for unicast: 1454 Policing of per-EU total amont of traffic. Unlike unicast though, 1455 this can not be done anywhere along the path (e.g.: on an arbitrary 1456 bottleneck link), but it has to happen at the point of last 1457 replication to the different EU. Simple solutions such as limiting 1458 the maximum number of joined (S,G) per EU are readily available, 1459 solutions that consider bandwidth consumed exist as vendor specific 1460 feature in routers. Note that this is primarily a non-peering issue 1461 in AD-2, it only becomes a peering issue if the peering-link itself 1462 is not big enough to carry all possible content from AD-1 or in case 1463 3.4 where the AMT relay in AD-1 is that last replication point. 1465 Limiting the amount of (S,G) state per EU is also a good first 1466 measure to prohibit too much undesired "empty" state to be built 1467 (state not carrying traffic), but it would not suffice in case of 1468 DDoS attack - viruses that impact a large number of EU devices. 1470 6.2. Content Security 1472 Content confidentiality, DRM (Digital Restrictions Management), 1473 authentication and authorization are optional based on the content 1474 delivered. For content that is "FTA" (Free To Air), the following 1475 considerations can be ignored and content can be sent unencrypted and 1476 without EU authentication and authorization. Note though that the 1477 mechanisms described here may also be desireable by the application 1478 source to better track users even if the content itself would not 1479 require it. 1481 For interdomain content, there are at least two models for content 1482 confidentiality, DRM and end-user authentication and authorization: 1484 In the classical (IP)TV model, responsibility is per-domain and 1485 content is and can be passed on unencrypted. AD-1 delivers content 1486 to AD-2, AD-2 can further process the content including features like 1487 ad-insertion and AD-2 is the sole point of contact regarding the 1488 contact for its EUs. In this document, we do not consider this case 1489 because it typically involves higher than network layer service 1490 aspects operated by AD-2 and this document focusses on the network 1491 layer AD-1/AD-2 peering case, but not the application layer peering 1492 case. Nevertheless, this model can be derived through additional 1493 work from what is describe here. 1495 The other case is the one in which content confidentiality, DRM, end- 1496 user authentication and authorization are end-to-end: 1497 responsibilities of the multicast application source provider and 1498 receiver application. This is the model assumed here. It is also 1499 the model used in Internet OTT video delivery. We discuss the 1500 threads incurred in this model due to the use of IP multicast in AD- 1501 1/AD-2 and across the peering. 1503 End-to-end encryption enables end-to-end EU authentication and 1504 authorization: The EU may be able to IGMP/MLD join and receive the 1505 content, but it can only decrypt it when it receives the decryption 1506 key from the content source in AD-1. The key is the authorization. 1507 Keeping that key to itself and prohibiting playout of the decrypted 1508 content to non-copy-protected interfaces are typical DRM features in 1509 that receiver application or EU device operating system. 1511 End-to-end ecnryption is continuously attacked. Keys may be subject 1512 to brute force attack so that content can be decrypted potentially 1513 later, or keys are extracted from the EU application/device and 1514 shared with other unauthenticated receivers. One important class of 1515 content is where the value is in live consumption, such as sports or 1516 other event (concert) streaming. Extraction of keying material from 1517 compromised authenticated EU and sharing with unauthenticated EU is 1518 not sufficient. It is also necessary for those unauthenticated EUs 1519 to get a streaming copy of the content itself. In unicast streaming, 1520 they can not get such a copy from the content source (because they 1521 can not authenticate) and because of asymmetric bandwidths, it is 1522 often impossible to get the content from compromised EUs to large 1523 number of unauthenticated EUs. EUs behind classical 16 Mbps down, 1 1524 Mbps up ADSL links are the best example. With increasing broadband 1525 access speeds unicast peer-to-peer copying of content becomes easier, 1526 but it likely will always be easily detectable by the ADs because of 1527 its traffic patterns and volume. 1529 When IP multicast is being used without additionals security, AD-2 is 1530 not aware which EU is authenticated for which content. Any 1531 unauthenticated EU in AD-2 could therefore get a copy of the 1532 encrypted content without suspicion by AD-2 or AD-1 and either live- 1533 deode it in the presence of compromised authenticated EU and key 1534 sharing, or later decrypt it in the presence of federated brute force 1535 key cracking. 1537 To mitigate this issue, the last replication point that is creating 1538 (S,G) copies to EUs would need to permit those copies only after 1539 authentication of EUs. This would establish the same authenticated 1540 EU only copy deliver thast is used in unicast. 1542 Schemes for per EU IP multicast authentication/authorization (and in 1543 result non-delivery/copying of per-content IP multicast traffic) have 1544 been built in the past and are deployed in service providers for 1545 intradomain IPTV services, but no standard exist for this. For 1546 example, there is no standardized radius attribute for authenticating 1547 the IGMP/MLD filter set, but implementations of this exist. The 1548 authors are specifically also not aware of schemes where the same 1549 authentication credentials used to get the encryption key from the 1550 content source could also be used to authenticate and authorize the 1551 network layer IP multicast replication for the content. Such schemes 1552 are technically not difficult to build and would avoid creating and 1553 maintaining a separate network forwarding authentication/ 1554 authorization scheme decoupled from the end-to-end authentication/ 1555 authorization system of the application. 1557 If delivery of such high value content in conjunction with the 1558 peering described here is desired, the short term recommendations are 1559 for sources to clearly isolate the source and group addresses used 1560 for different content bundles, communicate those (S,G) patterns from 1561 AD-1 to the AD-2 and let AD-2 leverage existing per-EU 1562 authentication/ authorization mechanisms in network devices to 1563 establish filters for (S,G) sets to each EU. 1565 6.3. Peering Encryption 1567 Encryption at peering points for multicast delivery may be used per 1568 agreement between AD-1/AD-2. 1570 In the case of a private peering link, IP multicast does not have 1571 attack vectors on a peering link different from those of IP unicast, 1572 but the content owner may have defined high bars against 1573 unauthenticated copying of even the end-to-end encrypted content, and 1574 in this case AD-1/AD-2 can agree on additional transport encryption 1575 across that peering link. In the case of a broadcast peering 1576 connection (e.g.: IXP), transport encryption is also the easiest way 1577 to prohibit unauthenticated copies by other ADs on the same peering 1578 point. 1580 If peering is across a tunnel going across intermittent transit ADs 1581 (not discused in detail in this document), then encryption of that 1582 tunnel traffic is recommended. It not only prohibits possible 1583 "leakage" of content, but also to protects the the information what 1584 content is being consumed in AD-2 (aggregated privacy protection). 1586 See the following subsection for reasons why the peering point may 1587 also need to be encrypted for operational reasons. 1589 6.4. Operational Aspects 1591 Section 4.3.3 discusses exchange of log information, this section 1592 discussed exchange of (S,G) information and Section 7 discusses 1593 exhange of program information. All these operational pieces of data 1594 should by default be exchanged via authenticated and encrypted peer- 1595 to-peer communication protocols between AD-1 and AD-2 so that only 1596 the intended recipient in the peers AD have access to it. Even 1597 exposure of the least sensitive information to third parties opens up 1598 attack vectors. Putting for example valid (S,G) information into DNS 1599 (as opposed to passing it via secured channels from AD-1 to AD-2) to 1600 allow easier filtering of invalid (S,G) would also allow attackers to 1601 easier identify valid (S,G) and change their attack vector. 1603 From the perspective of the ADs, security is most critical for the 1604 log information as it provides operational insight into the 1605 originating AD, but it also contains sensitive user data: 1607 Sensitive user data exported from AD-2 to AD-1 as part of logs could 1608 be as much as the equivalent of 5-tuple unicast traffic flow 1609 accounting (but not more, e.g.: no application level information). 1610 As mentioned in Section 7, in unicast, AD-1 could capture these 1611 traffic statistics itself because this is all about AD-1 originated 1612 traffic flows to EU receivers in AD-2, and operationally passing it 1613 from AD-2 to AD-1 may be necessary when IP multicast is used because 1614 of the replication happening in AD-2. 1616 Nevertheless, passing such traffic statistics inside AD-1 from a 1617 capturing router to a backend system is likely less subject to third 1618 party attacks then passing it interdomain from AD-2 to AD-1, so more 1619 diligence needs to be applied to secure it. 1621 If any protocols used for the operational information exchange are 1622 not easily secured at transport layer or higher (because of the use 1623 of legacy products or protocols in the network), then AD-1 and AD-2 1624 can also consider to ensure that all operational data exchange goes 1625 across the same peering point as the traffic and use network layer 1626 encryption of the peering point as discussed in before to protect it. 1628 End-to-end authentication and authorization of EU may involve some 1629 kind of token authentication and is done at the application layer 1630 independently of the two AD's. If there are problems related to 1631 failure of token authentication when end-users are supported by AD-2, 1632 then some means of validating proper working of the token 1633 authentication process (e.g., back-end servers querying the multicast 1634 application source provider's token authentication server are 1635 communicating properly) should be considered. Implementation details 1636 are beyond the scope of this document. 1638 Security Breach Mitigation Plan - In the event of a security breach, 1639 the two AD's are expected to have a mitigation plan for shutting down 1640 the peering point and directing multicast traffic over alternative 1641 peering points. It is also expected that appropriate information 1642 will be shared for the purpose of securing the identified breach. 1644 7. Privacy Considerations 1646 The described flow of information about content and the end-user 1647 described in this document aims to maintain privacy: 1649 AD-1 is operating on behalf (or owns) the content source and is 1650 therefore part of the content-consumption relationship with the end- 1651 user. The privacy considerations between the EU and AD-1 are 1652 therefore in general (exception see below) the same as if no IP 1653 multicast was used, especially because for any privacy conscious 1654 content, end-to-end encryption can and should be used. 1656 Interdomain multicast transport service related information is 1657 provided by the AD-2 operators to AD-1. AD-2 is not required to gain 1658 additional insight into the user behavior through this process that 1659 it would not already have without the service collaboration with AD-1 1660 - unless AD-1 and AD-2 agree on it and get approval from the EU. 1662 For example, if it is deemed beneficial for EU to directly get 1663 support from AD-2 then it would in general be necessary for AD-2 to 1664 be aware of the mapping between content and network (S,G) state so 1665 that AD-2 knows which (S,G) to troubleshoot when the EU complains 1666 about problems with a specific content. The degree to which this 1667 dissemination is done by AD-1 explicitly to meet privacy expectations 1668 of EUs is typically easy to assess by AD-1. Two simple examples: 1670 For a sports content bundle, every EU will happily click on the "i 1671 approve that the content program information is shared with your 1672 service provider" button, to ensure best service reliability because 1673 service conscious AD-2 would likely also try to ensure that high 1674 value content, such as the (S,G) for SuperBowl like content would be 1675 the first to receive care in case of network issues. 1677 If the content in question was one where the EU expected more 1678 privacy, the EU should prefer a content bundle that included this 1679 content in a large variety of other content, have all content end-to- 1680 end encrypted and the programming information not be shared with AD-2 1681 to maximize privacy. Nevertheless, the privacy of the EU against 1682 AD-2 observing traffic would still be lower than in the equivalent 1683 setup using unicast, because in unicast, AD-2 could not correlate 1684 which EUs are watching the same content and use that to deduce the 1685 content. Note that even the setup in Section 3.4 where AD-2 is not 1686 involved in IP multicast at all does not provide privacy against this 1687 level of analysis by AD-2 because there is no transport layer 1688 encryption in AMT and therefore AD-2 can correlate by onpath traffic 1689 analysis who is consuming the same content from an AMT relay from 1690 both the (S,G) join messages in AMT and the identical content 1691 segments (that where replicated at the AMT relay). 1693 In summary: Because only content to be consumed by multiple EUs is 1694 carried via IP multicast here, and all that content can be end-to-end 1695 encrypted, the only IP multicast specific privacy consideration is 1696 for AD-2 to know or reconstruct what content an EU is consuming. For 1697 content for which this is undesirable, some form of protections as 1698 explained above are possible, but ideally, the model of Section 3.4 1699 could be used in conjunction with future work adding e.g.: dTLS 1700 [RFC6347] encryption between AMT relay and EU. 1702 Note that IP multicast by nature would permit the EU privacy against 1703 the countent source operator because unlike unicast, the content 1704 source does not natively know which EU is consuming which content: In 1705 all cases where AD-2 provides replication, only AD-2 does know this 1706 directly. This document does not attempt to describe a model that 1707 does maintain such level of privacy against the content source but 1708 only against exposure to intermediate parties, in this case AD-2. 1710 8. IANA Considerations 1712 No considerations identified in this document. 1714 9. Acknowledgments 1716 The authors would like to thank the following individuals for their 1717 suggestions, comments, and corrections: 1719 Mikael Abrahamsson 1721 Hitoshi Asaeda 1723 Dale Carder 1725 Tim Chown 1727 Leonard Giuliano 1729 Jake Holland 1731 Joel Jaeggli 1733 Albert Manfredi 1735 Stig Venaas 1737 Henrik Levkowetz 1739 10. Change log [RFC Editor: Please remove] 1741 Please see discussion on mailing list for changes before -111. 1743 -11: version in IESG review. 1745 -12: XML'ified version of -11, committed solely to make rfcdiff 1746 easier. XML versions hosted on https://www.github.com/toerless/ 1747 peering-bcp 1749 -13: 1751 o IESG feedback. Complete details in: 1752 https://raw.githubusercontent.com/toerless/peering-bcp/master/11- 1753 iesg-review-reply.txt 1755 o Ben Campbell: Location information about EU (End User) is Network 1756 Locatio information 1758 o Ben Campbell: Added explanation of assumption to introduction that 1759 traffic is sourced from AD-1 to (one or many) AD-2, mentioned that 1760 sourcing from EU is out of scope. 1762 o Introduction: moved up bullet points about exchanges and transit 1763 to clean up flow of assumptions. 1765 o Ben Campbell: Added picture for the GRE case, visualized tunnels 1766 in all pictures. 1768 o Ben Campbell: See 13-discus.txt on github for more details of 1769 changes for this review. 1771 o Alissia Cooper: Added more explanation for Log Management, 1772 explained privacy context. 1774 o Alissia Cooper: removed pre pre-RFC5378 disclaimer. 1776 o Alissia Cooper: removed mentioning of potential mutual 1777 compensation between domains if the other violates SLA. 1779 o Mirja Kuehlewind: created section 4.1.1 to discuss congestion 1780 control more detailled, adding reference to BCP145, removed stub 1781 CC paragraphs from section 3.1 (principle applies to every section 1782 3.x, and did not want to duplicate text between 3.x and 4.x). 1784 o Mirja Kuehlewind: removed section 8 (conclusion). Text was not 1785 very good, not important to hae conclusion, maybe bring back with 1786 better text if strong interest. 1788 o Introduced section about broadcast peering points because there 1789 where too many places already where references to that case 1790 existed (4.2.4). 1792 o Introduced section about privact considerations because of comment 1793 by Ben Campbell and Alissa Cooper. 1795 o Rewrote security considerations and structured it into key 1796 aspects: DoS attacks, content protection, peering point encryption 1797 and operational aspects. 1799 o Kathleen Moriarty: Added operational aspects to security section 1800 (also for Alissia), e.g.: covering securing the exchange of 1801 operational data between ADs. 1803 o Spencer Dawkins: Various editorial fixes. Removed BCP38 text from 1804 section 3, superceeded be explanation of PIM-SM RPF check to 1805 provide equvialent security to BCP38 in security section 7.1). 1807 o Eric Roscorla: (fixed from other reviews already). 1809 o Adam Roach: Fixed up text about MDH-04, added reference to 1810 RFC4786. 1812 11. References 1814 11.1. Normative References 1816 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1817 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1818 DOI 10.17487/RFC2784, March 2000, 1819 . 1821 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1822 Thyagarajan, "Internet Group Management Protocol, Version 1823 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, 1824 . 1826 [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener 1827 Discovery Version 2 (MLDv2) for IPv6", RFC 3810, 1828 DOI 10.17487/RFC3810, June 2004, 1829 . 1831 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1832 "Multiprotocol Extensions for BGP-4", RFC 4760, 1833 DOI 10.17487/RFC4760, January 2007, 1834 . 1836 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1837 Group Management Protocol Version 3 (IGMPv3) and Multicast 1838 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1839 Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, 1840 August 2006, . 1842 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 1843 Independent Multicast - Sparse Mode (PIM-SM) Multicast 1844 Routing Security Issues and Enhancements", RFC 4609, 1845 DOI 10.17487/RFC4609, October 2006, 1846 . 1848 [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, 1849 DOI 10.17487/RFC7450, February 2015, 1850 . 1852 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 1853 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 1854 Multicast - Sparse Mode (PIM-SM): Protocol Specification 1855 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 1856 2016, . 1858 [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: 1859 Defeating Denial of Service Attacks which employ IP Source 1860 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 1861 May 2000, . 1863 [BCP41] Floyd, S., "Congestion Control Principles", BCP 41, 1864 RFC 2914, DOI 10.17487/RFC2914, September 2000, 1865 . 1867 [BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage 1868 Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, 1869 March 2017, . 1871 11.2. Informative References 1873 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1874 Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, 1875 December 2006, . 1877 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1878 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1879 January 2012, . 1881 [INF_ATIS_10] 1882 "CDN Interconnection Use Cases and Requirements in a 1883 Multi-Party Federation Environment", ATIS Standard 1884 A-0200010, December 2012. 1886 [MDH-04] Thaler, D. and others, "Multicast Debugging Handbook", 1887 IETF I-D draft-ietf-mboned-mdh-04.txt, May 2000. 1889 [Traceroute] 1890 , . 1892 [I-D.ietf-mboned-mtrace-v2] 1893 Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: 1894 Traceroute Facility for IP Multicast", draft-ietf-mboned- 1895 mtrace-v2-20 (work in progress), October 2017. 1897 Authors' Addresses 1899 Percy S. Tarapore (editor) 1900 AT&T 1902 Phone: 1-732-420-4172 1903 Email: tarapore@att.com 1905 Robert Sayko 1906 AT&T 1908 Phone: 1-732-420-3292 1909 Email: rs1983@att.com 1911 Greg Shepherd 1912 Cisco 1914 Email: shep@cisco.com 1916 Toerless Eckert (editor) 1917 Futurewei Technologies Inc. 1919 Email: tte+ietf@cs.fau.de 1921 Ram Krishnan 1922 SupportVectors 1924 Email: ramkri123@gmail.com