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

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/