Internet Engineering Task Force (IETF) P. Tarapore, Ed. Request for Comments: 8313 R. Sayko BCP: 213 AT&T Category: Best Current Practice G. Shepherd ISSN: 2070-1721 Cisco T. Eckert, Ed. Huawei R. Krishnan SupportVectors January 2018 Use of Multicast across Inter-domain Peering Points
AbstractThis document examines the use of Source-Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objectives are to (1) describe the setup process for multicast-based delivery across administrative domains for these scenarios and (2) document supporting functionality to enable this process. Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8313.
Copyright Notice Copyright (c) 2018 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 (https://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 warranty as described in the Simplified BSD License.
1. Introduction ....................................................4 2. Overview of Inter-domain Multicast Application Transport ........6 3. Inter-domain Peering Point Requirements for Multicast ...........7 3.1. Native Multicast ...........................................8 3.2. Peering Point Enabled with GRE Tunnel .....................10 3.3. Peering Point Enabled with AMT - Both Domains Multicast Enabled .........................................12 3.4. Peering Point Enabled with AMT - AD-2 Not Multicast Enabled .........................................14 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels through AD-2 ..............................................16 4. Functional Guidelines ..........................................18 4.1. Network Interconnection Transport Guidelines ..............18 4.1.1. Bandwidth Management ...............................19 4.2. Routing Aspects and Related Guidelines ....................20 4.2.1. Native Multicast Routing Aspects ...................21 4.2.2. GRE Tunnel over Interconnecting Peering Point ......22 4.2.3. Routing Aspects with AMT Tunnels ...................22 4.2.4. Public Peering Routing Aspects .....................24 4.3. Back-Office Functions - Provisioning and Logging Guidelines ................................................26 4.3.1. Provisioning Guidelines ............................26 4.3.2. Inter-domain Authentication Guidelines .............28 4.3.3. Log-Management Guidelines ..........................28 4.4. Operations - Service Performance and Monitoring Guidelines ................................................30 4.5. Client Reliability Models / Service Assurance Guidelines ..32 4.6. Application Accounting Guidelines .........................32 5. Troubleshooting and Diagnostics ................................32 6. Security Considerations ........................................33 6.1. DoS Attacks (against State and Bandwidth) .................33 6.2. Content Security ..........................................35 6.3. Peering Encryption ........................................37 6.4. Operational Aspects .......................................37 7. Privacy Considerations .........................................39 8. IANA Considerations ............................................40 9. References .....................................................40 9.1. Normative References ......................................40 9.2. Informative References ....................................42 Acknowledgments ...................................................43 Authors' Addresses ................................................44
Section 3.1, "Use Case 3.2" corresponds to Section 3.2, etc.). o Catalog all required exchanges of information 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 as follows: o Administrative Domain 1 (AD-1) sources content to one or more EUs in one or more Administrative Domain 2 (AD-2) entities. AD-1 and AD-2 want to use IP multicast to allow support for large and growing EU populations, with a minimum amount of duplicated traffic to send across network links. * This document does not detail the case where EUs are originating content. To support that additional service, it is recommended that some method (outside the scope of this document) be used by which the content from EUs is transmitted to the application in AD-1 and AD-1 can send out the traffic as IP multicast. From that point on, the descriptions in this document apply, except that they are not complete because they do not cover the transport or operational aspects of the leg from the EU to AD-1. * This document does not detail the case where AD-1 and AD-2 are not directly connected to each other and are instead connected via one or more other ADs (as opposed to a peering point) that serve as transit providers. The cases described in this document where tunnels are used between AD-1 and AD-2 can be applied to such scenarios, but SLA ("Service Level Agreement")
control, for example, would be different. Additional issues will likely exist as well in such scenarios. This topic is left for further study. o For the purposes of this document, the term "peering point" refers to a network connection ("link") between two administrative network domains over which traffic is exchanged between them. This is also referred to as a Network-to-Network Interface (NNI). Unless otherwise noted, it is assumed that the peering point is a private peering point, where the network connection is a physically or virtually isolated network connection solely between AD-1 and AD-2. The other case is that of a broadcast peering point, which is a common option in public Internet Exchange Points (IXPs). See Section 4.2.4 for more details. o 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 Protocol-Independent Multicast - Sparse Mode (PIM-SM) and Protocol-Independent Multicast - Source-Specific Multicast (PIM-SSM) [RFC7761], the Internet Group Management Protocol (IGMP) [RFC3376], and Multicast Listener Discovery (MLD) [RFC3810]. o As described in Section 2, the source IP address of the (so-called "(S,G)") multicast stream in the originating AD (AD-1) is known. Under this condition, using PIM-SSM is beneficial, as it allows the receiver's upstream router to send a join message directly to the source without the need to invoke an intermediate Rendezvous Point (RP). The use of SSM also presents an improved threat mitigation profile against attack, as described in [RFC4609]. Hence, in the case of inter-domain peering, it is recommended that only SSM protocols be used; the setup of inter-domain peering for ASM (Any-Source Multicast) is out of scope for this document. o The rest of this document assumes that PIM-SSM and BGP are used across the peering point, plus Automatic Multicast Tunneling (AMT) [RFC7450] and/or Generic Routing Encapsulation (GRE), according to the scenario in question. The use of other protocols is beyond the scope of this document. o AMT is set up 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 using AMT 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 It is assumed that the collection of billing data is done at the application level and is not considered to be a networking issue. The settlements process for EU 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 is beyond the scope of this document. RFC2784] allowing multicast tunneling across the peering point, or * AMT [RFC7450]. o A service provider controls one or more application sources in AD-1 that will send multicast IP packets via one or more (S,G)s (multicast traffic flows; see Section 4.2.1 if you are unfamiliar with IP multicast). It is assumed that the service being provided is suitable for delivery via multicast (e.g., live video streaming of popular events, software downloads to many devices) and that the packet streams will be carried by a suitable multicast transport protocol. o An EU controls a device connected to AD-2, which runs an application client compatible with the service provider's application source.
o The application client joins appropriate (S,G)s in order to receive the data necessary to provide the service to the EU. The mechanisms by which the application client learns the appropriate (S,G)s are an implementation detail of the application and are out of scope for this document. The assumption here is that AD-1 has ultimate responsibility for delivering the multicast-based service on behalf of the content source(s). All relevant interactions between the two domains described in this document are based on this assumption. Note that AD-2 may be an independent network domain (e.g., a Tier 1 network operator domain). Alternately, AD-2 could also be an enterprise network domain operated by a single customer of AD-1. The peering point architecture and requirements may have some unique aspects associated with enterprise networks; see Section 3. The use cases describing various architectural configurations for multicast distribution, along with associated requirements, are described in Section 3. Section 4 contains a comprehensive list of pertinent information that needs to be exchanged between the two domains in order to support functions to enable application transport.
Figure 1. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Multicast Enabled) \ / \ / \ | +----+ | | | | | | +------+ | | +------+ | +----+ | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | | | | +------+ | I1 | +------+ |I2 +----+ \ +----+ / \ / \ / \ / \ / \ / ------------------- ------------------- AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source BR = Border Router I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP) I2 = AD-2 and EU multicast connection Figure 1: Content Distribution via End-to-End Native Multicast Advantages of this configuration: o Most efficient use of bandwidth in both domains. o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point. From the perspective of AD-1, the one disadvantage associated with native multicast to AD-2 instead of individual unicast to every EU in AD-2 is that it does not have the ability to count the number of EUs as well as the transmitted bytes delivered to them. This information is relevant from the perspective of customer billing and operational logs. It is assumed that such data will be collected by the application layer. The application-layer mechanisms for generating this information need to be robust enough so that all pertinent requirements for the source provider and the AD operator are satisfactorily met. The specifics of these methods are beyond the scope of this document.
Architectural guidelines for this configuration are as follows: a. Dual homing for peering points between domains is recommended as a way to ensure reliability with full BGP table visibility. 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 the multicast traffic must support congestion control via any of the mechanisms described in Section 4.1 of [BCP145]. 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. 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. It is assumed that relevant information on multicast streams delivered to EUs in AD-2 is 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.
Figure 2. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Multicast Enabled) \ / \ / \ | +----+ +---+ | (I1) | +---+ | | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ | | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU | | | | +--+<........|........|........>+--+ |I2 +----+ \ +----+ / I1 \ / \ / GRE \ / \ / Tunnel \ / ------------------- ------------------- AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source uBR = unicast Border Router - not necessarily multicast enabled; may be the same router as BR BR = Border Router - for multicast I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP) I2 = AD-2 and EU multicast connection Figure 2: Content Distribution via GRE Tunnel In this case, interconnection I1 between AD-1 and AD-2 in Figure 2 is multicast enabled via a GRE tunnel [RFC2784] between the two BRs and encapsulating the multicast protocols across it. Normally, this approach is chosen if the uBR physically connected to the peering link cannot or should not be enabled for IP multicast. This approach may also be beneficial if the BR and uBR are the same device but the peering link is a broadcast domain (IXP); see Section 4.2.4. The routing configuration is basically unchanged: instead of running BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family Identifier") across the native IP multicast link between AD-1 and AD-2, BGP (SAFI-2) is now run across the GRE tunnel.
Advantages of this configuration: o Highly efficient use of bandwidth in both domains, although not as efficient as the fully native multicast use case (Section 3.1). o Fewer devices in the path traversed by the multicast stream when compared to an AMT-enabled peering point. o Ability to support partial and/or incremental IP multicast deployments in AD-1 and/or AD-2: only the path or paths between the AS/BR (AD-1) and the BR/EU (AD-2) need to be multicast enabled. The uBRs may not support IP multicast or enabling it could be seen as operationally risky on that important edge node, whereas dedicated BR nodes for IP multicast may (at least initially) be more acceptable. The BR can also be located such that only parts of the domain may need to support native IP multicast (e.g., only the core in AD-1 but not edge networks towards the uBR). o GRE is an existing technology and is relatively simple to implement. Disadvantages of this configuration: o Per Use Case 3.1, current router technology cannot count the number of EUs or the number of bytes transmitted. o The GRE tunnel requires manual configuration. o The GRE tunnel must be established prior to starting the stream. o The GRE tunnel is often left pinned up. Architectural guidelines for this configuration include the following: Guidelines (a) through (d) are the same as those described in Use Case 3.1. Two additional guidelines are as follows: e. GRE tunnels are typically configured manually between peering points to support multicast delivery between domains. f. It is recommended that the GRE tunnel (tunnel server) configuration in the source network be such that it only advertises the routes to the application sources and not to the entire network. This practice will prevent unauthorized delivery
of applications through the tunnel (for example, if the application (e.g., content) is not part of an agreed-upon inter-domain partnership). Figure 3. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Multicast Enabled) \ / \ / \ | +----+ +---+ | I1 | +---+ | | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ | | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU | | | | +--+<........|........|........>+--+ |I2 +----+ \ +----+ / AMT \ / \ / Tunnel \ / \ / \ / ------------------- ------------------- AD = Administrative Domain (independent autonomous system) AS = multicast (e.g., content) Application Source AR = AMT Relay AG = AMT Gateway uBR = unicast Border Router - not multicast enabled; also, either AR = uBR (AD-1) or uBR = AG (AD-2) I1 = AMT interconnection between AD-1 and AD-2 I2 = AD-2 and EU multicast connection Figure 3: AMT Interconnection between AD-1 and AD-2 Advantages of this configuration: o Highly efficient use of bandwidth in AD-1. o AMT is an existing technology and is relatively simple to implement. Attractive properties of AMT include the following: * Dynamic interconnection between the gateway-relay pair across the peering point. * Ability to serve clients and servers with differing policies.
Disadvantages of this configuration: o Per Use Case 3.1 (AD-2 is native multicast), current router technology cannot count the number of EUs or the number of bytes transmitted to all EUs. o Additional devices (AMT gateway and relay pairs) may be introduced into the path if these services are not incorporated into the existing routing nodes. o Currently undefined mechanisms for the AG to automatically select the optimal AR. Architectural guidelines for this configuration are as follows: Guidelines (a) through (d) are the same as those described in Use Case 3.1. In addition, e. It is recommended that AMT relay and gateway pairs be configured at the peering points to support multicast delivery between domains. AMT tunnels will then configure dynamically across the peering points once the gateway in AD-2 receives the (S,G) information from the EU.
Figure 4. ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Not Multicast \ / \ / Enabled) \ N(large) | +----+ +---+ | | +---+ | # EUs | | | +--+ |uBR|-|--------|-|uBR| | +----+ | | AS |-->|AR| +---+-| | +---+ ................>|EU/G| | | | +--+<........|........|........... |I2 +----+ \ +----+ / N x AMT\ / \ / Tunnel \ / \ / \ / ------------------- ------------------- AS = multicast (e.g., content) Application Source uBR = unicast Border Router - not multicast enabled; otherwise, AR = uBR (in AD-1) AR = AMT Relay EU/G = Gateway client embedded in EU device I2 = AMT tunnel connecting EU/G to AR in AD-1 through non-multicast-enabled AD-2 Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway This use case is equivalent to having unicast distribution of the application through AD-2. The total number of AMT tunnels would be equal to the total number of EUs requesting the application. The peering point thus needs to accommodate the total number of AMT tunnels between the two domains. Each AMT tunnel can provide the data usage associated with each EU. Advantages of this configuration: o Efficient use of bandwidth in AD-1 (the closer the AR is to the uBR, the more efficient). o Ability of AD-1 to introduce content delivery based on IP multicast, without any support by network devices in AD-2: only the application side in the EU device needs to perform AMT gateway library functionality to receive traffic from the AMT relay. o Allows AD-2 to "upgrade" to Use Case 3.5 (see Section 3.5) at a later time, without any change in AD-1 at that time.
o AMT is an existing technology and is relatively simple to implement. Attractive properties of AMT include the following: * Dynamic interconnection between the AMT gateway-relay pair across the peering point. * Ability to serve clients and servers with differing policies. o Each AMT tunnel serves as a count for each EU and is also able to track data usage (bytes) delivered to the EU. Disadvantages of this configuration: o Additional devices (AMT gateway and relay pairs) are introduced into the transport path. o Assuming multiple peering points between the domains, the EU gateway needs to be able to find the "correct" AMT relay in AD-1. Architectural guidelines for this configuration are as follows: Guidelines (a) through (c) are the same as those described in Use Case 3.1. In addition, d. It is necessary that proper procedures be implemented such that the AMT gateway at the EU device is able to find the correct AMT relay for each (S,G) content stream. Standard mechanisms for that selection are still subject to ongoing work. This includes the use of anycast gateway addresses, anycast DNS names, or explicit configuration that maps (S,G) to a relay address; or letting the application in the EU/G provide the relay address to the embedded AMT gateway function. e. The AMT tunnel's capabilities are expected to be sufficient for the purpose of collecting relevant information on the multicast streams delivered to EUs in AD-2.
Figure 5 illustrates a variation of Use Case 3.4: ------------------- ------------------- / AD-1 \ / AD-2 \ / (Multicast Enabled) \ / (Not Multicast \ / +---+ \ (I1) / +---+ Enabled) \ | +----+ |uBR|-|--------|-|uBR| | | | | +--+ +---+ | | +---+ +---+ | +----+ | | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G| | | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+ \ +----+ / I1 \ |AR1| I2 +---+ / \ / Single \+---+ / \ / AMT Tunnel \ / ------------------- ------------------- uBR = unicast Border Router - not multicast enabled; also, either AR = uBR (AD-1) or uBR = AGAR1 (AD-2) AS = multicast (e.g., content) Application Source AR = AMT Relay in AD-1 AGAR1 = AMT Gateway/Relay node in AD-2 across peering point I1 = AMT tunnel connecting AR in AD-1 to gateway in AGAR1 in AD-2 AGAR2 = AMT Gateway/Relay node at AD-2 network edge I2 = AMT tunnel connecting relay in AGAR1 to gateway in AGAR2 EU/G = Gateway client embedded in EU device I3 = AMT tunnel connecting EU/G to AR in AGAR2 Figure 5: AMT Tunnel Connecting AMT Gateways and Relays Use Case 3.4 results in several long AMT tunnels crossing the entire network of AD-2 linking the EU device and the AMT relay in AD-1 through the peering point. Depending on the number of EUs, there is a likelihood of an unacceptably high amount of traffic due to the large number of AMT tunnels -- and unicast streams -- through the peering point. This situation can be alleviated as follows: o Provisioning of strategically located AMT nodes in AD-2. An AMT node comprises co-location of an AMT gateway and an AMT relay. No change is required by AD-1, as compared to Use Case 3.4. This can be done whenever AD-2 sees fit (e.g., too much traffic across the peering point). o One such node is on the AD-2 side of the peering point (AMT node AGAR1 in Figure 5).
o A single AMT tunnel established across the peering point linking the AMT relay in AD-1 to the AMT gateway in AMT node AGAR1 in AD-2. o AMT tunnels linking AMT node AGAR1 at the peering point in AD-2 to other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 linking the AMT relay in AGAR1 to the AMT gateway in AMT node AGAR2 (Figure 5). o AMT tunnels linking an EU device (via a gateway client embedded in the device) and an AMT relay in an appropriate AMT node at the edge of AD-2: e.g., I3 linking the EU gateway in the device to the AMT relay in AMT node AGAR2. o In the simplest option (not shown), AD-2 only deploys a single AGAR1 node and lets the EU/G build AMT tunnels directly to it. This setup already solves the problem of replicated traffic across the peering point. As soon as there is a need to support more AMT tunnels to the EU/G, then additional AGAR2 nodes can be deployed by AD-2. The advantage of such a chained set of AMT tunnels is that the total number of unicast streams across AD-2 is significantly reduced, thus freeing up bandwidth. Additionally, there will be a single unicast stream across the peering point instead of, possibly, an unacceptably large number of such streams per Use Case 3.4. However, this implies that several AMT tunnels will need to be dynamically configured by the various AMT gateways, based solely on the (S,G) information received from the application client at the EU device. A suitable mechanism for such dynamic configurations is therefore critical. Architectural guidelines for this configuration are as follows: Guidelines (a) through (c) are the same as those described in Use Case 3.1. In addition, d. It is necessary that proper procedures be implemented such that the various AMT gateways (at the EU devices and the AMT nodes in AD-2) are able to find the correct AMT relay in other AMT nodes as appropriate. Standard mechanisms for that selection are still subject to ongoing work. This includes the use of anycast gateway addresses, anycast DNS names, or explicit configuration that maps (S,G) to a relay address. On the EU/G, this mapping information may come from the application. e. The AMT tunnel's capabilities are expected to be sufficient for the purpose of collecting relevant information on the multicast streams delivered to EUs in AD-2.