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