idnits 2.17.1 draft-tarapore-mboned-multicast-cdni-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview of Inter-domain Multicast Application Transport' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 115 has weird spacing: '...Catalog all ...' == Line 242 has weird spacing: '...network envi...' == Line 255 has weird spacing: '... Users in A...' == Line 308 has weird spacing: '... f. It is r...' == Line 311 has weird spacing: '... entire netwo...' == (3 more instances...) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 21, 2013) is 3839 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC4607' on line 606 looks like a reference -- Missing reference section? 'RFC4604' on line 601 looks like a reference -- Missing reference section? 'RFC2784' on line 595 looks like a reference -- Missing reference section? 'IETF-ID-AMT' on line 598 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Percy S. Tarapore 2 Internet Draft Robert Sayko 3 Intended status: BCP AT&T 4 Expires: April 21, 2014 Greg Shepherd 5 Toerless Eckert 6 Cisco 7 Ram Krishnan 8 Brocade 9 October 21, 2013 11 Multicasting Applications Across Inter-Domain Peering Points 12 draft-tarapore-mboned-multicast-cdni-04.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other documents 26 at any time. It is inappropriate to use Internet-Drafts as 27 reference material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on April 21, 2014. 31 Copyright Notice 33 Copyright (c) 2013 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with 41 respect to this document. Code Components extracted from this 42 document must include Simplified BSD License text as described in 43 Section 4.e of the Trust Legal Provisions and are provided without 44 warranty as described in the Simplified BSD License. 46 IETF I-D Multicasting Applications Across Peering Points October 2013 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Abstract 62 This document examines the process of transporting applications via 63 multicast across inter-domain peering points. The objective is to 64 describe the setup process for multicast-based delivery across 65 administrative domains and document supporting functionality to 66 enable this process. 68 Table of Contents 70 1. Introduction...................................................3 71 2. Overview of Inter-domain Multicast Application Transport.......3 72 3. Inter-domain Peering Point Requirements for Multicast..........5 73 3.1. Native Multicast..........................................5 74 3.2. Peering Point Enabled with GRE Tunnel.....................6 75 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 76 Enabled........................................................8 77 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 78 Enabled........................................................9 79 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through 80 AD-2..........................................................11 81 4. Supporting Functionality......................................13 82 4.1. Network Transport and Security Guidelines................14 83 4.2. Routing Aspects and Related Guidelines...................14 84 4.3. Back Office Functions - Billing and Logging Guidelines...14 85 4.4. Operations - Service Performance and Monitoring Guidelines14 86 4.5. Reliability Models/Service Assurance Guidelines..........14 87 4.6. Provisioning Guidelines..................................14 88 4.7. Client Models............................................14 89 4.8. Addressing Guidelines....................................14 90 5. Security Considerations.......................................15 91 6. IANA Considerations...........................................15 92 7. Conclusions...................................................15 93 8. References....................................................15 95 IETF I-D Multicasting Applications Across Peering Points October 2013 97 8.1. Normative References.....................................15 98 8.2. Informative References...................................15 99 9. Acknowledgments...............................................15 101 1. Introduction 103 Several types of applications (e.g., live video streaming, software 104 downloads) are well suited for delivery via multicast means. The use 105 of multicast for delivering such applications offers significant 106 savings for utilization of resources in any given administrative 107 domain. End user demand for such applications is growing. Often, 108 this requires transporting such applications across administrative 109 domains via inter-domain peering points. 111 The objective of this Best Current Practices document is twofold: 112 o Describe the process and establish guidelines for setting up 113 multicast-based delivery of applications across inter-domain 114 peering points, and 115 o Catalog all required information exchange between the 116 administrative domains to support multicast-based delivery. 118 While there are several multicast protocols available for use, this 119 BCP will focus the discussion to those that are applicable and 120 recommended for the peering requirements of today's service model, 121 including: 123 o Protocol Independent Multicast - Source Specific Multicast 124 (PIM-SSM) [RFC4607] 125 o Internet Group Management Protocol (IGMP) v3 [RFC4604] 126 o Multicast Listener Discovery (MLD) [RFC4604] 128 This document therefore serves the purpose of a "Gap Analysis" 129 exercise for this process. The rectification of any gaps identified 130 - whether they involve protocol extension development or otherwise - 131 is beyond the scope of this document and is for further study. 133 2. Overview of Inter-domain Multicast Application Transport 135 A multicast-based application delivery scenario is as follows: 136 o Two independent administrative domains are interconnected via a 137 peering point. 139 IETF I-D Multicasting Applications Across Peering Points October 2013 141 o The peering point is either multicast enabled (end-to-end 142 native multicast across the two domains) or it is connected by 143 one of two possible tunnel types: 144 o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] 145 allowing multicast tunneling across the peering point, or 146 o An Automatic Multicast Tunnel (AMT) [IETF-ID-AMT]. 147 o The application stream originates at a source in Domain 1. 148 o An End User associated with Domain 2 requests the application. 149 It is assumed that the application is suitable for delivery via 150 multicast means (e.g., live steaming of major events, software 151 downloads to large numbers of end user devices, etc.) 152 o The request is communicated to the application source which 153 provides the relevant multicast delivery information to the EU 154 device via a "manifest file". At a minimum, this file contains 155 the {Source, Group} or (S,G) information relevant to the 156 multicast stream. 157 o The application client in the EU device then joins the 158 multicast stream distributed by the application source in 159 domain 1 utilizing the (S,G) information provided in the 160 manifest file. The manifest file may also contain additional 161 information that the application client can use to locate the 162 source and join the stream. 164 It should be noted that the second administrative domain - domain 2 165 - may be an independent network domain (e.g., Tier 1 network 166 operator domain) or it could also be an Enterprise network operated 167 by a single customer. The peering point architecture and 168 requirements may have some unique aspects associated with the 169 Enterprise case. 171 The Use Cases describing various architectural configurations for 172 the multicast distribution along with associated requirements is 173 described in section 3. Unique aspects related to the Enterprise 174 network possibility will be described in this section. A 175 comprehensive list of pertinent information that needs to be 176 exchanged between the two domains to support various functions 177 enabling the application transport is provided in section 4. 179 IETF I-D Multicasting Applications Across Peering Points October 2013 181 3. Inter-domain Peering Point Requirements for Multicast 183 The transport of applications using multicast requires that the 184 inter-domain peering point is enabled to support such a process. 185 There are three possible Use Cases for consideration. 187 3.1. Native Multicast 189 This Use Case involves end-to-end Native Multicast between the two 190 administrative domains and the peering point is also native 191 multicast enabled - Figure 1. 193 ------------------- ------------------- 194 / AD-1 \ / AD-2 \ 195 / (Multicast Enabled) \ / (Multicast Enabled) \ 196 / \ / \ 197 | +----+ | | | 198 | | | +------+ | | +------+ | +----+ 199 | | CS |------>| BR |-|---------|->| BR |-------------|-->| EU | 200 | | | +------+ | I1 | +------+ |I2 +----+ 201 \ +----+ / \ / 202 \ / \ / 203 \ / \ / 204 ------------------- ------------------- 206 AD = Administrative Domain (Independent Autonomous System) 207 CS = Content Multicast Source 208 BR = Border Router 209 I1 = AD-1 and AD-2 Multicast Interconnection (MBGP or BGMP) 210 I2 = AD-2 and EU Multicast Connection 212 Figure 1 - Content Distribution via End to End Native Multicast 214 Advantages of this configuration are: 216 o Most efficient use of bandwidth in both domains 218 o Fewer devices in the path traversed by the multicast stream 219 when compared to unicast transmissions. 221 From the perspective of AD-1, the one disadvantage associated with 222 native multicast into AD-2 instead of individual unicast to every EU 224 IETF I-D Multicasting Applications Across Peering Points October 2013 226 in AD-2 is that it does not have the ability to count the number of 227 End Users as well as the transmitted bytes delivered to them. This 228 information is relevant from the perspective of customer billing and 229 operational logs. It is assumed that such data will be collected by 230 the application layer. The application layer mechanisms for 231 generating this information need to be robust enough such that all 232 pertinent requirements for the source provider and the AD operator 233 are satisfactorily met. The specifics of these methods are beyond 234 the scope of this document. 236 Architectural guidelines for this configuration are as follows: 238 a. Dual homing for peering points between domains is recommended 239 as a way to ensure reliability with full BGP table visibility. 241 b. If the peering point between AD-1 and AD-2 is a controlled 242 network environment, then bandwidth can be allocated 243 accordingly by the two domains to permit the transit of non- 244 rate adaptive multicast traffic. If this is not the case, then 245 it is recommended that the multicast traffic should support 246 rate-adaption. 248 c. The sending and receiving of multicast traffic between two 249 domains is typically determined by local policies associated 250 with each domain. For example, if AD-1 is a service provider 251 and AD-2 is an enterprise, then AD-1 may support local policies 252 for traffic delivery to, but not traffic reception from AD-2. 254 d. Relevant information on multicast streams delivered to End 255 Users in AD-2 is assumed to be collected by available 256 capabilities in the application layer. The precise nature and 257 formats of the collected information will be determined by 258 directives from the source owner and the domain operators. 260 3.2. Peering Point Enabled with GRE Tunnel 262 The peering point is not native multicast enabled in this Use Case. 263 There is a Generic Routing Encapsulation Tunnel provisioned over the 264 peering point. In this case, the interconnection I1 between AD-1 and 265 AD-2 in Figure 1 is multicast enabled via a Generic Routing 266 Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast 267 protocols across the interface. The routing configuration is 268 basically unchanged: Instead of BGP (SAFI2) across the native IP 270 IETF I-D Multicasting Applications Across Peering Points October 2013 272 multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across 273 the GRE tunnel. 275 Advantages of this configuration: 277 o Highly efficient use of bandwidth in both domains although not 278 as efficient as the fully native multicast Use Case. 280 o Fewer devices in the path traversed by the multicast stream 281 when compared to unicast transmissions. 283 o Ability to support only partial IP multicast deployments in AD- 284 1 and/or AD-2. 286 o GRE is an existing technology and is relatively simple to 287 implement. 289 Disadvantages of this configuration: 291 o Per Use Case 3.1, current router technology cannot count the 292 number of end users or the number bytes transmitted. 294 o GRE tunnel requires manual configuration. 296 o GRE must be in place prior to stream starting. 298 o GRE is often left pinned up 300 Architectural guidelines for this configuration include the 301 following: 303 Guidelines (a) through (d) are the same as those described in Use 304 Case 3.1. 306 e. GRE tunnels are typically configured manually between peering 307 points to support multicast delivery between domains. 308 f. It is recommended that the GRE tunnel (tunnel server) 309 configuration in the source network is such that it only 310 advertises the routes to the content sources and not to the 311 entire network. This practice will prevent unauthorized 312 delivery of content through the tunnel (e.g., if content is not 313 part of an agreed CDN partnership). 315 IETF I-D Multicasting Applications Across Peering Points October 2013 317 3.3. Peering Point Enabled with an AMT - Both Domains Multicast 318 Enabled 320 Both administrative domains in this Use Case are assumed to be 321 native multicast enabled here; however the peering point is not. The 322 peering point is enabled with an Automatic Multicast Tunnel. The 323 basic configuration is depicted in Figure 2. 325 ------------------- ------------------- 326 / AD-1 \ / AD-2 \ 327 / (Multicast Enabled) \ / (Multicast Enabled) \ 328 / \ / \ 329 | +----+ | | | 330 | | | +------+ | | +------+ | +----+ 331 | | CS |------>| AR |-|---------|->| AG |-------------|-->| EU | 332 | | | +------+ | I1 | +------+ |I2 +----+ 333 \ +----+ / \ / 334 \ / \ / 335 \ / \ / 336 ------------------- ------------------- 338 AR = AMT Relay 339 AG = AMT Gateway 340 I1 = AMT Interconnection between P-CDN and S-CDN 341 I2 = S-CDN and EU Multicast Connection 343 Figure 2 - AMT Interconnection between AD-1 and AD-2 345 Advantages of this configuration: 347 o Highly efficient use of bandwidth in AD-1. 349 o AMT is an existing technology and is relatively simple to 350 implement. Attractive properties of AMT include the following: 352 o Dynamic interconnection between Gateway-Relay pair across 353 the peering point. 355 o Ability to serve clients and servers with differing 356 policies. 358 Disadvantages of this configuration: 360 IETF I-D Multicasting Applications Across Peering Points October 2013 362 o Per Use Case 3.1 (AD-2 is native multicast), current router 363 technology cannot count the number of end users or the number 364 bytes transmitted. 366 o Additional devices (AMT Gateway and Relay pairs) may be 367 introduced into the path if these services are not incorporated 368 in the existing routing nodes. 370 o Currently undefined mechanisms to select the AR from the AG 371 automatically. 373 Architectural guidelines for this configuration are as follows: 375 Guidelines (a) through (d) are the same as those described in Use 376 Case 3.1. 378 e. It is recommended that AMT Relay and Gateway pairs be 379 configured at the peering points to support multicast delivery 380 between domains. AMT tunnels will then configure dynamically 381 across the peering points once the Gateway in AD-2 receives the 382 (S, G) information from the EU. 384 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 386 In this AMT Use Case, the second administrative domain AD-2 is not 387 multicast enabled. This implies that the interconnection between AD- 388 2 and the End User is also not multicast enabled as depicted in 389 Figure 3. 391 IETF I-D Multicasting Applications Across Peering Points October 2013 393 ------------------- ------------------- 394 / AD-1 \ / AD-2 \ 395 / (Multicast Enabled) \ / (Non-Multicast \ 396 / \ / Enabled) \ 397 | +----+ | | | 398 | | | +------+ | | | +----+ 399 | | CS |------>| AR |-|---------|-----------------------|-->|EU/G| 400 | | | +------+ | | |I2 +----+ 401 \ +----+ / \ / 402 \ / \ / 403 \ / \ / 404 ------------------- ------------------- 406 CS = Content Source 407 AR = AMT Relay 408 EU/G = Gateway client embedded in EU device 409 I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast 410 Enabled AD-2. 412 Figure 3 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 414 This Use Case is equivalent to having unicast distribution of the 415 application through AD-2. The total number of AMT tunnels would be 416 equal to the total number of End Users requesting the application. 417 The peering point thus needs to accommodate the total number of AMT 418 tunnels between the two domains. Each AMT tunnel can provide the 419 data usage associated with each End User. 421 Advantages of this configuration: 423 o Highly efficient use of bandwidth in AD-1. 425 o AMT is an existing technology and is relatively simple to 426 implement. Attractive properties of AMT include the following: 428 o Dynamic interconnection between Gateway-Relay pair across 429 the peering point. 431 o Ability to serve clients and servers with differing 432 policies. 434 o Each AMT tunnel serves as a count for each End User and is also 435 able to track data usage (bytes) delivered to the EU. 437 IETF I-D Multicasting Applications Across Peering Points October 2013 439 Disadvantages of this configuration: 441 o Additional devices (AMT Gateway and Relay pairs) are introduced 442 into the transport path. 444 o Assuming multiple peering points between the domains, the EU 445 Gateway needs to be able to find the "correct" AMT Relay in AD- 446 1. 448 Architectural guidelines for this configuration are as follows: 450 Guidelines (a) through (c) are the same as those described in Use 451 Case 3.1. 453 d. It is recommended that proper procedures are implemented such 454 that the AMT Gateway at the End User device is able to find the 455 correct AMT Relay in AD-1 across the peering points. The 456 application client in the EU device is expected to supply the (S, 457 G) information to the Gateway for this purpose. 459 e. The AMT tunnel capabilities are expected to be sufficient for 460 the purpose of collecting relevant information on the multicast 461 streams delivered to End Users in AD-2. 463 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 465 This is a variation of Use Case 3.4 as follows: 467 IETF I-D Multicasting Applications Across Peering Points October 2013 469 ------------------- ------------------- 470 / AD-1 \ / AD-2 \ 471 / (Multicast Enabled) \ / (Non-Multicast \ 472 / \ / Enabled) \ 473 | +----+ | |+--+ +--+ | 474 | | | +------+ | ||AG| |AG| | +----+ 475 | | CS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| 476 | | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ 477 \ +----+ / \+--+ +--+ / 478 \ / \ / 479 \ / \ / 480 ------------------- ------------------- 482 (Note: Diff-marks for the figure have been removed to improve 483 viewing) 485 CS = Content Source 486 AR = AMT Relay in AD-1 487 AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point 488 I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 489 AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge 490 I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 491 EU/G = Gateway client embedded in EU device 492 I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 494 Figure 4 - AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway 496 Use Case 3.4 results in several long AMT tunnels crossing the entire 497 network of AD-2 linking the EU device and the AMT Relay in AD-1 498 through the peering point. Depending on the number of End Users, 499 there is a likelihood of an unacceptably large number of AMT tunnels 500 - and unicast streams - through the peering point. This situation 501 can be alleviated as follows: 503 o Provisioning of strategically located AMT nodes at the edges of 504 AD-2. An AMT node comprises co-location of an AMT Gateway and 505 an AMT Relay. One such node is at the AD-2 side of the peering 506 point (node AGAR1 in Figure 4). 508 o Single AMT tunnel established across peering point linking AMT 509 Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. 511 o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to 512 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel 514 IETF I-D Multicasting Applications Across Peering Points October 2013 516 I2 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 517 in Figure 4. 519 o AMT tunnels linking EU device (via Gateway client embedded in 520 device) and AMT Relay in appropriate AMT node at edge of AD-2: 521 e.g., I3 linking EU Gateway in device to AMT Relay in AMT node 522 AGAR2. 524 The advantage for such a chained set of AMT tunnels is that the 525 total number of unicast streams across AD-2 is significantly reduced 526 thus freeing up bandwidth. Additionally, there will be a single 527 unicast stream across the peering point instead of possibly, an 528 unacceptably large number of such streams per Use Case 3.4. However, 529 this implies that several AMT tunnels will need to be dynamically 530 configured by the various AMT Gateways based solely on the (S,G) 531 information received from the application client at the EU device. A 532 suitable mechanism for such dynamic configurations is therefore 533 critical. 535 Architectural guidelines for this configuration are as follows: 537 Guidelines (a) through (c) are the same as those described in Use 538 Case 3.1. 540 d. It is recommended that proper procedures are implemented such 541 that the various AMT Gateways (at the End User devices and the AMT 542 nodes in AD-2) are able to find the correct AMT Relay in other AMT 543 nodes as appropriate. The application client in the EU device is 544 expected to supply the (S, G) information to the Gateway for this 545 purpose. 547 e. The AMT tunnel capabilities are expected to be sufficient for 548 the purpose of collecting relevant information on the multicast 549 streams delivered to End Users in AD-2. 551 4. Supporting Functionality 553 Supporting functions and related interfaces over the peering point 554 that enable the multicast transport of the application are listed in 555 this section. Critical information parameters that need to be 556 exchanged in support of these functions are enumerated along with 557 guidelines as appropriate. Specific interface functions for 558 consideration are as follows. 560 IETF I-D Multicasting Applications Across Peering Points October 2013 562 4.1. Network Transport and Security Guidelines 564 4.2. Routing Aspects and Related Guidelines 566 4.3. Back Office Functions - Billing and Logging Guidelines 568 4.4. Operations - Service Performance and Monitoring Guidelines 570 4.5. Reliability Models/Service Assurance Guidelines 572 4.6. Provisioning Guidelines 574 In order to find right relay there is a need for a small/light 575 implementation of an AMT DNS in source network. 577 4.7. Client Models 579 4.8. Addressing Guidelines 581 IETF I-D Multicasting Applications Across Peering Points October 2013 583 5. Security Considerations 585 (Include discussion on DRM, AAA, Network Security) 587 6. IANA Considerations 589 7. Conclusions 591 8. References 593 8.1. Normative References 595 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 596 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 598 [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- 599 ietf-mboned-auto-multicast-13, April 2012, Work in progress 601 [RFC4604] H. Holbrook, et al, "Using Internet Group Management 602 Protocol Version 3 (IGMPv3) and Multicast Listener Discovery 603 Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, 604 August 2006 606 [RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607, 607 August 2006 609 8.2. Informative References 611 9. Acknowledgments 613 IETF I-D Multicasting Applications Across Peering Points October 2013 615 Authors' Addresses 617 Percy S. Tarapore 618 AT&T 619 Phone: 1-732-420-4172 620 Email: tarapore@att.com 622 Robert Sayko 623 AT&T 624 Phone: 1-732-420-3292 625 Email: rs1983@att.com 627 Greg Shepherd 628 Cisco 629 Phone: 630 Email: shep@cisco.com 632 Toerless Eckert 633 Cisco 634 Phone: 635 Email: eckert@cisco.com 637 Ram Krishnan 638 Brocade 639 Phone: 640 Email: ramk@brocade.com