draft-tarapore-mboned-multicast-cdni-06.txt   draft-tarapore-mboned-multicast-cdni-07.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 4, 2015 Greg Shepherd Expires: April 27, 2015 Greg Shepherd
Toerless Eckert Toerless Eckert
Cisco Cisco
Ram Krishnan Ram Krishnan
Brocade Brocade
July 4, 2014 October 27, 2014
Multicasting Applications Across Inter-Domain Peering Points Multicasting Applications Across Inter-Domain Peering Points
draft-tarapore-mboned-multicast-cdni-06.txt draft-tarapore-mboned-multicast-cdni-07.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 4, 2015. This Internet-Draft will expire on April 27, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
warranty as described in the Simplified BSD License. warranty as described in the Simplified BSD License.
IETF I-D Multicasting Applications Across Peering Points February 2014
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
skipping to change at page 2, line 52 skipping to change at page 2, line 50
4.2. Routing Aspects and Related Guidelines...................15 4.2. Routing Aspects and Related Guidelines...................15
4.2.1 Native Multicast Routing Aspects..................15 4.2.1 Native Multicast Routing Aspects..................15
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.........20 4.3.2 Application Accounting Billing Guidelines.........20
4.3.3 Log Management Guidelines.........................21 4.3.3 Log Management Guidelines.........................21
4.3.4 Settlement Guidelines.............................21 4.3.4 Settlement Guidelines.............................21
4.4. Operations - Service Performance and Monitoring Guidelines22 4.4. Operations - Service Performance and Monitoring Guidelines22
4.5. Reliability Models/Service Assurance Guidelines..........22 4.5. Client Reliability Models/Service Assurance Guidelines...24
IETF I-D Multicasting Applications Across Peering Points February 2014
4.6. Provisioning Guidelines..................................22 5. Security Considerations.......................................25
4.7. Client Models............................................23 6. IANA Considerations...........................................25
4.8. Addressing Guidelines....................................23 7. Conclusions...................................................25
5. Security Considerations.......................................23 8. References....................................................26
6. IANA Considerations...........................................23 8.1. Normative References.....................................26
7. Conclusions...................................................23 8.2. Informative References...................................26
8. References....................................................23 9. Acknowledgments...............................................26
8.1. Normative References.....................................23
8.2. Informative References...................................24
9. Acknowledgments...............................................24
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.
The objective of this Best Current Practices document is twofold: The objective of this Best Current Practices document is twofold:
o Describe the process and establish guidelines for setting up o Describe the process and establish guidelines for setting up
multicast-based delivery of applications across inter-domain multicast-based delivery of applications across inter-domain
peering points, and peering points, and
o Catalog all required information exchange between the o Catalog all required information exchange between the
administrative domains to support multicast-based delivery. administrative domains to support multicast-based delivery.
While there are several multicast protocols available for use, this While there are sSeveral multicast protocols are available for use,
BCP will focus the discussion to those that are applicable and this BCP will focus the discussion to those that are applicable and
recommended for the peering requirements of today's service model, recommended for the peering requirements of today's service model,
including: including:
o Protocol Independent Multicast - Source Specific Multicast o Protocol Independent Multicast - Source Specific Multicast
(PIM-SSM) [RFC4607] (PIM-SSM) [RFC4607]
o Internet Group Management Protocol (IGMP) v3 [RFC4604] o Internet Group Management Protocol (IGMP) v3 [RFC4604]
o Multicast Listener Discovery (MLD) [RFC4604] o Multicast Listener Discovery (MLD) [RFC4604]
This BCP is independent of the choice of multicast protocol; it
focuses solely on the implications for the inter-domain peering
points.
This document therefore serves the purpose of a "Gap Analysis" This document therefore serves the purpose of a "Gap Analysis"
exercise for this process. The rectification of any gaps identified exercise for this process. The rectification of any gaps identified
- whether they involve protocol extension development or otherwise - - whether they involve protocol extension development or otherwise -
is beyond the scope of this document and is for further study. is beyond the scope of this document and is for further study.
IETF I-D Multicasting Applications Across Peering Points February 2014
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
skipping to change at page 5, line 5 skipping to change at page 5, line 5
information that the application client can use to locate the information that the application client can use to locate the
source and join the stream. source and join the stream.
It should be noted that the second administrative domain - domain 2 It should be noted that the second administrative domain - domain 2
- may be an independent network domain (e.g., Tier 1 network - may be an independent network domain (e.g., Tier 1 network
operator domain) or it could also be an Enterprise network operated operator domain) or it could also be an Enterprise network operated
by a single customer. The peering point architecture and by a single customer. The peering point architecture and
requirements may have some unique aspects associated with the requirements may have some unique aspects associated with the
Enterprise case. Enterprise case.
IETF I-D Multicasting Applications Across Peering Points February 2014
The Use Cases describing various architectural configurations for The Use Cases describing various architectural configurations for
the multicast distribution along with associated requirements is the multicast distribution along with associated requirements is
described in section 3. Unique aspects related to the Enterprise described in section 3. Unique aspects related to the Enterprise
network possibility will be described in this section. A network possibility will be described in this section. A
comprehensive list of pertinent information that needs to be comprehensive list of pertinent information that needs to be
exchanged between the two domains to support various functions exchanged between the two domains to support various functions
enabling the application transport is provided in section 4. enabling the application transport is provided in section 4.
3. Inter-domain Peering Point Requirements for Multicast 3. Inter-domain Peering Point Requirements for Multicast
skipping to change at page 6, line 5 skipping to change at page 6, line 5
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 (MBGP or BGMP) I1 = AD-1 and AD-2 Multicast Interconnection (MBGP or BGMP)
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:
IETF I-D Multicasting Applications Across Peering Points February 2014
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 o Fewer devices in the path traversed by the multicast stream
when compared to unicast transmissions. when compared to unicast transmissions.
From the perspective of AD-1, the one disadvantage associated with From the perspective of AD-1, the one disadvantage associated with
native multicast into AD-2 instead of individual unicast to every EU native multicast into AD-2 instead of individual unicast to every EU
in AD-2 is that it does not have the ability to count the number of in AD-2 is that it does not have the ability to count the number of
End Users as well as the transmitted bytes delivered to them. This End Users as well as the transmitted bytes delivered to them. This
information is relevant from the perspective of customer billing and information is relevant from the perspective of customer billing and
skipping to change at page 7, line 5 skipping to change at page 7, line 5
with each domain. For example, if AD-1 is a service provider with each domain. For example, if AD-1 is a service provider
and AD-2 is an enterprise, then AD-1 may support local policies and AD-2 is an enterprise, then AD-1 may support local policies
for traffic delivery to, but not traffic reception from AD-2. for traffic delivery to, but not traffic reception from AD-2.
o Relevant information on multicast streams delivered to End o Relevant information on multicast streams delivered to End
Users in AD-2 is assumed to be collected by available Users in AD-2 is assumed to be collected by available
capabilities in the application layer. The precise nature and capabilities in the application layer. The precise nature and
formats of the collected information will be determined by formats of the collected information will be determined by
directives from the source owner and the domain operators. directives from the source owner and the domain operators.
IETF I-D Multicasting Applications Across Peering Points February 2014
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 8, line 5 skipping to change at page 8, line 5
Architectural guidelines for this configuration include the Architectural guidelines for this configuration include the
following: following:
Guidelines (a) through (d) are the same as those described in Use Guidelines (a) through (d) are the same as those described in Use
Case 3.1. Case 3.1.
o GRE tunnels are typically configured manually between peering o GRE tunnels are typically configured manually between peering
points to support multicast delivery between domains. points to support multicast delivery between domains.
IETF I-D Multicasting Applications Across Peering Points February 2014
o It is recommended that the GRE tunnel (tunnel server) o It is recommended that the GRE tunnel (tunnel server)
configuration in the source network is such that it only configuration in the source network is such that it only
advertises the routes to the application sources and not to the advertises the routes to the application sources and not to the
entire network. This practice will prevent unauthorized entire network. This practice will prevent unauthorized
delivery of applications through the tunnel (e.g., if delivery of applications through the tunnel (e.g., if
application - e.g., content - is not part of an agreed inter- application - e.g., content - is not part of an agreed inter-
domain partnership). domain partnership).
3.3. Peering Point Enabled with an AMT - Both Domains Multicast 3.3. Peering Point Enabled with an AMT - Both Domains Multicast
Enabled Enabled
skipping to change at page 9, line 5 skipping to change at page 9, line 5
AG = AMT Gateway AG = AMT Gateway
I1 = AMT Interconnection between AD-1 and AD-2 I1 = AMT Interconnection between AD-1 and AD-2
I2 = AD-2 and EU Multicast Connection I2 = AD-2 and EU Multicast Connection
Figure 2 - AMT Interconnection between AD-1 and AD-2 Figure 2 - AMT Interconnection between AD-1 and AD-2
Advantages of this configuration: Advantages of this configuration:
o Highly efficient use of bandwidth in AD-1. o Highly efficient use of bandwidth in AD-1.
IETF I-D Multicasting Applications Across Peering Points February 2014
o AMT is an existing technology and is relatively simple to o AMT is an existing technology and is relatively simple to
implement. Attractive properties of AMT include the following: implement. Attractive properties of AMT include the following:
o Dynamic interconnection between Gateway-Relay pair across o Dynamic interconnection between Gateway-Relay pair across
the peering point. the peering point.
o Ability to serve clients and servers with differing o Ability to serve clients and servers with differing
policies. policies.
Disadvantages of this configuration: Disadvantages of this configuration:
skipping to change at page 10, line 5 skipping to change at page 10, line 5
across the peering points once the Gateway in AD-2 receives the across the peering points once the Gateway in AD-2 receives the
(S, G) information from the EU. (S, G) information from the EU.
3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled
In this AMT Use Case, the second administrative domain AD-2 is not In this AMT Use Case, the second administrative domain AD-2 is not
multicast enabled. This implies that the interconnection between AD- multicast enabled. This implies that the interconnection between AD-
2 and the End User is also not multicast enabled as depicted in 2 and the End User is also not multicast enabled as depicted in
Figure 3. Figure 3.
IETF I-D Multicasting Applications Across Peering Points February 2014
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Non-Multicast \ / (Multicast Enabled) \ / (Non-Multicast \
/ \ / Enabled) \ / \ / Enabled) \
| +----+ | | | | +----+ | | |
| | | +------+ | | | +----+ | | | +------+ | | | +----+
| | AS |------>| AR |-|---------|-----------------------|-->|EU/G| | | AS |------>| AR |-|---------|-----------------------|-->|EU/G|
| | | +------+ | | |I2 +----+ | | | +------+ | | |I2 +----+
\ +----+ / \ / \ +----+ / \ /
\ / \ / \ / \ /
skipping to change at page 11, line 5 skipping to change at page 11, line 5
o Dynamic interconnection between Gateway-Relay pair across o Dynamic interconnection between Gateway-Relay pair across
the peering point. the peering point.
o Ability to serve clients and servers with differing o Ability to serve clients and servers with differing
policies. policies.
o Each AMT tunnel serves as a count for each End User and is also o Each AMT tunnel serves as a count for each End User and is also
able to track data usage (bytes) delivered to the EU. able to track data usage (bytes) delivered to the EU.
IETF I-D Multicasting Applications Across Peering Points February 2014
Disadvantages of this configuration: Disadvantages of this configuration:
o Additional devices (AMT Gateway and Relay pairs) are introduced o Additional devices (AMT Gateway and Relay pairs) are introduced
into the transport path. into the transport path.
o Assuming multiple peering points between the domains, the EU o Assuming multiple peering points between the domains, the EU
Gateway needs to be able to find the "correct" AMT Relay in AD- Gateway needs to be able to find the "correct" AMT Relay in AD-
1. 1.
Architectural guidelines for this configuration are as follows: Architectural guidelines for this configuration are as follows:
skipping to change at page 12, line 5 skipping to change at page 12, line 5
G) information to the Gateway for this purpose. G) information to the Gateway for this purpose.
e. The AMT tunnel capabilities are expected to be sufficient for e. The AMT tunnel capabilities are expected to be sufficient for
the purpose of collecting relevant information on the multicast the purpose of collecting relevant information on the multicast
streams delivered to End Users in AD-2. streams delivered to End Users in AD-2.
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2
This is a variation of Use Case 3.4 as follows: This is a variation of Use Case 3.4 as follows:
IETF I-D Multicasting Applications Across Peering Points February 2014
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Non-Multicast \ / (Multicast Enabled) \ / (Non-Multicast \
/ \ / Enabled) \ / \ / Enabled) \
| +----+ | |+--+ +--+ | | +----+ | |+--+ +--+ |
| | | +------+ | ||AG| |AG| | +----+ | | | +------+ | ||AG| |AG| | +----+
| | AS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| | | AS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G|
| | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ | | | +------+ | I1 ||1 | I2 |2 | |I3 +----+
\ +----+ / \+--+ +--+ / \ +----+ / \+--+ +--+ /
\ / \ / \ / \ /
skipping to change at page 13, line 4 skipping to change at page 13, line 4
o Provisioning of strategically located AMT nodes at the edges of o Provisioning of strategically located AMT nodes at the edges of
AD-2. An AMT node comprises co-location of an AMT Gateway and AD-2. An AMT node comprises co-location of an AMT Gateway and
an AMT Relay. One such node is at the AD-2 side of the peering an AMT Relay. One such node is at the AD-2 side of the peering
point (node AGAR1 in Figure 4). point (node AGAR1 in Figure 4).
o Single AMT tunnel established across peering point linking AMT o Single AMT tunnel established across peering point linking AMT
Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2.
o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to
other AMT nodes located at the edges of AD-2: e.g., AMT tunnel other AMT nodes located at the edges of AD-2: e.g., AMT tunnel
IETF I-D Multicasting Applications Across Peering Points February 2014
I2 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 I2 linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2
in Figure 4. in Figure 4.
o AMT tunnels linking EU device (via Gateway client embedded in o AMT tunnels linking EU device (via Gateway client embedded in
device) and AMT Relay in appropriate AMT node at edge of AD-2: device) and AMT Relay in appropriate AMT node at edge of AD-2:
e.g., I3 linking EU Gateway in device to AMT Relay in AMT node e.g., I3 linking EU Gateway in device to AMT Relay in AMT node
AGAR2. AGAR2.
The advantage for such a chained set of AMT tunnels is that the The advantage for such a chained set of AMT tunnels is that the
total number of unicast streams across AD-2 is significantly reduced total number of unicast streams across AD-2 is significantly reduced
skipping to change at page 14, line 5 skipping to change at page 14, line 5
4. Supporting Functionality 4. Supporting Functionality
Supporting functions and related interfaces over the peering point Supporting functions and related interfaces over the peering point
that enable the multicast transport of the application are listed in that enable the multicast transport of the application are listed in
this section. Critical information parameters that need to be this section. Critical information parameters that need to be
exchanged in support of these functions are enumerated along with exchanged in support of these functions are enumerated along with
guidelines as appropriate. Specific interface functions for guidelines as appropriate. Specific interface functions for
consideration are as follows. consideration are as follows.
IETF I-D Multicasting Applications Across Peering Points February 2014
4.1. Network Interconnection Transport and Security Guidelines 4.1. Network Interconnection Transport and Security Guidelines
The term "Network Interconnection Transport" refers to the The term "Network Interconnection Transport" refers to the
interconnection points between the two Administrative Domains. The interconnection points between the two Administrative Domains. The
following is a representative set of attributes that will need to be following is a representative set of attributes that will need to be
agreed to between the two administrative domains to support agreed to between the two administrative domains to support
multicast delivery. multicast delivery.
o Number of Peering Points o Number of Peering Points
skipping to change at page 15, line 4 skipping to change at page 15, line 4
security procedures will be followed by each AD to facilitate security procedures will be followed by each AD to facilitate
multicast delivery to registered and authenticated end users. Some multicast delivery to registered and authenticated end users. Some
security aspects for consideration are: security aspects for consideration are:
o Encryption - Peering point links may be encrypted per agreement o Encryption - Peering point links may be encrypted per agreement
if dedicated for multicast delivery. if dedicated for multicast delivery.
o Security Breach Mitigation Plan - In the event of a security o Security Breach Mitigation Plan - In the event of a security
breach, the two AD's are expected to have a mitigation plan for breach, the two AD's are expected to have a mitigation plan for
shutting down the peering point and directing multicast traffic shutting down the peering point and directing multicast traffic
IETF I-D Multicasting Applications Across Peering Points February 2014
over alternated peering points. It is also expected that over alternated peering points. It is also expected that
appropriate information will be shared for the purpose of appropriate information will be shared for the purpose of
securing the identified breach. securing the identified breach.
4.2. Routing Aspects and Related Guidelines 4.2. Routing Aspects and Related Guidelines
The main objective for multicast delivery routing is to ensure that The main objective for multicast delivery routing is to ensure that
the End User receives the multicast stream from the "most optimal" the End User receives the multicast stream from the "most optimal"
source [INF_ATIS_10] which typically: source [INF_ATIS_10] which typically:
skipping to change at page 16, line 4 skipping to change at page 16, line 4
coordinate and advertise the correct source address(es) at their coordinate and advertise the correct source address(es) at their
network interconnection peering points(i.e., border routers). An network interconnection peering points(i.e., border routers). An
example of multicast delivery via a Native Multicast process across example of multicast delivery via a Native Multicast process across
two administrative Domains is as follows assuming that the two administrative Domains is as follows assuming that the
interconnecting peering points are also multicast enabled: interconnecting peering points are also multicast enabled:
o Appropriate information is obtained by the EU client who is a o Appropriate information is obtained by the EU client who is a
subscriber to AD-2 (see Use Case 3.1). This is usually done via subscriber to AD-2 (see Use Case 3.1). This is usually done via
an appropriate file transfer - this file is typically known as an appropriate file transfer - this file is typically known as
the manifest file. It contains instructions directing the EU the manifest file. It contains instructions directing the EU
IETF I-D Multicasting Applications Across Peering Points February 2014
client to launch an appropriate application if necessary, and client to launch an appropriate application if necessary, and
also additional information for the application about the source also additional information for the application about the source
location and the group (or stream) id in the form of the "S,G" location and the group (or stream) id in the form of the "S,G"
data. The "S" portion provides the name or IP address of the data. The "S" portion provides the name or IP address of the
source of the multicast stream. The file may also contain source of the multicast stream. The file may also contain
alternate delivery information such as specifying the unicast alternate delivery information such as specifying the unicast
address of the stream. address of the stream.
o The client uses the join message with S,G to join the multicast o The client uses the join message with S,G to join the multicast
stream [RFC2236]. stream [RFC2236].
skipping to change at page 17, line 5 skipping to change at page 17, line 5
more complex. It presents a dual layered problem because there are more complex. It presents a dual layered problem because there are
two criteria that should be simultaneously meet: two criteria that should be simultaneously meet:
o Find the closest AMT relay to the end-user that also has o Find the closest AMT relay to the end-user that also has
multicast connectivity to the content source and multicast connectivity to the content source and
o Minimize the AMT unicast tunnel distance. o Minimize the AMT unicast tunnel distance.
There are essentially two components to the AMT specification: There are essentially two components to the AMT specification:
IETF I-D Multicasting Applications Across Peering Points February 2014
o AMT Relays: These serve the purpose of tunneling UDP multicast o AMT Relays: These serve the purpose of tunneling UDP multicast
traffic to the receivers (i.e., End Points). The AMT Relay will traffic to the receivers (i.e., End Points). The AMT Relay will
receive the traffic natively from the multicast media source and receive the traffic natively from the multicast media source and
will replicate the stream on behalf of the downstream AMT will replicate the stream on behalf of the downstream AMT
Gateways, encapsulating the multicast packets into unicast Gateways, encapsulating the multicast packets into unicast
packets and sending them over the tunnel toward the AMT Gateway. packets and sending them over the tunnel toward the AMT Gateway.
In addition, the AMT Relay may perform various usage and In addition, the AMT Relay may perform various usage and
activity statistics collection. This results in moving the activity statistics collection. This results in moving the
replication point closer to the end user, and cuts down on replication point closer to the end user, and cuts down on
traffic across the network. Thus, the linear costs of adding traffic across the network. Thus, the linear costs of adding
skipping to change at page 18, line 4 skipping to change at page 18, line 4
Using an Anycast IP address for AMT Relays allows for all AMT Using an Anycast IP address for AMT Relays allows for all AMT
Gateways to find the "closest" AMT Relay - the nearest edge of the Gateways to find the "closest" AMT Relay - the nearest edge of the
multicast topology of the source. An example of a basic delivery multicast topology of the source. An example of a basic delivery
via an AMT Multicast process for these two Use Cases is as follows: via an AMT Multicast process for these two Use Cases is as follows:
o The manifest file is obtained by the EU client application. This o The manifest file is obtained by the EU client application. This
file contains instructions directing the EU client to an ordered file contains instructions directing the EU client to an ordered
list of particular destinations to seek the requested stream and, list of particular destinations to seek the requested stream and,
for multicast, specifies the source location and the group (or for multicast, specifies the source location and the group (or
stream) ID in the form of the "S,G" data. The "S" portion provides stream) ID in the form of the "S,G" data. The "S" portion provides
IETF I-D Multicasting Applications Across Peering Points February 2014
the URI (name or IP address) of the source of the multicast stream the URI (name or IP address) of the source of the multicast stream
and the "G" identifies the particular stream originated by that and the "G" identifies the particular stream originated by that
source. The manifest file may also contain alternate delivery source. The manifest file may also contain alternate delivery
information such as the address of the unicast form of the content information such as the address of the unicast form of the content
to be used, for example, if the multicast stream becomes to be used, for example, if the multicast stream becomes
unavailable. unavailable.
o Using the information in the manifest file, and possibly o Using the information in the manifest file, and possibly
information provisioned directly in the EU client, a DNS query is information provisioned directly in the EU client, a DNS query is
initiated in order to connect the EU client/AMT Gateway to an AMT initiated in order to connect the EU client/AMT Gateway to an AMT
skipping to change at page 19, line 5 skipping to change at page 19, line 5
protocol messages). protocol messages).
o AMT Relay receives the "S,G" information and uses the S,G to join o AMT Relay receives the "S,G" information and uses the S,G to join
the appropriate multicast stream, if it has not already subscribed the appropriate multicast stream, if it has not already subscribed
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.
IETF I-D Multicasting Applications Across Peering Points February 2014
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 - Billing 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.
skipping to change at page 19, line 28 skipping to change at page 19, line 26
provisioning, maintenance, service assurance, settlement, etc. provisioning, maintenance, service assurance, settlement, etc.
4.3.1 Provisioning Guidelines 4.3.1 Provisioning Guidelines
Resources for basic connectivity between ADs Providers need to be Resources for basic connectivity between ADs Providers need to be
provisioned as follows: provisioned as follows:
o Sufficient capacity must be provisioned to support multicast-based o Sufficient capacity must be provisioned to support multicast-based
delivery across ADs. delivery across ADs.
o Sufficient capacity must be provisioned for connectivity between o Sufficient capacity must be provisioned for connectivity between
all supporting back-offices of the Ads as appropriate. This all supporting back-offices of the ADs as appropriate. This
includes activating proper security treatment for these back- includes activating proper security treatment for these back-
office connections (gateways, firewalls, etc) as appropriate. office connections (gateways, firewalls, etc) as appropriate.
o Routing protocols as needed, e.g. configuring routers to support o Routing protocols as needed, e.g. configuring routers to support
these. these.
Provisioning aspects related to Multicast-Based inter-domain Provisioning aspects related to Multicast-Based inter-domain
delivery are as follows. delivery are as follows.
The ability to receive requested application via multicast is The ability to receive requested application via multicast is
triggered via the manifest file. Hence, this file must be provided triggered via the manifest file. Hence, this file must be provided
skipping to change at page 20, line 5 skipping to change at page 20, line 5
provide the file to the EU. provide the file to the EU.
Native multicast functionality is assumed to be available in across Native multicast functionality is assumed to be available in across
many ISP backbones, peering and access networks. If however, native many ISP backbones, peering and access networks. If however, native
multicast is not an option (Use Cases 3.4 and 3.5), then: multicast is not an option (Use Cases 3.4 and 3.5), then:
o EU must have multicast client to use AMT multicast obtained either o EU must have multicast client to use AMT multicast obtained either
from Application Source (per agreement with AD-1) or from AD-1 or from Application Source (per agreement with AD-1) or from AD-1 or
AD-2 (if delegated by the Application Source). AD-2 (if delegated by the Application Source).
IETF I-D Multicasting Applications Across Peering Points February 2014
o If provided by AD-1/AD-2, then the EU could be redirected to a o If provided by AD-1/AD-2, then the EU could be redirected to a
client download site (note: this could be an Application Source client download site (note: this could be an Application Source
site). If provided by the Application Source, then this Source site). If provided by the Application Source, then this Source
would have to coordinate with AD-1 to ensure the proper client is would have to coordinate with AD-1 to ensure the proper client is
provided (assuming multiple possible clients). provided (assuming multiple possible clients).
o Where AMT Gateways support different application sets, all AD-2 o Where AMT Gateways support different application sets, all AD-2
AMT Relays need to be provisioned with all source & group AMT Relays need to be provisioned with all source & group
addresses for streams it is allowed to join. addresses for streams it is allowed to join.
o DNS across each AD, must be provisioned to enable a client GW to o DNS across each AD must be provisioned to enable a client GW to
locate the optimal AMT Relay (i.e. longest multicast path and locate the optimal AMT Relay (i.e. longest multicast path and
shortest unicast tunnel) with connectivity to the content's shortest unicast tunnel) with connectivity to the content's
multicast source. multicast source.
Provisioning Aspects Related to Operations and Customer Care are Provisioning Aspects Related to Operations and Customer Care are
stated as follows. stated as follows.
Each AD provider is assumed to provision operations and customer Each AD provider is assumed to provision operations and customer
care access to their own systems. care access to their own systems.
skipping to change at page 20, line 43 skipping to change at page 20, line 41
This requires coordination between the two AD's with appropriate This 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 directly to AD-2's system. In this scenario, additional
provisioning in these systems will be needed to provide necessary provisioning in these systems will be needed to provide necessary
access. Additional provisioning must be agreed to by the two AD-2s access. Additional provisioning must be agreed to by the two AD-2s
to support this option. to support this option.
4.3.2 Application Accounting Billing Guidelines 4.3.2 Application Accounting Billing 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
IETF I-D Multicasting Applications Across Peering Points February 2014
accounts and multiple types/partitions of accounts can apply, e.g. accounts and multiple types/partitions of accounts can apply, e.g.
customer accounts, security accounts, etc. customer accounts, security accounts, etc.
4.3.3 Log Management Guidelines 4.3.3 Log Management Guidelines
Successful delivery of applications via multicast between pairs of Successful delivery of applications via multicast between pairs of
interconnecting ADs requires that appropriate logs will be exchanged interconnecting ADs requires that appropriate logs will be exchanged
between them in support. Associated guidelines are as follows. between them in support. Associated guidelines are as follows.
AD-2 needs to supply logs to AD-1 per existing contract(s). Examples AD-2 needs to supply logs to AD-1 per existing contract(s). Examples
skipping to change at page 22, line 4 skipping to change at page 22, line 4
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)
4.3.4 Settlement Guidelines 4.3.4 Settlement Guidelines
Settlements between the ADs relate to (1) billing and reimbursement Settlements between the ADs relate to (1) billing and reimbursement
aspects for delivery of applications, and (2) aggregation, aspects for delivery of applications, and (2) aggregation,
transport, and collection of data in preparation for the billing and transport, and collection of data in preparation for the billing and
IETF I-D Multicasting Applications Across Peering Points February 2014
reimbursement aspects for delivery of applications for the reimbursement aspects for delivery of applications for the
Application Provider. At a high level: Application Provider. At a high level:
o AD-2 collects "usage" data for AD-1 related to application o AD-2 collects "usage" data for AD-1 related to application
delivery to End Users, and submits invoices to AD-1 based on this delivery to End Users, and submits invoices to AD-1 based on this
usage data. The data may include information related to the type usage data. The data may include information related to the type
of content delivered, total bandwidth utilized, storage utilized, of content delivered, total bandwidth utilized, storage utilized,
features supported, etc. features supported, etc.
o AD-1 collects all available data from partner AD-2 and creates o AD-1 collects all available data from partner AD-2 and creates
aggregate reports pertaining to responsible Application Providers, aggregate reports pertaining to responsible Application Providers,
skipping to change at page 22, line 32 skipping to change at page 22, line 29
o AD-2 may convey prices/rates to AD-1, proactively or in response o AD-2 may convey prices/rates to AD-1, proactively or in response
to a query, especially in cases where these may change. to a query, especially in cases where these may change.
o Usage data may be collected per end user or on an aggregated o Usage data may be collected per end user or on an aggregated
basis; the method of collection will depend on the application basis; the method of collection will depend on the application
delivered and/or the agreements with the source provider. In all delivered and/or the agreements with the source provider. In all
cases, usage volume is expected to be in terms of delivered packet cases, usage volume is expected to be in terms of delivered packet
bits or bytes. bits or bytes.
4.4. Operations - Service Performance and Monitoring Guidelines 4.4. Operations - Service Performance and Monitoring Guidelines
4.5. Reliability Models/Service Assurance Guidelines Service Performance refers to monitoring metrics related to
multicast delivery via probes. The focus is on the service provided
by AD-2 to AD-1 on behalf of all multicast application sources
(metrics may be specified for SLA use or otherwise). Associated
guidelines are as follows:
4.6. Provisioning Guidelines o Both AD's are expected to monitor, collect, and analyze service
performance metrics for multicast applications. AD-2 provides
relevant performance information to AD-1; this enables AD-1 to
create an end-to-end performance view on behalf of the
multicast application source.
In order to find right relay there is a need for a small/light o Both AD's are expected to agree on the type of probes to be
implementation of an AMT DNS in source network. used to monitor multicast delivery performance. For example,
AD-2 may permit AD-1's probes to be utilized in the AD-2
multicast service footprint. Alternately, AD-2 may deploy its
own probes and relay performance information back to AD-1.
IETF I-D Multicasting Applications Across Peering Points February 2014 o In the event of performance degradation (SLA violation), AD-1
may have to compensate the multicast application source per SLA
agreement. As appropriate, AD-1 may seek compensation from AD-2
if the cause of the degradation is in AD-2's network.
4.7. Client Models Service Monitoring generally refers to a service (as a whole)
provided on behalf of a particular multicast application source
provider. It thus involves complaints from End Users when service
problems occur. EU's direct their complaints to the source provider;
in turn the source provider submits these complaints to AD-1. The
responsibility for service delivery lies with AD-1; as such AD-1
will need to determine where the service problem is occurring - its
own network or in AD-2. It is expected that each AD will have tools
to monitor multicast service status in its own network.
4.8. Addressing Guidelines o Both AD's will determine how best to deploy multicast service
monitoring tools. Typically, each AD will deploy its own set of
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.
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. Security Considerations 5. Security Considerations
(Include discussion on DRM, AAA, Network Security) DRM and Application Accounting, Authorization and Authentication
should be the responsibility of the multicast application source
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.
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. Details will have to be worked out during implementation
(e.g., test tokens or trace token exchange process).
6. IANA Considerations 6. IANA Considerations
7. Conclusions 7. 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.3 provides an overview of one method that
finds the optimal Relay-Gateway combination via the use of an
Anycast IP address for AMT Relays.
8. References 8. References
8.1. Normative References 8.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- [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft-
ietf-mboned-auto-multicast-13, April 2012, Work in progress ietf-mboned-auto-multicast-13, April 2012, Work in progress
[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
IETF I-D Multicasting Applications Across Peering Points February 2014
[RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607, [RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607,
August 2006 August 2006
8.2. Informative References 8.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
9. Acknowledgments 9. Acknowledgments
IETF I-D Multicasting Applications Across Peering Points February 2014
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
Phone: 1-732-420-3292 Phone: 1-732-420-3292
 End of changes. 41 change blocks. 
81 lines changed or deleted 160 lines changed or added

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