Use of Multicast Across Inter-Domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-11
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 8313.
|
|
---|---|---|---|
Authors | Percy Tarapore , Robert Sayko , Greg Shepherd , Toerless Eckert , Ramki Krishnan | ||
Last updated | 2017-10-12 (Latest revision 2017-09-28) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
TSVART Telechat review
by Yoshifumi Nishida
Almost ready
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Tim Chown | ||
Shepherd write-up | Show Last changed 2017-07-19 | ||
IESG | IESG state | Became RFC 8313 (Best Current Practice) | |
Consensus boilerplate | Yes | ||
Telechat date |
(None)
Needs 9 more YES or NO OBJECTION positions to pass. |
||
Responsible AD | Warren "Ace" Kumari | ||
Send notices to | (None) | ||
IANA | IANA review state | IANA OK - No Actions Needed |
draft-ietf-mboned-interdomain-peering-bcp-11
monitoring tools; in which case, both AD's are expected to inform each other when multicast delivery problems are detected. o AD-2 may experience some problems in its network. For example, for the AMT Use Cases, one or more AMT Relays may be experiencing difficulties. AD-2 may be able to fix the problem by rerouting the multicast streams via alternate AMT Relays. If the fix is not successful and multicast service delivery degrades, then AD-2 needs to report the issue to AD-1. o When problem notification is received from a multicast application source, AD-1 determines whether the cause of the problem is within its own network or within the AD-2 domain. If the cause is within the AD-2 domain, then AD-1 supplies all necessary information to AD-2. Examples of supporting information include the following: o Kind of problem(s). o Starting point & duration of problem(s). o Conditions in which problem(s) occur. o IP address blocks of affected users. o ISPs of affected users. o Type of access e.g., mobile versus desktop. o Locations of affected EUs. o Both AD's conduct some form of root cause analysis for multicast service delivery problems. Examples of various factors for consideration include: o Verification that the service configuration matches the product features. o Correlation and consolidation of the various customer problems and resource troubles into a single root service problem. Tarapore, et al Expires March 28, 2018 [Page 24] IETF I-D Multicast Across Inter-Domain Peering Points September 2017 o Prioritization of currently open service problems, giving consideration to problem impact, service level agreement, etc. o Conduction of service tests, including one time tests or a series of tests over a period of time. o Analysis of test results. o Analysis of relevant network fault or performance data. o Analysis of the problem information provided by the customer (CP). o Once the cause of the problem has been determined and the problem has been fixed, both AD's need to work jointly to verify and validate the success of the fix. o Faults in service could lead to SLA violation for which the multicast application source provider may have to be compensated by AD-1. Subsequently, AD-1 may have to be compensated by AD-2 based on the contract. 4.5. Client Reliability Models/Service Assurance Guidelines There are multiple options for instituting reliability architectures, most are at the application level. Both AD's should work those out with their contract/agreement and with the multicast application source providers. Network reliability can also be enhanced by the two AD's by provisioning alternate delivery mechanisms via unicast means. 5. Troubleshooting and Diagnostics Any service provider supporting multicast delivery of content should have the capability to collect diagnostics as part of multicast troubleshooting practices and resolve network issues accordingly. Issues may become apparent or identified either through network 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 multicast creates a significant interdependence of proper networking functionality between providers Tarapore, et al Expires March 28, 2018 [Page 25] IETF I-D Multicast Across Inter-Domain Peering Points September 2017 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], [draft-MTraceroute] 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. o A default resolution period may be considered to resolve open issues. Alternately, mutually acceptable resolution periods could be established depending on the severity of the identified trouble. 6. Security Considerations From a security perspective, normal security procedures are expected to be followed by each AD to facilitate multicast delivery to registered and authenticated end users. Additionally: o Encryption - Peering point links may be encrypted per agreement for multicast delivery. o Security Breach Mitigation Plan - In the event of a security breach, the two AD's are expected to have a mitigation plan for shutting down the peering point and directing multicast traffic over alternative peering points. It is also expected that appropriate information will be shared for the purpose of securing the identified breach. DRM and Application Accounting, Authorization and Authentication should be the responsibility of the multicast application source Tarapore, et al Expires March 28, 2018 [Page 26] IETF I-D Multicast Across Inter-Domain Peering Points September 2017 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. 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. For example, [BCP38] style filtering could be deployed by both AD's to ensure that only legitimately sourced multicast content is exchanged between them. Authentication and authorization of EU to receive multicast content is done at the application layer between the client application and the source. This may involve some kind of token authentication and is done at the application layer independently of the two AD's. 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. Implementation details are beyond the scope of this document. 7. IANA Considerations No considerations identified in this document 8. Conclusions This Best Current Practice document provides detailed Use Case scenarios for the transmission of applications via multicast across peering points between two Administrative Domains. A detailed set of guidelines supporting the delivery is provided for all Use Cases. For Use Cases involving AMT tunnels (cases 3.4 and 3.5), it is recommended that proper procedures are implemented such that the various AMT Gateways (at the End User devices and the AMT nodes in AD-2) are able to find the correct AMT Relay in other AMT nodes as appropriate. Section 4.2 provides an overview of one method that finds the optimal Relay-Gateway combination via the use of an Anycast IP address for AMT Relays. Tarapore, et al Expires March 28, 2018 [Page 27] IETF I-D Multicast Across Inter-Domain Peering Points September 2017 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 [RFC3376] B. Cain, et al, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002 [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004 [RFC4760] T. Bates, et al, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007 [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 [RFC4609] P. Savola, et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, August 2006 [RFC7450] G. Bumgardner, "Automatic Multicast Tunneling", RFC 7450, February 2015 [RFC7761] B. Fenner, et al, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised), RFC 7761, March 2016 [BCP38] P. Ferguson, et al, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP: 38, May 2000 [BCP41] S. Floyd, "Congestion Control Principles", BCP 41, September 2000 Tarapore, et al Expires March 28, 2018 [Page 28] IETF I-D Multicast Across Inter-Domain Peering Points September 2017 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-MTraceroute] H. Asaeda, K, Meyer, and W. Lee, "Mtrace Version 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace- v2-16, October 2016, work in progress 10. Acknowledgments The authors would like to thank the following individuals for their suggestions, comments, and corrections: Mikael Abrahamsson Hitoshi Asaeda Dale Carder Tim Chown Leonard Giuliano Jake Holland Joel Jaeggli Albert Manfredi Stig Venaas Tarapore, et al Expires March 28, 2018 [Page 29] IETF I-D Multicast Across Inter-Domain Peering Points September 2017 Authors' Addresses Percy S. Tarapore AT&T Phone: 1-732-420-4172 Email: tarapore@att.com Robert Sayko AT&T Phone: 1-732-420-3292 Email: rs1983@att.com Greg Shepherd Cisco Phone: Email: shep@cisco.com Toerless Eckert Futurewei Technologies Inc. Phone: Email: tte@cs.fau.de Ram Krishnan SupportVectors Phone: Email: ramkri123@gmail.com Tarapore, et al Expires March 28, 2018 [Page 30]