--- 1/draft-ietf-mboned-interdomain-peering-bcp-03.txt 2016-07-29 18:25:43.332633482 -0700 +++ 2/draft-ietf-mboned-interdomain-peering-bcp-04.txt 2016-07-29 18:25:43.384634798 -0700 @@ -1,39 +1,39 @@ MBONED Working Group Percy S. Tarapore Internet Draft Robert Sayko Intended status: BCP AT&T -Expires: December 1, 2016 Greg Shepherd +Expires: January 28, 2017 Greg Shepherd Toerless Eckert Cisco Ram Krishnan Brocade - June 1, 2016 + July 28, 2016 Use of Multicast Across Inter-Domain Peering Points - draft-ietf-mboned-interdomain-peering-bcp-03.txt + draft-ietf-mboned-interdomain-peering-bcp-04.txt Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 1, 2016. + This Internet-Draft will expire on January 28, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,40 +68,41 @@ 2. Overview of Inter-domain Multicast Application Transport.......4 3. Inter-domain Peering Point Requirements for Multicast..........5 3.1. Native Multicast..........................................5 3.2. Peering Point Enabled with GRE Tunnel.....................7 3.3. Peering Point Enabled with an AMT - Both Domains Multicast Enabled........................................................8 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled.......................................................10 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2..........................................................12 - 4. Supporting Functionality......................................13 - 4.1. Network Interconnection Transport and Security Guidelines14 - 4.2. Routing Aspects and Related Guidelines...................14 - 4.2.1 Native Multicast Routing Aspects..................15 - 4.2.2 GRE Tunnel over Interconnecting Peering Point.....16 - 4.2.3 Routing Aspects with AMT Tunnels.....................16 - 4.3. Back Office Functions - Billing and Logging Guidelines...18 - 4.3.1 Provisioning Guidelines...........................19 - 4.3.2 Application Accounting Billing Guidelines.........20 - 4.3.3 Log Management Guidelines.........................20 - 4.4. Operations - Service Performance and Monitoring Guidelines21 + 4. Supporting Functionality......................................14 + 4.1. Network Interconnection Transport and Security Guidelines15 + 4.2. Routing Aspects and Related Guidelines...................15 + 4.2.1 Native Multicast Routing Aspects..................16 + 4.2.2 GRE Tunnel over Interconnecting Peering Point.....17 + 4.2.3 Routing Aspects with AMT Tunnels.....................17 + 4.3. Back Office Functions - Provisioning and Logging Guidelines + ..............................................................19 + 4.3.1 Provisioning Guidelines...........................20 + 4.3.2 Application Accounting Guidelines.................21 + 4.3.3 Log Management Guidelines.........................21 + 4.4. Operations - Service Performance and Monitoring Guidelines22 4.5. Client Reliability Models/Service Assurance Guidelines...24 - 5. Troubleshooting and Diagnostics...............................24 - 6. Security Considerations.......................................25 + 5. Troubleshooting and Diagnostics...............................25 + 6. Security Considerations.......................................26 7. IANA Considerations...........................................26 - 8. Conclusions...................................................26 - 9. References....................................................26 - 9.1. Normative References.....................................26 - 9.2. Informative References...................................27 - 10. Acknowledgments..............................................27 + 8. Conclusions...................................................27 + 9. References....................................................27 + 9.1. Normative References.....................................27 + 9.2. Informative References...................................28 + 10. Acknowledgments..............................................28 1. Introduction Several types of applications (e.g., live video streaming, software downloads) are well suited for delivery via multicast means. The use of multicast for delivering such applications offers significant savings for utilization of resources in any given administrative domain. End user demand for such applications is growing. Often, this requires transporting such applications across administrative domains via inter-domain peering points. @@ -110,37 +111,52 @@ o Describe the technical process and establish guidelines for setting up multicast-based delivery of applications across inter- domain peering points via a set of use cases. o Catalog all required information exchange between the administrative domains to support multicast-based delivery. This enables operators to initiate necessary processes to support inter-domain peering with multicast. The scope and assumptions for this document are stated as follows: + o For the purpose of this document, the term "peering point" + refers to an interface between two networks/administrative + domains over which traffic is exchanged between them. A + Network-Network Interface (NNI) is an example of a peering + point. o Administrative Domain 1 (AD-1) is enabled with native multicast. A peering point exists between AD-1 and AD-2. o It is understood that several protocols are available for this purpose including PIM-SM, Protocol Independent Multicast - Source Specific Multicast (PIM-SSM) [RFC4607], Internet Group Management Protocol (IGMP) [RFC4604], Multicast Listener - Discovery (MLD) [RFC4604]. In the case of inter-domain - peering, it is recommended to use only SSM protocols. + Discovery (MLD) [RFC4604]. + o As described in Section 2, the source IP address of the + multicast stream in the originating AD (AD-1) is known. Under + this condition, PIM-SSM use is beneficial for the reasons + stated in [draft-acq], e.g., it allows the receiver's router + to directly send a JOIN message to the source without the need + of invoking an intermediate Rendezvous Point (RP). Hence, in + the case of inter-domain peering, it is recommended to use + only SSM protocols. o AD-1 and AD-2 are assumed to adopt compatible protocols. The use of different protocols is beyond the scope of this document. - o It is assumed that an AMT Relay will be available to a client - for multicast delivery. The selection of an optimal AMT relay - by a client is out of scope for this document. Note that AMT - use is necessary only when native multicast is unavailable in - the peering point (Use Case 3.3) or in the downstream - administrative domain (Use Cases 3.4, and 3.5). + o An Automatic Multicast Tunnel (AMT) [RFC7450] is setup at the + peering point if either the peering point or AD-2 is not + multicast enabled. It is assumed that an AMT Relay will be + available to a client for multicast delivery. The selection of + an optimal AMT relay by a client is out of scope for this + document. Note that AMT use is necessary only when native + multicast is unavailable in the peering point (Use Case 3.3) + or in the downstream administrative domain (Use Cases 3.4, and + 3.5). o The collection of billing data is assumed to be done at the application level and is not considered to be a networking issue. The settlements process for end user billing and/or inter-provider billing is out of scope for this document. o Inter-domain network connectivity troubleshooting is only considered within the context of a cooperative process between the two domains. This document also attempts to identify ways by which the peering process can be improved. Development of new methods for improvement @@ -149,22 +165,24 @@ 2. Overview of Inter-domain Multicast Application Transport A multicast-based application delivery scenario is as follows: o Two independent administrative domains are interconnected via a peering point. o The peering point is either multicast enabled (end-to-end native multicast across the two domains) or it is connected by one of two possible tunnel types: o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] allowing multicast tunneling across the peering point, or - o An Automatic Multicast Tunnel (AMT) [IETF-ID-AMT]. - o The application stream originates at a source in Domain 1. + o An Automatic Multicast Tunnel (AMT) [RFC7450]. + + o The application stream originates at a source in Domain 1. The + source IP address is known. o An End User associated with Domain 2 requests the application. It is assumed that the application is suitable for delivery via multicast means (e.g., live steaming of major events, software downloads to large numbers of end user devices, etc.) o The request is communicated to the application source which provides the relevant multicast delivery information to the EU device via a "manifest file". At a minimum, this file contains the {Source, Group} or (S,G) information relevant to the multicast stream. o The application client in the EU device then joins the @@ -209,21 +227,21 @@ | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | | | | +------+ | I1 | +------+ |I2 +----+ \ +----+ / \ / \ / \ / \ / \ / ------------------- ------------------- AD = Administrative Domain (Independent Autonomous System) AS = Application (e.g., Content) Multicast Source BR = Border Router - I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP or BGMP) + I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) I2 = AD-2 and EU Multicast Connection Figure 1 - Content Distribution via End to End Native Multicast Advantages of this configuration are: o Most efficient use of bandwidth in both domains o Fewer devices in the path traversed by the multicast stream when compared to unicast transmissions. @@ -565,21 +583,22 @@ o Peering Point Addresses and Locations o Connection Type - Dedicated for Multicast delivery or shared with other services o Connection Mode - Direct connectivity between the two AD's or via another ISP o Peering Point Protocol Support - Multicast protocols that will be used for multicast delivery will need to be supported at these - points. Examples of protocols include eBGP, BGMP, and MBGP. + points. Examples of protocols include eBGP [RFC4271] and MBGP + [RFC4271]. o Bandwidth Allocation - If shared with other services, then there needs to be a determination of the share of bandwidth reserved for multicast delivery. o QoS Requirements - Delay/latency specifications that need to be specified in an SLA. o AD Roles and Responsibilities - the role played by each AD for provisioning and maintaining the set of peering points to support @@ -1102,48 +1120,53 @@ finds the optimal Relay-Gateway combination via the use of an Anycast IP address for AMT Relays. 9. References 9.1. Normative References [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 - [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- - ietf-mboned-auto-multicast-13, April 2012, Work in progress + [RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol", + RFC 3618, October 2003 + + [RFC4271] Y. Rekhter, et al, "A Border Gateway Protocol 4 (BGP-4)", + RFC 4271, January 2006 [RFC4604] H. Holbrook, et al, "Using Internet Group Management Protocol Version 3 (IGMPv3) and Multicast Listener Discovery Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, August 2006 [RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607, August 2006 - [RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol", - RFC 3618, October 2003 + [RFC7450] G. Bumgardner, "Automatic Multicast Tunneling", RFC 7450, + February 2015 [BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP: 38, May 2000 + [draft-acg] M. Abrahamsson, et al, "Multicast Service Models", + draft-acg-mboned-multicast-models-00, July 2017, Work in progress + 9.2. Informative References [INF_ATIS_10] "CDN Interconnection Use Cases and Requirements in a Multi-Party Federation Environment", ATIS Standard A-0200010, December 2012 [MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D - draft-ietf-mboned-mdh-04.txt, May 2000 - - [Traceroute] http://traceroute.org/#source%20code + draft-ietf-mboned-mdh-04.txt, May 2000 [Traceroute] + http://traceroute.org/#source%20code 10. Acknowledgments Authors' Addresses Percy S. Tarapore AT&T Phone: 1-732-420-4172 Email: tarapore@att.com Robert Sayko