Skip to main content

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
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]