--- 1/draft-ietf-mboned-interdomain-peering-bcp-00.txt 2016-01-21 13:16:25.229346672 -0800 +++ 2/draft-ietf-mboned-interdomain-peering-bcp-01.txt 2016-01-21 13:16:25.301348479 -0800 @@ -1,43 +1,43 @@ MBONED Working Group Percy S. Tarapore Internet Draft Robert Sayko Intended status: BCP AT&T -Expires: January 20, 2016 Greg Shepherd +Expires: July 20, 2016 Greg Shepherd Toerless Eckert Cisco Ram Krishnan Brocade - July 20, 2015 + January 21, 2016 Use of Multicast Across Inter-Domain Peering Points - draft-ietf-mboned-interdomain-peering-bcp-00.txt + draft-ietf-mboned-interdomain-peering-bcp-01.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 January 20, 2016. + This Internet-Draft will expire on July 21, 2016. Copyright Notice - Copyright (c) 2015 IETF Trust and the persons identified as the + 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without @@ -82,25 +82,25 @@ 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...19 4.3.1 Provisioning Guidelines...........................19 4.3.2 Application Accounting Billing 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 - 7. IANA Considerations...........................................25 + 7. IANA Considerations...........................................26 8. Conclusions...................................................26 9. References....................................................26 9.1. Normative References.....................................26 - 9.2. Informative References...................................26 + 9.2. Informative References...................................27 10. Acknowledgments..............................................27 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 @@ -124,24 +124,26 @@ Discovery (MLD) [RFC4604], and Multicast Source Discovery Protocol (MSDP) [RFC3618]. This BCP is independent of the choice of multicast protocol; it focuses solely on the implications for the inter-domain peering points. However, in order to help explain use cases the figures will use the general SSM flows and architectures. o Network Administrative Domains involved in setting up multicast peering points 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. + 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 @@ -250,28 +253,35 @@ b. If the peering point between AD-1 and AD-2 is a controlled network environment, then bandwidth can be allocated accordingly by the two domains to permit the transit of non-rate adaptive multicast traffic. If this is not the case, then it is recommended that the multicast traffic should support rate-adaption. c. The sending and receiving of multicast traffic between two domains is typically determined by local policies associated with each domain. For example, if AD-1 is a service provider and AD-2 is an enterprise, then AD-1 may support local policies for traffic - delivery to, but not traffic reception from AD-2. + delivery to, but not traffic reception from AD-2. Another example + is the use of a policy by which AD-1 delivers specified content + to AD-2 only if such delivery has been accepted by contract. d. Relevant information on multicast streams delivered to End Users in AD-2 is assumed to be collected by available capabilities in the application layer. The precise nature and formats of the collected information will be determined by directives from the source owner and the domain operators. + e. The interconnection of AD-1 and AD-2 should minimally follow + guidelines for traffic filtering between autonomous systems + [BCP38]. Filtering guidelines specific to the multicast control- + plane and data-plane are described in section 6. + 3.2. Peering Point Enabled with GRE Tunnel The peering point is not native multicast enabled in this Use Case. There is a Generic Routing Encapsulation Tunnel provisioned over the peering point. In this case, the interconnection I1 between AD-1 and AD-2 in Figure 1 is multicast enabled via a Generic Routing Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast protocols across the interface. The routing configuration is basically unchanged: Instead of BGP (SAFI2) across the native IP multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across @@ -774,21 +783,21 @@ to that stream. o AMT Relay encapsulates the multicast stream into the tunnel between the Relay and the Gateway, providing the requested content to the EU. Note: Further routing discussion on optimal method to find "best AMT Relay/GW combination" and information exchange between AD's to be provided. - 4.3. Back Office Functions - Billing and Logging Guidelines + 4.3. Back Office Functions - Provisioning and Logging Guidelines Back Office refers to the following: o Servers and Content Management systems that support the delivery of applications via multicast and interactions between ADs. o Functionality associated with logging, reporting, ordering, provisioning, maintenance, service assurance, settlement, etc. 4.3.1 Provisioning Guidelines @@ -847,21 +856,21 @@ o Automated interfaces are built between AD-1 and AD-2 such that operations and customer care continue using their own systems. This requires coordination between the two AD's with appropriate provisioning of necessary resources. o AD-1's operations and customer care personnel are provided access directly to AD-2's system. In this scenario, additional provisioning in these systems will be needed to provide necessary access. Additional provisioning must be agreed to by the two AD-2s to support this option. - 4.3.2 Application Accounting Billing Guidelines + 4.3.2 Application Accounting Guidelines All interactions between pairs of ADs can be discovered and/or be associated with the account(s) utilized for delivered applications. Supporting guidelines are as follows: o A unique identifier is recommended to designate each master account. o AD-2 is expected to set up "accounts" (logical facility generally protected by login/password/credentials) for use by AD-1. Multiple accounts and multiple types/partitions of accounts can apply, e.g. @@ -895,21 +904,20 @@ The two ADs may supply additional security logs to each other as agreed to by contract(s). Examples include the following: o Information related to general security-relevant activity which may be of use from a protective or response perspective, such as types and counts of attacks detected, related source information, related target information, etc. o Aggregated or summarized logs according to agreement (with additional detail potentially provided during security events, by agreement) - o 4.4. Operations - Service Performance and Monitoring Guidelines Service Performance refers to monitoring metrics related to multicast delivery via probes. The focus is on the service provided by AD-2 to AD-1 on behalf of all multicast application sources (metrics may be specified for SLA use or otherwise). Associated guidelines are as follows: o Both AD's are expected to monitor, collect, and analyze service @@ -1025,20 +1033,28 @@ monitoring functions or by customer reported problems as described in section 4.4. It is expected that multicast diagnostics will be collected according to currently established practices [MDH-04]. However, given that inter-domain creates a significant interdependence of proper networking functionality between providers there does exist a need for providers to be able to signal/alert each other if there are any issues noted by either one. + Service providers may also wish to allow limited read-only + administrative access to their routers via a looking-glass style + router proxy to facilitate the debugging of multicast control state + and peering status. Software implementations for this purpose is + readily available [Traceroute] and can be easily extended to provide + access to commonly-used multicast troubleshooting commands in a + secure manner. + The specifics of the notification and alerts are beyond the scope of this document, but general guidelines are similar to those described in section 4.4 (Service Performance and Monitoring). Some general communications issues are stated as follows. o Appropriate communications channels will be established between the customer service and operations groups from both AD's to facilitate information sharing related to diagnostic troubleshooting. @@ -1050,25 +1066,28 @@ 6. Security Considerations DRM and Application Accounting, Authorization and Authentication should be the responsibility of the multicast application source provider and/or AD-1. AD-1 needs to work out the appropriate agreements with the source provider. Network has no DRM responsibilities, but might have authentication and authorization obligations. These though are consistent with normal operations of a CDN to insure end user reliability, security - and network security + and network security. AD-1 and AD-2 should have mechanisms in place to ensure proper accounting for the volume of bytes delivered through the peering - point and separately the number of bytes delivered to EUs. + point and separately the number of bytes delivered to EUs. For + example, [BCP38] style filtering could be deployed by both AD's to + ensure that only legitimately sourced multicast content is exchanged + between them. If there are problems related to failure of token authentication when end-users are supported by AD-2, then some means of validating proper working of the token authentication process (e.g., back-end servers querying the multicast application source provider's token authentication server are communicating properly) should be considered. Details will have to be worked out during implementation (e.g., test tokens or trace token exchange process). 7. IANA Considerations @@ -1101,29 +1121,35 @@ 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 + [BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating + Denial of Service Attacks which employ IP Source Address Spoofing", + BCP: 38, May 2000 + 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 + 10. Acknowledgments Authors' Addresses Percy S. Tarapore AT&T Phone: 1-732-420-4172 Email: tarapore@att.com Robert Sayko AT&T