draft-ietf-mboned-interdomain-peering-bcp-00.txt   draft-ietf-mboned-interdomain-peering-bcp-01.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: January 20, 2016 Greg Shepherd Expires: July 20, 2016 Greg Shepherd
Toerless Eckert Toerless Eckert
Cisco Cisco
Ram Krishnan Ram Krishnan
Brocade Brocade
July 20, 2015 January 21, 2016
Use of Multicast Across Inter-Domain Peering Points 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 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 January 20, 2016. This Internet-Draft will expire on July 21, 2016.
Copyright Notice 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. 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
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without Section 4.e of the Trust Legal Provisions and are provided without
skipping to change at page 3, line 4 skipping to change at page 3, line 4
4.2.2 GRE Tunnel over Interconnecting Peering Point.....16 4.2.2 GRE Tunnel over Interconnecting Peering Point.....16
4.2.3 Routing Aspects with AMT Tunnels.....................16 4.2.3 Routing Aspects with AMT Tunnels.....................16
4.3. Back Office Functions - Billing and Logging Guidelines...19 4.3. Back Office Functions - Billing and Logging Guidelines...19
4.3.1 Provisioning Guidelines...........................19 4.3.1 Provisioning Guidelines...........................19
4.3.2 Application Accounting Billing Guidelines.........21 4.3.2 Application Accounting Billing Guidelines.........21
4.3.3 Log Management Guidelines.........................21 4.3.3 Log Management Guidelines.........................21
4.4. Operations - Service Performance and Monitoring Guidelines22 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...............................24
6. Security Considerations.......................................25 6. Security Considerations.......................................25
7. IANA Considerations...........................................25 7. IANA Considerations...........................................26
8. Conclusions...................................................26 8. Conclusions...................................................26
9. References....................................................26 9. References....................................................26
9.1. Normative References.....................................26 9.1. Normative References.....................................26
9.2. Informative References...................................26 9.2. Informative References...................................27
10. Acknowledgments..............................................27 10. Acknowledgments..............................................27
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
skipping to change at page 4, line 4 skipping to change at page 3, line 46
Discovery (MLD) [RFC4604], and Multicast Source Discovery Discovery (MLD) [RFC4604], and Multicast Source Discovery
Protocol (MSDP) [RFC3618]. This BCP is independent of the Protocol (MSDP) [RFC3618]. This BCP is independent of the
choice of multicast protocol; it focuses solely on the choice of multicast protocol; it focuses solely on the
implications for the inter-domain peering points. However, in implications for the inter-domain peering points. However, in
order to help explain use cases the figures will use the order to help explain use cases the figures will use the
general SSM flows and architectures. general SSM flows and architectures.
o Network Administrative Domains involved in setting up o Network Administrative Domains involved in setting up
multicast peering points are assumed to adopt compatible multicast peering points are assumed to adopt compatible
protocols. The use of different protocols is beyond the scope protocols. The use of different protocols is beyond the scope
of this document. of this document.
o It is assumed that an AMT Relay will be available to a client o It is assumed that an AMT Relay will be available to a client
for multicast delivery. The selection of an optimal AMT relay 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 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 7, line 15 skipping to change at page 7, line 15
b. If the peering point between AD-1 and AD-2 is a controlled network b. If the peering point between AD-1 and AD-2 is a controlled network
environment, then bandwidth can be allocated accordingly by the environment, then bandwidth can be allocated accordingly by the
two domains to permit the transit of non-rate adaptive multicast two domains to permit the transit of non-rate adaptive multicast
traffic. If this is not the case, then it is recommended that the traffic. If this is not the case, then it is recommended that the
multicast traffic should support rate-adaption. multicast traffic should support rate-adaption.
c. The sending and receiving of multicast traffic between two domains c. The sending and receiving of multicast traffic between two domains
is typically determined by local policies associated with each is typically determined by local policies associated with each
domain. For example, if AD-1 is a service provider and AD-2 is an 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 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 d. Relevant information on multicast streams delivered to End Users
in AD-2 is assumed to be collected by available capabilities in in AD-2 is assumed to be collected by available capabilities in
the application layer. The precise nature and formats of the the application layer. The precise nature and formats of the
collected information will be determined by directives from the collected information will be determined by directives from the
source owner and the domain operators. 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 3.2. Peering Point Enabled with GRE Tunnel
The peering point is not native multicast enabled in this Use Case. The peering point is not native multicast enabled in this Use Case.
There is a Generic Routing Encapsulation Tunnel provisioned over the There is a Generic Routing Encapsulation Tunnel provisioned over the
peering point. In this case, the interconnection I1 between AD-1 and peering point. In this case, the interconnection I1 between AD-1 and
AD-2 in Figure 1 is multicast enabled via a Generic Routing AD-2 in Figure 1 is multicast enabled via a Generic Routing
Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast
protocols across the interface. The routing configuration is protocols across the interface. The routing configuration is
basically unchanged: Instead of BGP (SAFI2) across the native IP basically unchanged: Instead of BGP (SAFI2) across the native IP
multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across
skipping to change at page 19, line 17 skipping to change at page 19, line 17
to that stream. to that stream.
o AMT Relay encapsulates the multicast stream into the tunnel o AMT Relay encapsulates the multicast stream into the tunnel
between the Relay and the Gateway, providing the requested content between the Relay and the Gateway, providing the requested content
to the EU. to the EU.
Note: Further routing discussion on optimal method to find "best AMT Note: Further routing discussion on optimal method to find "best AMT
Relay/GW combination" and information exchange between AD's to be Relay/GW combination" and information exchange between AD's to be
provided. 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: Back Office refers to the following:
o Servers and Content Management systems that support the delivery o Servers and Content Management systems that support the delivery
of applications via multicast and interactions between ADs. of applications via multicast and interactions between ADs.
o Functionality associated with logging, reporting, ordering, o Functionality associated with logging, reporting, ordering,
provisioning, maintenance, service assurance, settlement, etc. provisioning, maintenance, service assurance, settlement, etc.
4.3.1 Provisioning Guidelines 4.3.1 Provisioning Guidelines
skipping to change at page 21, line 5 skipping to change at page 21, line 5
o Automated interfaces are built between AD-1 and AD-2 such that o Automated interfaces are built between AD-1 and AD-2 such that
operations and customer care continue using their own systems. This operations and customer care continue using their own systems. This
requires coordination between the two AD's with appropriate requires coordination between the two AD's with appropriate
provisioning of necessary resources. provisioning of necessary resources.
o AD-1's operations and customer care personnel are provided access o AD-1's operations and customer care personnel are provided access
directly to AD-2's system. In this scenario, additional provisioning directly to AD-2's system. In this scenario, additional provisioning
in these systems will be needed to provide necessary access. in these systems will be needed to provide necessary access.
Additional provisioning must be agreed to by the two AD-2s to support Additional provisioning must be agreed to by the two AD-2s to support
this option. 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 All interactions between pairs of ADs can be discovered and/or be
associated with the account(s) utilized for delivered applications. associated with the account(s) utilized for delivered applications.
Supporting guidelines are as follows: Supporting guidelines are as follows:
o A unique identifier is recommended to designate each master o A unique identifier is recommended to designate each master
account. account.
o AD-2 is expected to set up "accounts" (logical facility generally o AD-2 is expected to set up "accounts" (logical facility generally
protected by login/password/credentials) for use by AD-1. Multiple protected by login/password/credentials) for use by AD-1. Multiple
accounts and multiple types/partitions of accounts can apply, e.g. accounts and multiple types/partitions of accounts can apply, e.g.
skipping to change at page 22, line 9 skipping to change at page 22, line 9
The two ADs may supply additional security logs to each other as The two ADs may supply additional security logs to each other as
agreed to by contract(s). Examples include the following: agreed to by contract(s). Examples include the following:
o Information related to general security-relevant activity which o Information related to general security-relevant activity which
may be of use from a protective or response perspective, such as may be of use from a protective or response perspective, such as
types and counts of attacks detected, related source information, types and counts of attacks detected, related source information,
related target information, etc. related target information, etc.
o Aggregated or summarized logs according to agreement (with o Aggregated or summarized logs according to agreement (with
additional detail potentially provided during security events, by additional detail potentially provided during security events, by
agreement) agreement)
o
4.4. Operations - Service Performance and Monitoring Guidelines 4.4. Operations - Service Performance and Monitoring Guidelines
Service Performance refers to monitoring metrics related to Service Performance refers to monitoring metrics related to
multicast delivery via probes. The focus is on the service provided multicast delivery via probes. The focus is on the service provided
by AD-2 to AD-1 on behalf of all multicast application sources by AD-2 to AD-1 on behalf of all multicast application sources
(metrics may be specified for SLA use or otherwise). Associated (metrics may be specified for SLA use or otherwise). Associated
guidelines are as follows: guidelines are as follows:
o Both AD's are expected to monitor, collect, and analyze service o Both AD's are expected to monitor, collect, and analyze service
skipping to change at page 25, line 5 skipping to change at page 25, line 5
monitoring functions or by customer reported problems as described monitoring functions or by customer reported problems as described
in section 4.4. in section 4.4.
It is expected that multicast diagnostics will be collected It is expected that multicast diagnostics will be collected
according to currently established practices [MDH-04]. However, according to currently established practices [MDH-04]. However,
given that inter-domain creates a significant interdependence of given that inter-domain creates a significant interdependence of
proper networking functionality between providers there does exist a proper networking functionality between providers there does exist a
need for providers to be able to signal/alert each other if there need for providers to be able to signal/alert each other if there
are any issues noted by either one. 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 The specifics of the notification and alerts are beyond the scope of
this document, but general guidelines are similar to those described this document, but general guidelines are similar to those described
in section 4.4 (Service Performance and Monitoring). Some general in section 4.4 (Service Performance and Monitoring). Some general
communications issues are stated as follows. communications issues are stated as follows.
o Appropriate communications channels will be established between o Appropriate communications channels will be established between
the customer service and operations groups from both AD's to the customer service and operations groups from both AD's to
facilitate information sharing related to diagnostic facilitate information sharing related to diagnostic
troubleshooting. troubleshooting.
skipping to change at page 25, line 30 skipping to change at page 25, line 38
6. Security Considerations 6. Security Considerations
DRM and Application Accounting, Authorization and Authentication DRM and Application Accounting, Authorization and Authentication
should be the responsibility of the multicast application source should be the responsibility of the multicast application source
provider and/or AD-1. AD-1 needs to work out the appropriate provider and/or AD-1. AD-1 needs to work out the appropriate
agreements with the source provider. agreements with the source provider.
Network has no DRM responsibilities, but might have authentication Network has no DRM responsibilities, but might have authentication
and authorization obligations. These though are consistent with and authorization obligations. These though are consistent with
normal operations of a CDN to insure end user reliability, security 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 AD-1 and AD-2 should have mechanisms in place to ensure proper
accounting for the volume of bytes delivered through the peering 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 If there are problems related to failure of token authentication
when end-users are supported by AD-2, then some means of validating when end-users are supported by AD-2, then some means of validating
proper working of the token authentication process (e.g., back-end proper working of the token authentication process (e.g., back-end
servers querying the multicast application source provider's token servers querying the multicast application source provider's token
authentication server are communicating properly) should be authentication server are communicating properly) should be
considered. Details will have to be worked out during implementation considered. Details will have to be worked out during implementation
(e.g., test tokens or trace token exchange process). (e.g., test tokens or trace token exchange process).
7. IANA Considerations 7. IANA Considerations
skipping to change at page 26, line 40 skipping to change at page 27, line 5
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", [RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol",
RFC 3618, October 2003 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 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
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
AT&T AT&T
 End of changes. 19 change blocks. 
15 lines changed or deleted 40 lines changed or added

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