draft-ietf-mboned-interdomain-peering-bcp-14.txt   rfc8313.txt 
MBONED Working Group P. Tarapore, Ed. Internet Engineering Task Force (IETF) P. Tarapore, Ed.
Internet-Draft R. Sayko Request for Comments: 8313 R. Sayko
Intended status: Best Current Practice AT&T BCP: 213 AT&T
Expires: May 3, 2018 G. Shepherd Category: Best Current Practice G. Shepherd
Cisco ISSN: 2070-1721 Cisco
T. Eckert, Ed. T. Eckert, Ed.
Huawei Huawei
R. Krishnan R. Krishnan
SupportVectors SupportVectors
October 30, 2017 January 2018
Use of Multicast Across Inter-Domain Peering Points Use of Multicast across Inter-domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-14
Abstract Abstract
This document examines the use of Source Specific Multicast (SSM) This document examines the use of Source-Specific Multicast (SSM)
across inter-domain peering points for a specified set of deployment across inter-domain peering points for a specified set of deployment
scenarios. The objective is to describe the setup process for scenarios. The objectives are to (1) describe the setup process for
multicast-based delivery across administrative domains for these multicast-based delivery across administrative domains for these
scenarios and document supporting functionality to enable this scenarios and (2) document supporting functionality to enable this
process. process.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This memo documents an Internet Best Current Practice.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
BCPs is available in Section 2 of RFC 7841.
This Internet-Draft will expire on May 3, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8313.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................4
2. Overview of Inter-domain Multicast Application Transport . . 5 2. Overview of Inter-domain Multicast Application Transport ........6
3. Inter-domain Peering Point Requirements for Multicast . . . . 6 3. Inter-domain Peering Point Requirements for Multicast ...........7
3.1. Native Multicast . . . . . . . . . . . . . . . . . . . . 7 3.1. Native Multicast ...........................................8
3.2. Peering Point Enabled with GRE Tunnel . . . . . . . . . . 8 3.2. Peering Point Enabled with GRE Tunnel .....................10
3.3. Peering Point Enabled with an AMT - Both Domains 3.3. Peering Point Enabled with AMT - Both Domains
Multicast Enabled . . . . . . . . . . . . . . . . . . . . 10 Multicast Enabled .........................................12
3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 3.4. Peering Point Enabled with AMT - AD-2 Not
Enabled . . . . . . . . . . . . . . . . . . . . . . . . . 12 Multicast Enabled .........................................14
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels
AD-2 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 through AD-2 ..............................................16
4. Functional Guidelines . . . . . . . . . . . . . . . . . . . . 16 4. Functional Guidelines ..........................................18
4.1. Network Interconnection Transport Guidelines . . . . . . 16 4.1. Network Interconnection Transport Guidelines ..............18
4.1.1. Bandwidth Management . . . . . . . . . . . . . . . . 16 4.1.1. Bandwidth Management ...............................19
4.2. Routing Aspects and Related Guidelines . . . . . . . . . 18 4.2. Routing Aspects and Related Guidelines ....................20
4.2.1. Native Multicast Routing Aspects . . . . . . . . . . 19 4.2.1. Native Multicast Routing Aspects ...................21
4.2.2. GRE Tunnel over Interconnecting Peering Point . . . . 19 4.2.2. GRE Tunnel over Interconnecting Peering Point ......22
4.2.3. Routing Aspects with AMT Tunnels . . . . . . . . . . 20 4.2.3. Routing Aspects with AMT Tunnels ...................22
4.2.4. Public Peering Routing Aspects . . . . . . . . . . . 22 4.2.4. Public Peering Routing Aspects .....................24
4.3. Back Office Functions - Provisioning and Logging 4.3. Back-Office Functions - Provisioning and Logging
Guidelines . . . . . . . . . . . . . . . . . . . . . . . 23 Guidelines ................................................26
4.3.1. Provisioning Guidelines . . . . . . . . . . . . . . . 24 4.3.1. Provisioning Guidelines ............................26
4.3.2. Interdomain Authentication Guidelines . . . . . . . . 25 4.3.2. Inter-domain Authentication Guidelines .............28
4.3.3. Log Management Guidelines . . . . . . . . . . . . . . 26 4.3.3. Log-Management Guidelines ..........................28
4.4. Operations - Service Performance and Monitoring 4.4. Operations - Service Performance and Monitoring
Guidelines . . . . . . . . . . . . . . . . . . . . . . . 27 Guidelines ................................................30
4.5. Client Reliability Models/Service Assurance Guidelines . 29 4.5. Client Reliability Models / Service Assurance Guidelines ..32
4.6. Application Accounting Guidelines . . . . . . . . . . . . 29 4.6. Application Accounting Guidelines .........................32
5. Troubleshooting and Diagnostics . . . . . . . . . . . . . . . 29 5. Troubleshooting and Diagnostics ................................32
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations ........................................33
6.1. DoS attacks (against state and bandwidth) . . . . . . . . 30 6.1. DoS Attacks (against State and Bandwidth) .................33
6.2. Content Security . . . . . . . . . . . . . . . . . . . . 32 6.2. Content Security ..........................................35
6.3. Peering Encryption . . . . . . . . . . . . . . . . . . . 34 6.3. Peering Encryption ........................................37
6.4. Operational Aspects . . . . . . . . . . . . . . . . . . . 34 6.4. Operational Aspects .......................................37
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 35 7. Privacy Considerations .........................................39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations ............................................40
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37 9. References .....................................................40
10. Change log [RFC Editor: Please remove] . . . . . . . . . . . 37 9.1. Normative References ......................................40
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 39 9.2. Informative References ....................................42
11.1. Normative References . . . . . . . . . . . . . . . . . . 39 Acknowledgments ...................................................43
11.2. Informative References . . . . . . . . . . . . . . . . . 40 Authors' Addresses ................................................44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
Content and data from several types of applications (e.g., live video Content and data from several types of applications (e.g., live video
streaming, software downloads) are well suited for delivery via streaming, software downloads) are well suited for delivery via
multicast means. The use of multicast for delivering such content or multicast means. The use of multicast for delivering such content or
other data offers significant savings of utilization of resources in other data offers significant savings in terms of utilization of
any given administrative domain. End user demand for such content or resources in any given administrative domain. End User (EU) demand
other data is growing. Often, this requires transporting the content for such content or other data is growing. Often, this requires
or other data across administrative domains via inter-domain peering transporting the content or other data across administrative domains
points. via inter-domain peering points.
The objective of this Best Current Practices document is twofold: The objectives of this document are twofold:
o Describe the technical process and establish guidelines for o Describe the technical process and establish guidelines for
setting up multicast-based delivery of application content or setting up multicast-based delivery of application content or
other data across inter-domain peering points via a set of use other data across inter-domain peering points via a set of
cases. use cases (where "Use Case 3.1" corresponds to Section 3.1,
"Use Case 3.2" corresponds to Section 3.2, etc.).
o Catalog all required information exchange between the o Catalog all required exchanges of information between the
administrative domains to support multicast-based delivery. This administrative domains to support multicast-based delivery. This
enables operators to initiate necessary processes to support enables operators to initiate necessary processes to support
inter-domain peering with multicast. inter-domain peering with multicast.
The scope and assumptions for this document are as follows: The scope and assumptions for this document are as follows:
o Administrative Domain 1 (AD-1) sources content to one or more End o Administrative Domain 1 (AD-1) sources content to one or more EUs
Users (EUs) in one or more Administrative Domain 2 (AD-2). AD-1 in one or more Administrative Domain 2 (AD-2) entities. AD-1 and
and AD-2 want to use IP multicast to allow supporting large and AD-2 want to use IP multicast to allow support for large and
growing EU populations with minimum amount of duplicated traffic growing EU populations, with a minimum amount of duplicated
to send across network links. traffic to send across network links.
o This document does not detail the case where EUs are * This document does not detail the case where EUs are
originating content. To support that additional service, it is originating content. To support that additional service, it is
recommended to use some method (outside the scope of this recommended that some method (outside the scope of this
document) by which the content from EUs is transmitted to the document) be used by which the content from EUs is transmitted
application in AD-1 that this document refers to as the to the application in AD-1 and AD-1 can send out the traffic as
multicast source and let it send out the traffic as IP IP multicast. From that point on, the descriptions in this
multicast. From that point on, the descriptions in this
document apply, except that they are not complete because they document apply, except that they are not complete because they
do not cover the transport or operational aspects of the leg do not cover the transport or operational aspects of the leg
from EU to AD-1. from the EU to AD-1.
o This document does not detail the case where AD-1 and AD-2 are * This document does not detail the case where AD-1 and AD-2 are
not directly connected to each other but only via one or more not directly connected to each other and are instead connected
AD-3 (transit providers). The cases described in this document via one or more other ADs (as opposed to a peering point) that
where tunnels are used between AD-1 and AD-2 can be applied to serve as transit providers. The cases described in this
such scenarios, but SLA ("Service Level Agreement") control for document where tunnels are used between AD-1 and AD-2 can be
example would be different. Other additional issues will applied to such scenarios, but SLA ("Service Level Agreement")
likely exist as well in such scenarios. This is for further control, for example, would be different. Additional issues
study. will likely exist as well in such scenarios. This topic is
left for further study.
o For the purpose of this document, the term "peering point" refers o For the purposes of this document, the term "peering point" refers
to a network connection ("link") between two administrative to a network connection ("link") between two administrative
network domains over which traffic is exchanged between them. network domains over which traffic is exchanged between them.
This is also referred to as a Network-to-Network Interface (NNI). This is also referred to as a Network-to-Network Interface (NNI).
Unless otherwise noted, the peering point is assumed to be a Unless otherwise noted, it is assumed that the peering point is a
private peering point, where the network connection is a private peering point, where the network connection is a
physically or virtually isolated network connection solely between physically or virtually isolated network connection solely between
AD-1 and AD-2. The other case is that of a broadcast peering AD-1 and AD-2. The other case is that of a broadcast peering
point which is a common option in public Internet Exchange Points point, which is a common option in public Internet Exchange Points
(IXP). See Section 4.2.2 for more details about that option. (IXPs). See Section 4.2.4 for more details.
o Administrative Domain 1 (AD-1) is enabled with native multicast. o AD-1 is enabled with native multicast. A peering point exists
A peering point exists between AD-1 and AD-2. between AD-1 and AD-2.
o It is understood that several protocols are available for this o It is understood that several protocols are available for this
purpose including PIM-SM and Protocol Independent Multicast - purpose, including Protocol-Independent Multicast - Sparse Mode
Source Specific Multicast (PIM-SSM) [RFC7761], Internet Group (PIM-SM) and Protocol-Independent Multicast - Source-Specific
Management Protocol (IGMP) [RFC3376], and Multicast Listener Multicast (PIM-SSM) [RFC7761], the Internet Group Management
Discovery (MLD) [RFC3810]. Protocol (IGMP) [RFC3376], and Multicast Listener Discovery (MLD)
[RFC3810].
o As described in Section 2, the source IP address of the multicast o As described in Section 2, the source IP address of the (so-called
stream in the originating AD (AD-1) is known. Under this "(S,G)") multicast stream in the originating AD (AD-1) is known.
condition, PIM-SSM use is beneficial as it allows the receiver's Under this condition, using PIM-SSM is beneficial, as it allows
upstream router to directly send a JOIN message to the source the receiver's upstream router to send a join message directly to
without the need of invoking an intermediate Rendezvous Point the source without the need to invoke an intermediate Rendezvous
(RP). Use of SSM also presents an improved threat mitigation Point (RP). The use of SSM also presents an improved threat
profile against attack, as described in [RFC4609]. Hence, in the mitigation profile against attack, as described in [RFC4609].
case of inter-domain peering, it is recommended to use only SSM Hence, in the case of inter-domain peering, it is recommended that
protocols; the setup of inter- domain peering for ASM (Any-Source only SSM protocols be used; the setup of inter-domain peering for
Multicast) is not in scope for this document. ASM (Any-Source Multicast) is out of scope for this document.
o The rest of the document assumes that PIM-SSM and BGP are used o The rest of this document assumes that PIM-SSM and BGP are used
across the peering point plus AMT and/or GRE according to across the peering point, plus Automatic Multicast Tunneling (AMT)
scenario. The use of other protocols is beyond the scope of this [RFC7450] and/or Generic Routing Encapsulation (GRE), according to
document. the scenario in question. The use of other protocols is beyond
the scope of this document.
o An Automatic Multicast Tunnel (AMT) [RFC7450] is setup at the o AMT is set up at the peering point if either the peering point or
peering point if either the peering point or AD-2 is not multicast AD-2 is not multicast enabled. It is assumed that an AMT relay
enabled. It is assumed that an AMT Relay will be available to a will be available to a client for multicast delivery. The
client for multicast delivery. The selection of an optimal AMT selection of an optimal AMT relay by a client is out of scope for
relay by a client is out of scope for this document. Note that this document. Note that using AMT is necessary only when native
AMT use is necessary only when native multicast is unavailable in multicast is unavailable in the peering point (Use Case 3.3) or in
the peering point (Use Case 3.3) or in the downstream the downstream administrative domain (Use Cases 3.4 and 3.5).
administrative domain (Use Cases 3.4, and 3.5).
o The collection of billing data is assumed to be done at the o It is assumed that the collection of billing data is done at the
application level and is not considered to be a networking issue. application level and is not considered to be a networking issue.
The settlements process for end user billing and/or inter-provider The settlements process for EU billing and/or inter-provider
billing is out of scope for this document. 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 the considered within the context of a cooperative process between the
two domains. 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
is beyond the scope of this document. is beyond the scope of this document.
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 native o The peering point is either multicast enabled (end-to-end native
multicast across the two domains) or it is connected by one of two multicast across the two domains) or connected by one of two
possible tunnel types: possible tunnel types:
o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] allowing * A GRE tunnel [RFC2784] allowing multicast tunneling across the
multicast tunneling across the peering point, or peering point, or
o An Automatic Multicast Tunnel (AMT) [RFC7450]. * AMT [RFC7450].
o A service provider controls one or more application sources in o A service provider controls one or more application sources in
AD-1 which will send multicast IP packets via one or more (S,G)s AD-1 that will send multicast IP packets via one or more (S,G)s
(multicast traffic flows, see Section 4.2.1 if you are unfamiliar (multicast traffic flows; see Section 4.2.1 if you are unfamiliar
with IP multicast). It is assumed that the service being provided with IP multicast). It is assumed that the service being provided
is suitable for delivery via multicast (e.g. live video streaming is suitable for delivery via multicast (e.g., live video streaming
of popular events, software downloads to many devices, etc.), and of popular events, software downloads to many devices) and that
that the packet streams will carried by a suitable multicast the packet streams will be carried by a suitable multicast
transport protocol. transport protocol.
o An End User (EU) controls a device connected to AD-2, which runs o An EU controls a device connected to AD-2, which runs an
an application client compatible with the service provider's application client compatible with the service provider's
application source. application source.
o The application client joins appropriate (S,G)s in order to o The application client joins appropriate (S,G)s in order to
receive the data necessary to provide the service to the EU. The receive the data necessary to provide the service to the EU. The
mechanisms by which the application client learns the appropriate mechanisms by which the application client learns the appropriate
(S,G)s are an implementation detail of the application, and are (S,G)s are an implementation detail of the application and are out
out of scope for this document. of scope for this document.
The assumption here is that AD-1 has ultimate responsibility for The assumption here is that AD-1 has ultimate responsibility for
delivering the multicast based service on behalf of the content delivering the multicast-based service on behalf of the content
source(s). All relevant interactions between the two domains source(s). All relevant interactions between the two domains
described in this document are based on this assumption. described in this document are based on this assumption.
Note that domain 2 may be an independent network domain (e.g.: Tier 1 Note that AD-2 may be an independent network domain (e.g., a Tier 1
network operator domain). Alternately, domain 2 could also be an network operator domain). Alternately, AD-2 could also be an
Enterprise network domain operated by a single customer of AD-1. The enterprise network domain operated by a single customer of AD-1. The
peering point architecture and requirements may have some unique peering point architecture and requirements may have some unique
aspects associated with the Enterprise case. aspects associated with enterprise networks; see Section 3.
The Use Cases describing various architectural configurations for the
multicast distribution along with associated requirements is
described in section 3. Unique aspects related to the Enterprise
network possibility will be described in this section. Section 4
contains a comprehensive list of pertinent information that needs to
be exchanged between the two domains in order to support functions to
enable the application transport.
Note that domain 2 may be an independent network domain (e.g., Tier 1
network operator domain). Alternately, domain 2 could also be an
Enterprise network domain operated by a single customer.
The Use Cases describing various architectural configurations for the The use cases describing various architectural configurations for
multicast distribution along with associated requirements is multicast distribution, along with associated requirements, are
described in Section 3. The peering point architecture and described in Section 3. Section 4 contains a comprehensive list of
requirements may have some unique aspects associated with the pertinent information that needs to be exchanged between the two
Enterprise case. These unique aspects will also be described in domains in order to support functions to enable application
Section 3. Section 4 contains a comprehensive list of pertinent transport.
information that needs to be exchanged between the two domains in
order to support functions to enable the application transport.
3. Inter-domain Peering Point Requirements for Multicast 3. Inter-domain Peering Point Requirements for Multicast
The transport of applications using multicast requires that the The transport of applications using multicast requires that the
inter-domain peering point is enabled to support such a process. inter-domain peering point be enabled to support such a process.
There are five Use Cases for consideration in this document. This section presents five use cases for consideration.
3.1. Native Multicast 3.1. Native Multicast
This Use Case involves end-to-end Native Multicast between the two This use case involves end-to-end native multicast between the two
administrative domains and the peering point is also native multicast administrative domains, and the peering point is also native
enabled - see Figure 1. multicast enabled. See Figure 1.
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \ / (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \ / \ / \
| +----+ | | | | +----+ | | |
| | | +------+ | | +------+ | +----+ | | | +------+ | | +------+ | +----+
| | AS |------>| BR |-|---------|->| BR |-------------|-->| EU | | | AS |------>| BR |-|---------|->| BR |-------------|-->| EU |
| | | +------+ | I1 | +------+ |I2 +----+ | | | +------+ | I1 | +------+ |I2 +----+
\ +----+ / \ / \ +----+ / \ /
\ / \ / \ / \ /
\ / \ / \ / \ /
------------------- ------------------- ------------------- -------------------
AD = Administrative Domain (Independent Autonomous System) AD = Administrative Domain (independent autonomous system)
AS = Application (e.g., Content) Multicast Source AS = multicast (e.g., content) Application Source
BR = Border Router BR = Border Router
I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP)
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:
o Most efficient use of bandwidth in both domains. o Most efficient use of bandwidth in both domains.
o Fewer devices in the path traversed by the multicast stream when o Fewer devices in the path traversed by the multicast stream when
compared to an AMT enabled peering point. compared to an AMT-enabled peering point.
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 to AD-2 instead of individual unicast to every EU in
in AD-2 is that it does not have the ability to count the number of AD-2 is that it does not have the ability to count the number of EUs
End Users as well as the transmitted bytes delivered to them. This as well as the transmitted bytes delivered to them. This information
information is relevant from the perspective of customer billing and is relevant from the perspective of customer billing and operational
operational logs. It is assumed that such data will be collected by logs. It is assumed that such data will be collected by the
the application layer. The application layer mechanisms for application layer. The application-layer mechanisms for generating
generating this information need to be robust enough such that all this information need to be robust enough so that all pertinent
pertinent requirements for the source provider and the AD operator requirements for the source provider and the AD operator are
are satisfactorily met. The specifics of these methods are beyond satisfactorily met. The specifics of these methods are beyond the
the scope of this document. scope of this document.
Architectural guidelines for this configuration are as follows: Architectural guidelines for this configuration are as follows:
a. Dual homing for peering points between domains is recommended as a. Dual homing for peering points between domains is recommended as
a way to ensure reliability with full BGP table visibility. a way to ensure reliability with full BGP table visibility.
b. If the peering point between AD-1 and AD-2 is a controlled b. If the peering point between AD-1 and AD-2 is a controlled
network environment, then bandwidth can be allocated accordingly network environment, then bandwidth can be allocated accordingly
by the two domains to permit the transit of non- rate adaptive by the two domains to permit the transit of non-rate-adaptive
multicast traffic. If this is not the case, then the multicast multicast traffic. If this is not the case, then the multicast
traffic must support rate-adaption (see [BCP145]). traffic must support congestion control via any of the mechanisms
described in Section 4.1 of [BCP145].
c. The sending and receiving of multicast traffic between two c. The sending and receiving of multicast traffic between two
domains is typically determined by local policies associated with domains is typically determined by local policies associated with
each domain. For example, if AD-1 is a service provider and AD-2 each domain. For example, if AD-1 is a service provider and AD-2
is an enterprise, then AD-1 may support local policies for is an enterprise, then AD-1 may support local policies for
traffic delivery to, but not traffic reception from, AD-2. traffic delivery to, but not traffic reception from, AD-2.
Another example is the use of a policy by which AD-1 delivers 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 specified content to AD-2 only if such delivery has been accepted
by contract. by contract.
d. Relevant information on multicast streams delivered to End Users d. It is assumed that relevant information on multicast streams
in AD-2 is assumed to be collected by available capabilities in delivered to EUs in AD-2 is collected by available capabilities
the application layer. The precise nature and formats of the in 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.
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 GRE tunnel provisioned over the peering point. See
peering point. See Figure 2. Figure 2.
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \ / (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \ / \ / \
| +----+ +---+ | (I1) | +---+ | | +----+ +---+ | (I1) | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU | | | AS |-->|BR| +---+-| | +---+ |BR| -------->|-->| EU |
| | | +--+ <.......|........|........>+--+ |I2 +----+ | | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / I1 \ / \ +----+ / I1 \ /
\ / GRE \ / \ / GRE \ /
\ / Tunnel \ / \ / Tunnel \ /
------------------- ------------------- ------------------- -------------------
AD = Administrative Domain (Independent Autonomous System) AD = Administrative Domain (independent autonomous system)
AS = Application (e.g., Content) Multicast Source AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not necessarily multicast enabled uBR = unicast Border Router - not necessarily multicast enabled;
may be the same router as BR may be the same router as BR
BR = Border Router - for multicast BR = Border Router - for multicast
I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) I1 = AD-1 and AD-2 multicast interconnection (e.g., MP-BGP)
I2 = AD-2 and EU Multicast Connection I2 = AD-2 and EU multicast connection
Figure 2: Content Distribution via GRE Tunnel Figure 2: Content Distribution via GRE Tunnel
In this case, the interconnection I1 between AD-1 and AD-2 in In this case, interconnection I1 between AD-1 and AD-2 in Figure 2 is
Figure 2 is multicast enabled via a Generic Routing Encapsulation multicast enabled via a GRE tunnel [RFC2784] between the two BRs and
Tunnel (GRE) [RFC2784] between the two BR and encapsulating the encapsulating the multicast protocols across it.
multicast protocols across it.
Normally, this approach is choosen if the uBR physcially connected to Normally, this approach is chosen if the uBR physically connected to
the peering link can or should not be enabled for IP multicast. This the peering link cannot or should not be enabled for IP multicast.
approach may also be beneficial if BR and uBR are the same device, This approach may also be beneficial if the BR and uBR are the same
but the peering link is a broadcast domain (IXP), see Figure 6. device but the peering link is a broadcast domain (IXP); see
Section 4.2.4.
The routing configuration is basically unchanged: Instead of BGP The routing configuration is basically unchanged: instead of running
(SAFI2) across the native IP multicast link between AD-1 and AD-2, BGP (SAFI-2) ("SAFI" stands for "Subsequent Address Family
BGP (SAFI2) is now run across the GRE tunnel. Identifier") across the native IP multicast link between AD-1 and
AD-2, BGP (SAFI-2) is now run across the GRE tunnel.
Advantages of this configuration: Advantages of this configuration:
o Highly efficient use of bandwidth in both domains, although not as o Highly efficient use of bandwidth in both domains, although not as
efficient as the fully native multicast Use Case. efficient as the fully native multicast use case (Section 3.1).
o Fewer devices in the path traversed by the multicast stream when o Fewer devices in the path traversed by the multicast stream when
compared to an AMT enabled peering point. compared to an AMT-enabled peering point.
o Ability to support partial and/or incremental IP multicast o Ability to support partial and/or incremental IP multicast
deployments in AD- 1 and/or AD-2: Only the path(s) between AS/BR deployments in AD-1 and/or AD-2: only the path or paths between
(AD-1) and BR/EU (AD-2) need to be multicast enabled. The uBRs the AS/BR (AD-1) and the BR/EU (AD-2) need to be multicast
may not support IP multicast or enabling it could be seen as enabled. The uBRs may not support IP multicast or enabling it
operationally risky on that important edge node whereas dedicated could be seen as operationally risky on that important edge node,
BR nodes for IP multicast may be more acceptable at least whereas dedicated BR nodes for IP multicast may (at least
initially. BR can also be located such that only parts of the initially) be more acceptable. The BR can also be located such
domain may need to support native IP multicast (e.g.: only the that only parts of the domain may need to support native IP
core in AD-1 but not edge networks towards uBR). multicast (e.g., only the core in AD-1 but not edge networks
towards the uBR).
o GRE is an existing technology and is relatively simple to o GRE is an existing technology and is relatively simple to
implement. implement.
Disadvantages of this configuration: Disadvantages of this configuration:
o Per Use Case 3.1, current router technology cannot count the o Per Use Case 3.1, current router technology cannot count the
number of end users or the number bytes transmitted. number of EUs or the number of bytes transmitted.
o GRE tunnel requires manual configuration. o The GRE tunnel requires manual configuration.
o The GRE must be established prior to stream starting. o The GRE tunnel must be established prior to starting the stream.
o The GRE tunnel is often left pinned up. o The GRE tunnel is often left pinned up.
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
Case 3.1. Two additional guidelines are as follows: Use Case 3.1. Two additional guidelines are as follows:
e. GRE tunnels are typically configured manually between peering e. GRE tunnels are typically configured manually between peering
points to support multicast delivery between domains. points to support multicast delivery between domains.
f. It is recommended that the GRE tunnel (tunnel server) f. It is recommended that the GRE tunnel (tunnel server)
configuration in the source network is such that it only configuration in the source network be 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 delivery entire network. This practice will prevent unauthorized delivery
of applications through the tunnel (e.g., if application - e.g., of applications through the tunnel (for example, if the
content - is not part of an agreed inter-domain partnership). application (e.g., content) is not part of an agreed-upon
inter-domain partnership).
3.3. Peering Point Enabled with an AMT - Both Domains Multicast Enabled 3.3. Peering Point Enabled with AMT - Both Domains Multicast Enabled
Both administrative domains in this Use Case are assumed to be native It is assumed that both administrative domains in this use case are
multicast enabled here; however, the peering point is not. native multicast enabled here; however, the peering point is not.
The peering point is enabled with an Automatic Multicast Tunnel. The The peering point is enabled with AMT. The basic configuration is
basic configuration is depicted in Figure 2. depicted in Figure 3.
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Multicast Enabled) \ / (Multicast Enabled) \ / (Multicast Enabled) \
/ \ / \ / \ / \
| +----+ +---+ | I1 | +---+ | | +----+ +---+ | I1 | +---+ |
| | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+ | | | +--+ |uBR|-|--------|-|uBR| +--+ | +----+
| | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU | | | AS |-->|AR| +---+-| | +---+ |AG| -------->|-->| EU |
| | | +--+ <.......|........|........>+--+ |I2 +----+ | | | +--+<........|........|........>+--+ |I2 +----+
\ +----+ / AMT \ / \ +----+ / AMT \ /
\ / Tunnel \ / \ / Tunnel \ /
\ / \ / \ / \ /
------------------- ------------------- ------------------- -------------------
AD = Administrative Domain (Independent Autonomous System) AD = Administrative Domain (independent autonomous system)
AS = Application (e.g., Content) Multicast Source AS = multicast (e.g., content) Application Source
AR = AMT Relay AR = AMT Relay
AG = AMT Gateway AG = AMT Gateway
uBR = unicast Border Router - not multicast enabled uBR = unicast Border Router - not multicast enabled;
otherwise AR=uBR (AD-1), uBR=AG (AD-2) also, either AR = uBR (AD-1) or uBR = AG (AD-2)
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 3: - AMT Interconnection between AD-1 and AD-2 Figure 3: 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.
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 the * Dynamic interconnection between the gateway-relay pair across
peering point. the peering point.
o Ability to serve clients and servers with differing policies. * Ability to serve clients and servers with differing policies.
Disadvantages of this configuration: Disadvantages of this configuration:
o Per Use Case 3.1 (AD-2 is native multicast), current router o Per Use Case 3.1 (AD-2 is native multicast), current router
technology cannot count the number of end users or the number of technology cannot count the number of EUs or the number of bytes
bytes transmitted to all end users. transmitted to all EUs.
o Additional devices (AMT Gateway and Relay pairs) may be introduced o Additional devices (AMT gateway and relay pairs) may be introduced
into the path if these services are not incorporated in the into the path if these services are not incorporated into the
existing routing nodes. existing routing nodes.
o Currently undefined mechanisms for the AG to automatically select o Currently undefined mechanisms for the AG to automatically select
the optimal AR. the optimal AR.
Architectural guidelines for this configuration are as follows: Architectural guidelines for this configuration are as follows:
Guidelines (a) through (d) are the same as those described in Use Guidelines (a) through (d) are the same as those described in
Case 3.1. In addition, Use Case 3.1. In addition,
e. It is recommended that AMT Relay and Gateway pairs be configured e. It is recommended that AMT relay and gateway pairs be configured
at the peering points to support multicast delivery between at the peering points to support multicast delivery between
domains. AMT tunnels will then configure dynamically across the domains. AMT tunnels will then configure dynamically across the
peering points once the Gateway in AD-2 receives the (S, G) peering points once the gateway in AD-2 receives the (S,G)
information from the EU. information from the EU.
3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled 3.4. Peering Point Enabled with AMT - AD-2 Not Multicast Enabled
In this AMT Use Case, the second administrative domain AD-2 is not In this AMT use case, AD-2 is not multicast enabled. Hence, the
multicast enabled. Hence, the interconnection between AD-2 and the interconnection between AD-2 and the EU is also not multicast
End User is also not multicast enabled. This Use Case is depicted in enabled. This use case is depicted in Figure 4.
Figure 3.
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Non Multicast \ / (Multicast Enabled) \ / (Not Multicast \
/ \ / Enabled) \ N(large) / \ / Enabled) \ N(large)
| +----+ +---+ | | +---+ | #EU | +----+ +---+ | | +---+ | # EUs
| | | +--+ |uBR|-|--------|-|uBR| | +----+ | | | +--+ |uBR|-|--------|-|uBR| | +----+
| | AS |-->|AR| +---+-| | +---+ ................>|EU/G| | | AS |-->|AR| +---+-| | +---+ ................>|EU/G|
| | | +--+ <.......|........|........... |I2 +----+ | | | +--+<........|........|........... |I2 +----+
\ +----+ / N x AMT\ / \ +----+ / N x AMT\ /
\ / Tunnel \ / \ / Tunnel \ /
\ / \ / \ / \ /
------------------- ------------------- ------------------- -------------------
AS = Application Multicast Source AS = multicast (e.g., content) Application Source
uBR = unicast Border Router - not multicast enabled, uBR = unicast Border Router - not multicast enabled;
otherwise AR = uBR (in AD-1). otherwise, AR = uBR (in AD-1)
AR = AMT Relay AR = AMT Relay
EU/G = Gateway client embedded in EU device EU/G = Gateway client embedded in EU device
I2 = AMT Tunnel Connecting EU/G to AR in AD-1 through Non-Multicast I2 = AMT tunnel connecting EU/G to AR in AD-1 through
Enabled AD-2. non-multicast-enabled AD-2
Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway Figure 4: AMT Tunnel Connecting AD-1 AMT Relay and EU Gateway
This Use Case is equivalent to having unicast distribution of the This use case is equivalent to having unicast distribution of the
application through AD-2. The total number of AMT tunnels would be application through AD-2. The total number of AMT tunnels would be
equal to the total number of End Users requesting the application. equal to the total number of EUs requesting the application. The
The peering point thus needs to accommodate the total number of AMT peering point thus needs to accommodate the total number of AMT
tunnels between the two domains. Each AMT tunnel can provide the tunnels between the two domains. Each AMT tunnel can provide the
data usage associated with each End User. data usage associated with each EU.
Advantages of this configuration: Advantages of this configuration:
o Efficient use of bandwidth in AD-1 (The closer AR is to uBR, the o Efficient use of bandwidth in AD-1 (the closer the AR is to the
more efficient). uBR, the more efficient).
o Ability for AD-1 to introduce IP multicast based content delivery o Ability of AD-1 to introduce content delivery based on IP
without any support by network devices in AD-2: Only application multicast, without any support by network devices in AD-2: only
side in the EU device needs to perform AMT gateway library the application side in the EU device needs to perform AMT gateway
functionality to receive traffic from AMT relay. library functionality to receive traffic from the AMT relay.
o Allows for AD-2 to "upgrade" to Use Case 3.5 (see below) at a o Allows AD-2 to "upgrade" to Use Case 3.5 (see Section 3.5) at a
later time without any change in AD-1 at that time. later time, without any change in AD-1 at that time.
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 the * Dynamic interconnection between the AMT gateway-relay pair
peering point. across the peering point.
o Ability to serve clients and servers with differing policies. * Ability to serve clients and servers with differing 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 EU and is also able to
able to track data usage (bytes) delivered to the EU. track data usage (bytes) delivered to the EU.
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-1. gateway needs to be able to find the "correct" AMT relay in AD-1.
Architectural guidelines for this configuration are as follows: Architectural guidelines for this configuration are as follows:
Guidelines (a) through (c) are the same as those described in Use Guidelines (a) through (c) are the same as those described in
Case 3.1. Use Case 3.1. In addition,
d. It is necessary that proper procedures are implemented such that d. It is necessary that proper procedures be implemented such that
the AMT Gateway at the End User device is able to find the correct the AMT gateway at the EU device is able to find the correct AMT
AMT Relay for each (S,G) content stream. Standard mechanisms for relay for each (S,G) content stream. Standard mechanisms for
that selection are still subject to ongoing work. This includes that selection are still subject to ongoing work. This includes
use of anycast gateway addresses, anycast DNS names, explicit the use of anycast gateway addresses, anycast DNS names, or
configuration that is mapping (S,G) to a relay address or letting explicit configuration that maps (S,G) to a relay address; or
the application in the EU/G provide the relay address to the letting the application in the EU/G provide the relay address to
embedded AMT gateway function. the embedded AMT gateway function.
e. The AMT tunnel capabilities are expected to be sufficient for the e. The AMT tunnel's capabilities are expected to be sufficient for
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 EUs 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: Figure 5 illustrates a variation of Use Case 3.4:
------------------- ------------------- ------------------- -------------------
/ AD-1 \ / AD-2 \ / AD-1 \ / AD-2 \
/ (Multicast Enabled) \ / (Non Multicast \ / (Multicast Enabled) \ / (Not Multicast \
/ +---+ \ (I1) / +---+ Enabled) \ / +---+ \ (I1) / +---+ Enabled) \
| +----+ |uBR|-|--------|-|uBR| | | +----+ |uBR|-|--------|-|uBR| |
| | | +--+ +---+ | | +---+ +---+ | +----+ | | | +--+ +---+ | | +---+ +---+ | +----+
| | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G| | | AS |-->|AR|<........|.... | +---+ |AG/|....>|EU/G|
| | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+ | | | +--+ | ......|.|AG/|..........>|AR2| |I3 +----+
\ +----+ / I1 \ |AR1| I2 +---+ / \ +----+ / I1 \ |AR1| I2 +---+ /
\ / single \+---+ / \ / Single \+---+ /
\ / AMT Tunnel \ / \ / AMT Tunnel \ /
------------------- ------------------- ------------------- -------------------
uBR = unicast Border Router - not multicast enabled uBR = unicast Border Router - not multicast enabled;
otherwise AR=uBR (AD-1) or ubr=AGAR1 (AD-2) also, either AR = uBR (AD-1) or uBR = AGAR1 (AD-2)
AS = Application Source AS = multicast (e.g., content) Application Source
AR = AMT Relay in AD-1 AR = AMT Relay in AD-1
AGAR1 = AMT Gateway/Relay node in AD-2 across Peering Point AGAR1 = AMT Gateway/Relay node in AD-2 across peering point
I1 = AMT Tunnel Connecting AR in AD-1 to GW in AGAR1 in AD-2 I1 = AMT tunnel connecting AR in AD-1 to gateway in AGAR1 in AD-2
AGAR2 = AMT Gateway/Relay node at AD-2 Network Edge AGAR2 = AMT Gateway/Relay node at AD-2 network edge
I2 = AMT Tunnel Connecting Relay in AGAR1 to GW in AGAR2 I2 = AMT tunnel connecting relay in AGAR1 to gateway in AGAR2
EU/G = Gateway client embedded in EU device EU/G = Gateway client embedded in EU device
I3 = AMT Tunnel Connecting EU/G to AR in AGAR2 I3 = AMT tunnel connecting EU/G to AR in AGAR2
Figure 5: AMT Tunnel Connecting AMT Relay and Relays Figure 5: AMT Tunnel Connecting AMT Gateways and Relays
Use Case 3.4 results in several long AMT tunnels crossing the entire Use Case 3.4 results in several long AMT tunnels crossing the entire
network of AD-2 linking the EU device and the AMT Relay in AD-1 network of AD-2 linking the EU device and the AMT relay in AD-1
through the peering point. Depending on the number of End Users, through the peering point. Depending on the number of EUs, there is
there is a likelihood of an unacceptably high amount of traffic due a likelihood of an unacceptably high amount of traffic due to the
to the large number of AMT tunnels - and unicast streams - through large number of AMT tunnels -- and unicast streams -- through the
the peering point. This situation can be alleviated as follows: peering point. This situation can be alleviated as follows:
o Provisioning of strategically located AMT nodes in AD-2 AD-2. An o Provisioning of strategically located AMT nodes in AD-2. An
AMT node comprises co-location of an AMT Gateway and an AMT Relay. AMT node comprises co-location of an AMT gateway and an AMT relay.
No change is required by AD-1 compared to 3.4. This can be done No change is required by AD-1, as compared to Use Case 3.4. This
whenever AD-2 seems fit (too much traffic across peering point. can be done whenever AD-2 sees fit (e.g., too much traffic across
the peering point).
o One such node is at the AD-2 side of the peering point (node AGAR1 o One such node is on the AD-2 side of the peering point (AMT node
in above Figure). AGAR1 in Figure 5).
o Single AMT tunnel established across peering point linking AMT o A single AMT tunnel established across the peering point linking
Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. the AMT relay in AD-1 to the AMT gateway in 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 the peering point in AD-2 to
other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2
linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 in linking the AMT relay in AGAR1 to the AMT gateway in AMT
Figure 4. node AGAR2 (Figure 5).
o AMT tunnels linking EU device (via Gateway client embedded in o AMT tunnels linking an EU device (via a gateway client embedded in
device) and AMT Relay in appropriate AMT node at edge of AD-2: the device) and an AMT relay in an appropriate AMT node at the
e.g., I3 linking EU Gateway in device to AMT Relay in AMT node edge of AD-2: e.g., I3 linking the EU gateway in the device to the
AGAR2. AMT relay in AMT node AGAR2.
o In the most simple option (not shown), AD-2 only deploys a single o In the simplest option (not shown), AD-2 only deploys a single
AGAR1 and lets EU/G build AMT tunnels directly to it. This setup AGAR1 node and lets the EU/G build AMT tunnels directly to it.
already solves the problem of replicated traffic across the This setup already solves the problem of replicated traffic across
peering point. As soon as there is need to support more AMT the peering point. As soon as there is a need to support more AMT
tunnels to EU/G, then additional AGAR2 nodes can be deployed by tunnels to the EU/G, then additional AGAR2 nodes can be deployed
AD-2. by AD-2.
The advantage for such a chained set of AMT tunnels is that the total The advantage of such a chained set of AMT tunnels is that the total
number of unicast streams across AD-2 is significantly reduced, thus number of unicast streams across AD-2 is significantly reduced, thus
freeing up bandwidth. Additionally, there will be a single unicast freeing up bandwidth. Additionally, there will be a single unicast
stream across the peering point instead of possibly, an unacceptably stream across the peering point instead of, possibly, an unacceptably
large number of such streams per Use Case 3.4. However, this implies large number of such streams per Use Case 3.4. However, this implies
that several AMT tunnels will need to be dynamically configured by that several AMT tunnels will need to be dynamically configured by
the various AMT Gateways based solely on the (S,G) information the various AMT gateways, based solely on the (S,G) information
received from the application client at the EU device. A suitable received from the application client at the EU device. A suitable
mechanism for such dynamic configurations is therefore critical. mechanism for such dynamic configurations is therefore critical.
Architectural guidelines for this configuration are as follows: Architectural guidelines for this configuration are as follows:
Guidelines (a) through (c) are the same as those described in Use Guidelines (a) through (c) are the same as those described in
Case 3.1. Use Case 3.1. In addition,
d. It is necessary that proper procedures are implemented such that d. It is necessary that proper procedures be implemented such that
the various AMT Gateways (at the End User devices and the AMT the various AMT gateways (at the EU devices and the AMT nodes in
nodes in AD-2) are able to find the correct AMT Relay in other AMT AD-2) are able to find the correct AMT relay in other AMT nodes
nodes as appropriate. Standard mechanisms for that selection are as appropriate. Standard mechanisms for that selection are still
still subject to ongoing work. This includes use of anycast subject to ongoing work. This includes the use of anycast
gateway addresses, anycast DNS names, or explicit configuration gateway addresses, anycast DNS names, or explicit configuration
that is mapping (S,G) to a relay address. On the EU/G, this that maps (S,G) to a relay address. On the EU/G, this mapping
mapping information may come from the application. information may come from the application.
e. The AMT tunnel capabilities are expected to be sufficient for the e. The AMT tunnel's capabilities are expected to be sufficient for
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 EUs in AD-2.
4. Functional Guidelines 4. Functional Guidelines
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.
4.1. Network Interconnection Transport Guidelines 4.1. Network Interconnection Transport 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 the two
agreed to between the two administrative domains to support multicast administrative domains will need to agree on to support multicast
delivery. delivery.
o Number of Peering Points. o Number of peering points.
o Peering Point Addresses and Locations. o Peering point addresses and locations.
o Connection Type - Dedicated for Multicast delivery or shared with o Connection type - Dedicated for multicast delivery or shared with
other services. other services.
o Connection Mode - Direct connectivity between the two AD's or via o Connection mode - Direct connectivity between the two ADs or via
another ISP. another ISP.
o Peering Point Protocol Support - Multicast protocols that will be o Peering point protocol support - Multicast protocols that will be
used for multicast delivery will need to be supported at these used for multicast delivery will need to be supported at these
points. Examples of protocols include eBGP [RFC4760] and MBGP points. Examples of such protocols include External BGP (EBGP)
[RFC4760]. [RFC4760] peering via MP-BGP (Multiprotocol BGP) SAFI-2 [RFC4760].
o Bandwidth Allocation - If shared with other services, then there o Bandwidth allocation - If shared with other services, then there
needs to be a determination of the share of bandwidth reserved for needs to be a determination of the share of bandwidth reserved for
multicast delivery. See section 4.1.1 below for more details. multicast delivery. See Section 4.1.1 below for more details.
o QoS Requirements - Delay and/or latency specifications that need o QoS requirements - Delay and/or latency specifications that need
to be specified in an SLA. to be specified in an SLA.
o AD Roles and Responsibilities - the role played by each AD for o AD roles and responsibilities - The role played by each AD for
provisioning and maintaining the set of peering points to support provisioning and maintaining the set of peering points to support
multicast delivery. multicast delivery.
4.1.1. Bandwidth Management 4.1.1. Bandwidth Management
Like IP unicast traffic, IP multicast traffic carried across non- Like IP unicast traffic, IP multicast traffic carried across
controlled networks must comply to Congestion Control Principles as non-controlled networks must comply with congestion control
described in [BCP41] and explained in detail for UDP IP multicast in principles as described in [BCP41] and as explained in detail for UDP
[BCP145]. IP multicast in [BCP145].
Non-controlled networks (such as the Internet) are those where there Non-controlled networks (such as the Internet) are networks where
is no policy for managing bandwidth other than best effort with fair there is no policy for managing bandwidth other than best effort with
share of bandwidth under congestion. As a simplified rule of thumb, a fair share of bandwidth under congestion. As a simplified rule of
complying to congestion control principles means to reduce bandwidth thumb, complying with congestion control principles means reducing
under congestion in a way that is fair to competing competing bandwidth under congestion in a way that is fair to competing
(typically TCP) flow ("rate adaptive"). (typically TCP) flows ("rate adaptive").
In many instances, multicast content delivery evolves from intra- In many instances, multicast content delivery evolves from
domain deployments where it is handled as a controlled network intra-domain deployments where it is handled as a controlled network
service and of not complyng to congestion control principles. It was service and does not comply with congestion control principles. It
given a reserved amount of bandwidth and admitted to the network so was given a reserved amount of bandwidth and admitted to the network
that congestion never occurs. Therefore the congestion control issue so that congestion never occurs. Therefore, the congestion control
should be given specific attention when evolving to an interdomain issue should be given specific attention when evolving to an
peering deployment. inter-domain peering deployment.
In the case where end-to-end IP multicast traffic passes across the In the case where end-to-end IP multicast traffic passes across the
network of two ADs (and their subsidiaries/customers), both ADs must network of two ADs (and their subsidiaries/customers), both ADs must
agree on a consistent traffic management policy. If for example AD-1 agree on a consistent traffic-management policy. If, for example,
sources non congestion aware IP multicast traffic and AD-2 carries it AD-1 sources non-congestion-aware IP multicast traffic and AD-2
as best effort traffic across links shared with other Internet carries it as best-effort traffic across links shared with other
traffic and subject to congestion, this will not work: Under Internet traffic (subject to congestion), this will not work: under
congestion, some amount of that traffic will be dropped, rendering congestion, some amount of that traffic will be dropped, often
the remaining packets often as undecodeable garbage clogging up the rendering the remaining packets as undecodable garbage clogging up
network in AD-2 and because this is not congestion aware, the loss the network in AD-2; because this traffic is not congestion aware,
does not reduce this rate. Competing traffic will not get their fair the loss does not reduce this rate. Competing traffic will not get
share under congestion, and EUs will be frusted by extremely bad their fair share under congestion, and EUs will be frustrated by the
quality of both their IP multicast and other (e.g.: TCP) traffic. extremely bad quality of both their IP multicast traffic and other
Note that this is not an IP multicast technology issue, but solely a (e.g., TCP) traffic. Note that this is not an IP multicast
transport/application layer issue: The problem would equally happen technology issue but is solely a transport-layer / application-layer
if AD-1 would send non-rate adaptive unicast traffic,, for example issue: the problem would just as likely happen if AD-1 were to send
legacy IPTV video-on-demand traffic which typically is also non non-rate-adaptive unicast traffic -- for example, legacy IPTV
congestion aware. Because rate adaption in IP unicast video is video-on-demand traffic, which is typically also non-congestion
commonplace today because of ABR (Adaptive Bitrate Video), it is very aware. Note that because rate adaptation in IP unicast video is
unlikely for this to happen though in reality with IP unicast. commonplace today due to the availability of ABR (Adaptive Bitrate)
video, it is very unlikely that this will happen in reality with IP
unicast.
While the rules for traffic management apply whether or not IP While the rules for traffic management apply whether IP multicast is
multicast is tunneled or not, the one feature that can make AMT tunneled or not, the one feature that can make AMT tunnels more
tunnels more difficult is the unpredictability of bandwidth difficult is the unpredictability of bandwidth requirements across
requirements across underlying links because of the way they can be underlying links because of the way they can be used: with native IP
used: With native IP multicast or GRE tunnels, the amount of multicast or GRE tunnels, the amount of bandwidth depends on the
bandwidth depends on the amount of content, not the number of EUs - amount of content -- not the number of EUs -- and is therefore easier
and is therefore easier to plan for. AMT tunnels terminating in EU/G to plan for. AMT tunnels terminating in the EU/G, on the other hand,
on the other hand scale with the number of EUs. In the vicinity of scale with the number of EUs. In the vicinity of the AMT relay, they
the AMT relay they can introduce very large amount of replicated can introduce a very large amount of replicated traffic, and it is
traffic and it is not always feasible to provision enough bandwidth not always feasible to provision enough bandwidth for all possible
for all possible EU to get the highest quality for all their content EUs to get the highest quality for all their content during peak
during peak utilization in such setups - unless the AMT relays are utilization in such setups -- unless the AMT relays are very close to
very close to the EU edge. Therefore it is also recommended to use the EU edge. Therefore, it is also recommended that IP multicast
IP multicast rate adaptation even inside controlled networks when rate adaptation be used, even inside controlled networks, when using
using AMT tunnels directly to EU/G. AMT tunnels directly to the EU/G.
Note that rate-adaptive IP multicast traffic in general does not mean Note that rate-adaptive IP multicast traffic in general does not mean
that the sender is reducing the bitrate, but rather that the EUs that that the sender is reducing the bitrate but rather that the EUs that
experience congestion are joining to a lower bitrate (S,G) stream of experience congestion are joining to a lower-bitrate (S,G) stream of
the content, similar to adaptive bitrate streaming over TCP. the content, similar to ABR streaming over TCP. Therefore, migration
Migration from non rate-adaptive to rate adaptive bitrate in IP from a non-rate-adaptive bitrate to a rate-adaptive bitrate in IP
multicast does therefore also change the dynamic (S,G) join behavior multicast will also change the dynamic (S,G) join behavior in the
in the network resulting in potentially higher performance network, resulting in potentially higher performance requirements for
requirement for IP multicast protocols (IGMP/PIM), especially on the IP multicast protocols (IGMP/PIM), especially on the last hops where
last hops where dynamic changes occur (including AMT gateway/relays): dynamic changes occur (including AMT gateways/relays): in non-rate-
In non rate-adaptive IP multicast, only "channel change" causes state adaptive IP multicast, only "channel change" causes state change, but
change, in rate-adaptive also the congestion situation causes state in rate-adaptive multicast, congestion also causes state change.
change.
Even though not fully specified in this document, peerings that rely Even though not fully specified in this document, peerings that rely
on GRE/AMT tunnels may be across one or more transit ADs instead of on GRE/AMT tunnels may be across one or more transit ADs instead of
an exclusive (non-shared, L1/L2) path. Unless those transit ADs are an exclusive (non-shared, L1/L2) path. Unless those transit ADs are
explicitly contracted to provide other than "best effort" transit for explicitly contracted to provide other than "best effort" transit for
the tunneled traffic, the IP multicast traffic tunneled must be rate the tunneled traffic, the tunneled IP multicast traffic must be
adaptive to not violate BCP41 across those transit ADs. rate adaptive in order to not violate BCP 41 across those
transit ADs.
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 EU receives the multicast stream from the "most optimal" source
source [INF_ATIS_10] which typically: [INF_ATIS_10], which typically:
o Maximizes the multicast portion of the transport and minimizes any o Maximizes the multicast portion of the transport and minimizes any
unicast portion of the delivery, and unicast portion of the delivery, and
o Minimizes the overall combined network(s) route distance. o Minimizes the overall combined route distance of the network(s).
This routing objective applies to both Native and AMT; the actual This routing objective applies to both native multicast and AMT; the
methodology of the solution will be different for each. Regardless, actual methodology of the solution will be different for each.
the routing solution is expected: Regardless, the routing solution is expected to:
o To be scalable, o Be scalable,
o To avoid or minimize new protocol development or modifications, o Avoid or minimize new protocol development or modifications, and
and
o To be robust enough to achieve high reliability and automatically o Be robust enough to achieve high reliability and to automatically
adjust to changes and problems in the multicast infrastructure. adjust to changes and problems in the multicast infrastructure.
For both Native and AMT environments, having a source as close as For both native and AMT environments, having a source as close as
possible to the EU network is most desirable; therefore, in some possible to the EU network is most desirable; therefore, in some
cases, an AD may prefer to have multiple sources near different cases, an AD may prefer to have multiple sources near different
peering points. However, that is entirely an implementation issue. peering points. However, that is entirely an implementation issue.
4.2.1. Native Multicast Routing Aspects 4.2.1. Native Multicast Routing Aspects
Native multicast simply requires that the Administrative Domains Native multicast simply requires that the administrative domains
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., BRs). An example of
example of multicast delivery via a Native Multicast process across multicast delivery via a native multicast process across two
two Administrative Domains is as follows assuming that the 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 information is in the subscriber to AD-2 (see Use Case 3.1). This information is in the
form of metadata and it contains instructions directing the EU form of metadata, and it contains instructions directing the EU
client to launch an appropriate application if necessary, as well client to launch an appropriate application if necessary, as well
as additional information for the application about the source as 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 (S,G) data.
data. The "S" portion provides the name or IP address of the The "S" portion provides the name or IP address of the source of
source of the multicast stream. The metadata may also contain the multicast stream. The metadata may also contain alternate
alternate delivery information such as specifying the unicast delivery information, such as specifying the unicast address of
address of the stream. 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 [RFC4604]. To facilitate this process, the two AD's need stream [RFC4604]. To facilitate this process, the two ADs need to
to do the following: do the following:
o Advertise the source id(s) over the Peering Points. * Advertise the source ID(s) over the peering points.
o Exchange relevant Peering Point information such as Capacity * Exchange such relevant peering point information as capacity
and Utilization. and utilization.
o Implement compatible multicast protocols to ensure proper * Implement compatible multicast protocols to ensure proper
multicast delivery across the peering points. multicast delivery across the peering points.
4.2.2. GRE Tunnel over Interconnecting Peering Point 4.2.2. GRE Tunnel over Interconnecting Peering Point
If the interconnecting peering point is not multicast enabled and If the interconnecting peering point is not multicast enabled and
both AD's are multicast enabled, then a simple solution is to both ADs are multicast enabled, then a simple solution is to
provision a GRE tunnel between the two AD's - see Use Case 3.2.2. provision a GRE tunnel between the two ADs; see Use Case 3.2
The termination points of the tunnel will usually be a network (Section 3.2). The termination points of the tunnel will usually be
engineering decision, but generally will be between the border a network engineering decision but generally will be between the BRs
routers or even between the AD 2 border router and the AD 1 source or even between the AD-2 BR and the AD-1 source (or source access
(or source access router). The GRE tunnel would allow end-to-end router). The GRE tunnel would allow end-to-end native multicast or
native multicast or AMT multicast to traverse the interface. AMT multicast to traverse the interface. Coordination and
Coordination and advertisement of the source IP is still required. advertisement of the source IP are still required.
The two AD's need to follow the same process as described in 4.2.1 to The two ADs need to follow the same process as the process described
facilitate multicast delivery across the Peering Points. in Section 4.2.1 to facilitate multicast delivery across the peering
points.
4.2.3. Routing Aspects with AMT Tunnels 4.2.3. Routing Aspects with AMT Tunnels
Unlike Native Multicast (with or without GRE), an AMT Multicast Unlike native multicast (with or without GRE), an AMT multicast
environment is more complex. It presents a dual layered problem environment is more complex. It presents a two-layered problem
because there are two criteria that should be simultaneously met: in that there are two criteria that should be simultaneously met:
o Find the closest AMT relay to the end-user that also has multicast o Find the closest AMT relay to the EU that also has multicast
connectivity to the content source, and 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 in the AMT specification:
AMT Relays: These serve the purpose of tunneling UDP multicast 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., endpoints). 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 packets gateways, encapsulating the multicast packets into unicast packets
and sending them over the tunnel toward the AMT Gateway. In and sending them over the tunnel toward the AMT gateways. In
addition, the AMT Relay may perform various usage and activity addition, the AMT relay may collect various usage and activity
statistics collection. This results in moving the replication statistics. This results in moving the replication point closer
point closer to the end user, and cuts down on traffic across the to the EU and cuts down on traffic across the network. Thus, the
network. Thus, the linear costs of adding unicast subscribers can linear costs of adding unicast subscribers can be avoided.
be avoided. However, unicast replication is still required for However, unicast replication is still required for each requesting
each requesting End-Point within the unicast-only network. endpoint within the unicast-only network.
AMT Gateway (GW): The Gateway will reside on an End-Point - this AMT gateway: The gateway will reside on an endpoint; this could be
could be any type of IP host such as a Personal Computer (PC), any type of IP host, such as a Personal Computer (PC), mobile
mobile phone, Set Top Box (STB) or appliances. The AMT Gateway phone, Set-Top Box (STB), or appliances. The AMT gateway receives
receives join and leave requests from the Application via an join and leave requests from the application via an Application
Application Programming Interface (API). In this manner, the Programming Interface (API). In this manner, the gateway allows
Gateway allows the End-Point to conduct itself as a true Multicast the endpoint to conduct itself as a true multicast endpoint. The
End-Point. The AMT Gateway will encapsulate AMT messages into UDP AMT gateway will encapsulate AMT messages into UDP packets and
packets and send them through a tunnel (across the unicast-only send them through a tunnel (across the unicast-only
infrastructure) to the AMT Relay. infrastructure) to the AMT relay.
The simplest AMT Use Case (section 3.3) involves peering points that The simplest AMT use case (Section 3.3) involves peering points that
are not multicast enabled between two multicast enabled AD's. An AMT are not multicast enabled between two multicast-enabled ADs. An
tunnel is deployed between an AMT Relay on the AD 1 side of the AMT tunnel is deployed between an AMT relay on the AD-1 side of the
peering point and an AMT Gateway on the AD 2 side of the peering peering point and an AMT gateway on the AD-2 side of the peering
point. One advantage to this arrangement is that the tunnel is point. One advantage of this arrangement is that the tunnel is
established on an as needed basis and need not be a provisioned established on an as-needed basis and need not be a provisioned
element. The two AD's can coordinate and advertise special AMT Relay element. The two ADs can coordinate and advertise special AMT relay
Anycast addresses with each other. Alternately, they may decide to anycast addresses with, and to, each other. Alternately, they may
simply provision Relay addresses, though this would not be an optimal decide to simply provision relay addresses, though this would not be
solution in terms of scalability. an optimal solution in terms of scalability.
Use Cases 3.4 and 3.5 describe more complicated AMT situations as Use Cases 3.4 and 3.5 describe AMT situations that are more
AD-2 is not multicast enabled. For these cases, the End User device complicated, as AD-2 is not multicast enabled in these two cases.
needs to be able to setup an AMT tunnel in the most optimal manner. For these cases, the EU device needs to be able to set up an AMT
There are many methods by which relay selection can be done including tunnel in the most optimal manner. There are many methods by which
the use of DNS based queries and static lookup tables [RFC7450]. The relay selection can be done, including the use of DNS-based queries
choice of the method is implementation dependent and is up to the and static lookup tables [RFC7450]. The choice of the method is
network operators. Comparison of various methods is out of scope for implementation dependent and is up to the network operators.
this document; it is for further study. Comparison of various methods is out of scope for this document and
is left for further study.
An illustrative example of a relay selection based on DNS queries and An illustrative example of a relay selection based on DNS queries as
Anycast IP addresses process for Use Cases 3.4 and 3.5 is described part of an anycast IP address process is described here for Use
here. Using an Anycast IP address for AMT Relays allows for all AMT Cases 3.4 and 3.5 (Sections 3.4 and 3.5). Using an anycast
Gateways to find the "closest" AMT Relay - the nearest edge of the IP address for AMT relays allows all AMT gateways to find the
multicast topology of the source. Note that this is strictly "closest" AMT relay -- the nearest edge of the multicast topology of
illustrative; the choice of the method is up to the network the source. Note that this is strictly illustrative; the choice of
operators. The basic process is as follows: the method is up to the network operators. The basic process is as
follows:
o Appropriate metadata is obtained by the EU client application. o Appropriate metadata is obtained by the EU client application.
The metadata contains instructions directing the EU client to an The metadata contains instructions directing the EU client to an
ordered list of particular destinations to seek the requested ordered list of particular destinations to seek the requested
stream and, for multicast, specifies the source location and the stream and, for multicast, specifies the source location and the
group (or stream) ID in the form of the "S,G" data. The "S" group (or stream) ID in the form of (S,G) data. The "S" portion
portion provides the URI (name or IP address) of the source of the provides the URI (name or IP address) of the source of the
multicast stream and the "G" identifies the particular stream multicast stream, and the "G" identifies the particular stream
originated by that source. The metadata may also contain originated by that source. The metadata may also contain
alternate delivery information such as the address of the unicast alternate delivery information such as the address of the unicast
form of the content to be used, for example, if the multicast form of the content to be used -- for example, if the multicast
stream becomes unavailable. stream becomes unavailable.
o Using the information from the metadata, and possibly information o Using the information from the metadata and, possibly, information
provisioned directly in the EU client, a DNS query is initiated in provisioned directly in the EU client, a DNS query is initiated in
order to connect the EU client/AMT Gateway to an AMT Relay. order to connect the EU client / AMT gateway to an AMT relay.
o Query results are obtained, and may return an Anycast address or a o Query results are obtained and may return an anycast address or a
specific unicast address of a relay. Multiple relays will specific unicast address of a relay. Multiple relays will
typically exist. The Anycast address is a routable "pseudo- typically exist. The anycast address is a routable
address" shared among the relays that can gain multicast access to "pseudo-address" shared among the relays that can gain multicast
the source. access to the source.
o If a specific IP address unique to a relay was not obtained, the o If a specific IP address unique to a relay was not obtained, the
AMT Gateway then sends a message (e.g., the discovery message) to AMT gateway then sends a message (e.g., the discovery message) to
the Anycast address such that the network is making the routing the anycast address such that the network is making the routing
choice of particular relay - e.g., closest relay to the EU. choice of a particular relay, e.g., the relay that is closest to
Details are outside the scope for this document. See [RFC4786]. the EU. Details are outside the scope of this document. See
[RFC4786].
o The contacted AMT Relay then returns its specific unicast IP o The contacted AMT relay then returns its specific unicast IP
address (after which the Anycast address is no longer required). address (after which the anycast address is no longer required).
Variations may exist as well. Variations may exist as well.
o The AMT Gateway uses that unicast IP address to initiate a three- o The AMT gateway uses that unicast IP address to initiate a
way handshake with the AMT Relay. three-way handshake with the AMT relay.
o AMT Gateway provides "S,G" to the AMT Relay (embedded in AMT o The AMT gateway provides the (S,G) information to the AMT relay
protocol messages). (embedded in AMT protocol messages).
o AMT Relay receives the "S,G" information and uses the S,G to join o The AMT relay receives the (S,G) information and uses it 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 The 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.
4.2.4. Public Peering Routing Aspects 4.2.4. Public Peering Routing Aspects
Figure 6 shows an example of a broadcast peering point.
AD-1a AD-1b AD-1a AD-1b
BR BR BR BR
| | | |
--+-+---------------+-+-- broadcast peering point LAN --+-+---------------+-+-- broadcast peering point LAN
| | | |
BR BR BR BR
AD-2a AD-2b AD-2a AD-2b
Figure 6: Broadcast Peering Point Figure 6: Broadcast Peering Point
A broadcast peering point is an L2 subnet connecting 3 or more ADs. A broadcast peering point is an L2 subnet connecting three or more
It is common in IXPs and usually consists of ethernet switch(es) ADs. It is common in IXPs and usually consists of Ethernet
operated by the IXP connecting to BRs operated by the ADs. switch(es) operated by the IXP connecting to BRs operated by the ADs.
In an example setup domain AD-2a peers with AD-1a and wants to In an example setup domain, AD-2a peers with AD-1a and wants to
receive IP multicast from it. Likewise AD-2b peers with AD-1b and receive IP multicast from it. Likewise, AD-2b peers with AD-1b and
wants to receive IP multicast from it. wants to receive IP multicast from it.
Assume one or more IP multicast (S,G) traffic streams can be served Assume that one or more IP multicast (S,G) traffic streams can be
by both AD-1a and AD-1b, for example because both AD-1a and AD-1b do served by both AD-1a and AD-1b -- for example, because both AD-1a and
contract this content from the same content source. AD-1b contact this content from the same content source.
In this case, AD-2a and AD-2b can not control anymore which upstream In this case, AD-2a and AD-2b can no longer control which upstream
domain, AD-1a or AD-1b will forward this (S,G) into the LAN. AD-2a domain -- AD-1a or AD-1b -- will forward this (S,G) into the LAN.
BR requests the (S,G) from AD-1a BR and AD-2b BR requests the same The AD-2a BR requests the (S,G) from the AD-1a BR, and the AD-2b BR
(S,G) from AD-1b BR. To avoid duplicate packets, an (S,G) can be requests the same (S,G) from the AD-1b BR. To avoid duplicate
forwarded by only one router onto the LAN, and PIM-SM/PIM-SSM detects packets, an (S,G) can be forwarded by only one router onto the LAN;
requests for duplicate transmission and resolve it via the so-called PIM-SM / PIM-SSM detects requests for duplicate transmissions and
"assert" protocol operation which results in only one BR forwarding resolves them via the so-called "assert" protocol operation, which
the traffic. Assume this is AD-1a BR. AD-2b will then receive the results in only one BR forwarding the traffic. Assume that this is
multicast traffic unexpectedly from a provider with whom it does not the AD-1a BR. AD-2b will then receive unexpected multicast traffic
have a mutual agreement for the traffic. Quality issues in EUs from a provider with whom it does not have a mutual agreement for
behind AD-2b caused by AD-1a will cause a lot of responsiblity and that traffic. Quality issues in EUs behind AD-2b caused by AD-1a
troubleshooting issues. will cause a lot of issues related to responsibility and
troubleshooting.
In face of this technical issues, we describe the following options In light of these technical issues, we describe, via the following
how IP multicast can be carried across broadcast peering point LANs: options, how IP multicast can be carried across broadcast peering
point LANs:
1. IP multicast is tunneled across the LAN. Any of the GRE/AMT 1. IP multicast is tunneled across the LAN. Any of the GRE/AMT
tunneling solutions mentioned in this document are applicable. tunneling solutions mentioned in this document are applicable.
This is the one case where specifically a GRE tunnel between the This is the one case where a GRE tunnel between the upstream BR
upstream BR (e.g.: AD-1a) and downstream BR (e.g.: AD-2a) is (e.g., AD-1a) and downstream BR (e.g., AD-2a) is specifically
recommended as opposed to tunneling across uBRs which are not the recommended, as opposed to tunneling across uBRs (which are not
actual BRs. the actual BRs).
2. The LAN has only one upstream AD that is sourcing IP multicast 2. The LAN has only one upstream AD that is sourcing IP multicast,
and native IP multicast is used. This is an efficient way to and native IP multicast is used. This is an efficient way to
distribute the same IP multicast content to multiple downstream distribute the same IP multicast content to multiple downstream
ADs. Misbehaving downstream BRs can still disrupt the delivery ADs. Misbehaving downstream BRs can still disrupt the delivery
of IP multicast from the upstream BR to other downstream BRs, of IP multicast from the upstream BR to other downstream BRs;
therefore strict rules must be follow to prohibit that case. The therefore, strict rules must be followed to prohibit such a case.
downstream BRs must ensure that they will always consider only The downstream BRs must ensure that they will always consider
the upstream BR as a source for multicast traffic: e.g.: no BGP only the upstream BR as a source for multicast traffic: e.g., no
SAFI-2 peerings between the downstream ADs across the peering BGP SAFI-2 peerings between the downstream ADs across the peering
point LAN, so that only the upstream BR is the only possible point LAN, so that the upstream BR is the only possible next hop
next-hop reachable across this LAN. And routing policies reachable across this LAN. Also, routing policies can be
configured to avoid fall back to the use of SAFI-1 (unicast) configured to avoid falling back to using SAFI-1 (unicast) routes
routes for IP multicast if unicast BGP peering is not limited in for IP multicast if unicast BGP peering is not limited in the
the same way. same way.
3. The LAN has multiple upstreams, but they are federated and agree 3. The LAN has multiple upstream ADs, but they are federated and
on a consistent policy for IP multicast traffic across the LAN. agree on a consistent policy for IP multicast traffic across the
One policy is that each possible source is only announced by one LAN. One policy is that each possible source is only announced
upstream BR. Another policy is that sources are redundantly by one upstream BR. Another policy is that sources are
announced (problematic case mentioned in above example), but the redundantly announced (the problematic case mentioned in the
upstream domains also provide mutual operational insight to help example in Figure 6 above), but the upstream domains also provide
troubleshooting (outside the scope of this document). mutual operational insight to help with troubleshooting (outside
the scope of this document).
4.3. Back Office Functions - Provisioning 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 AD's. 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
Resources for basic connectivity between AD's 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 AD's. 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 AD's 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
office connections (gateways, firewalls, etc) as appropriate. back-office connections (gateways, firewalls, etc.) as
appropriate.
o Routing protocols as needed, e.g. configuring routers to support
these.
Provisioning aspects related to Multicast-Based inter-domain delivery Provisioning aspects related to multicast-based inter-domain delivery
are as follows. are as follows.
The ability to receive requested application via multicast is The ability to receive a requested application via multicast is
triggered via receipt of the necessary metadata. Hence, this triggered via receipt of the necessary metadata. Hence, this
metadata must be provided to the EU regarding multicast URL - and metadata must be provided to the EU regarding the multicast URL --
unicast fallback if applicable. AD-2 must enable the delivery of and unicast fallback if applicable. AD-2 must enable the delivery of
this metadata to the EU and provision appropriate resources for this this metadata to the EU and provision appropriate resources for this
purpose. purpose.
Native multicast functionality is assumed to be available across many It is assumed that native multicast functionality is available across
ISP backbones, peering and access networks. If, however, native many ISP backbones, peering points, and access networks. If,
multicast is not an option (Use Cases 3.4 and 3.5), then: however, native 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 The EU must have a multicast client to use AMT multicast obtained
from Application Source (per agreement with AD-1) or from AD-1 or from either (1) the application source (per agreement with AD-1)
AD-2 (if delegated by the Application Source). or (2) AD-1 or AD-2 (if delegated by the application source).
o If provided by AD-1/AD-2, then the EU could be redirected to a o If provided by AD-1 or 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 that the proper
provided (assuming multiple possible clients). client is 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 and 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 gateway
locate the optimal AMT Relay (i.e. longest multicast path and to 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 as
stated as follows. follows.
Each AD provider is assumed to provision operations and customer care It is assumed that each AD provider will provision operations and
access to their own systems. customer care access to their own systems.
AD-1's operations and customer care functions must have visibility to AD-1's operations and customer care functions must be able to see
what is happening in AD-2's network or to the service provided by AD- enough of what is happening in AD-2's network or in the service
2, sufficient to verify their mutual goals and operations, e.g. to provided by AD-2 to verify their mutual goals and operations, e.g.,
know how the EU's are being served. This can be done in two ways: to know how the EUs are being served. This can be done in two ways:
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. operations and customer care continue using their own systems.
This requires coordination between the two AD's with appropriate This requires coordination between the two ADs, 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 direct
directly to AD-2's system. In this scenario, additional access to AD-2's systems. 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's access. The two ADs must agree on additional provisioning to
to support this option. support this option.
4.3.2. Interdomain Authentication Guidelines 4.3.2. Inter-domain Authentication Guidelines
All interactions between pairs of AD's can be discovered and/or be All interactions between pairs of ADs can be discovered and/or
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" (a logical facility
protected by credentials such as login passwords) for use by AD-1. generally protected by credentials such as login passwords) for
Multiple accounts and multiple types or partitions of accounts can use by AD-1. Multiple accounts, and multiple types or partitions
apply, e.g. customer accounts, security accounts, etc. of accounts, can apply, e.g., customer accounts, security
accounts.
The reason to specifically mention the need for AD-1 to initiate The reason to specifically mention the need for AD-1 to initiate
interactions with AD-2 (and use some account for that), as opposed to interactions with AD-2 (and use some account for that), as opposed to
the opposite direction is based on the recommended workflow initiated the opposite, is based on the recommended workflow initiated by
by customers (see Section 4.4): The customer contacts content source customers (see Section 4.4): the customer contacts the content
(part of AD-1), when AD-1 sees the need to propagate the issue, it source, which is part of AD-1. Consequently, if AD-1 sees the need
will interact with AD-2 using the aforementioned guidelines. to escalate the issue to AD-2, it will interact with AD-2 using the
aforementioned guidelines.
4.3.3. Log Management Guidelines 4.3.3. Log-Management Guidelines
Successful delivery (in terms of user experience) of applications or Successful delivery (in terms of user experience) of applications or
content via multicast between pairs of interconnecting AD's can be content via multicast between pairs of interconnecting ADs can be
improved through the ability to exchange appropriate logs for various improved through the ability to exchange appropriate logs for various
workflows - troubleshooting, accounting and billing, traffic and workflows -- troubleshooting, accounting and billing, optimization of
content transmission optimization, content and application traffic and content transmission, optimization of content and
development optimization and so on. application development, and so on.
The basic model as explained in before is that the content source and Specifically, AD-1 take over primary responsibility for customer
on its behalf AD-1 take over primary responsibility for customer experience on behalf of the content source, with support from AD-2 as
experience and the AD-2's support this. The application/content needed. The application/content owner is the only participant who
owner is the only participant who has and needs full insight into the has, and needs, full insight into the application level and can map
application level and can map the customer application experience to the customer application experience to the network traffic flows --
the network traffic flows - which it then with the help of AD-2 or which, with the help of AD-2 or logs from AD-2, it can then analyze
logs from AD-2 can analyze and interpret. and interpret.
The main difference between unicast delivery and multicast delivery The main difference between unicast delivery and multicast delivery
is that the content source can infer a lot more about downstream is that the content source can infer a lot more about downstream
network problems from a unicasted stream than from a multicasted network problems from a unicast stream than from a multicast stream:
stream: The multicasted stream is not per-EU except after the last the multicast stream is not per EU, except after the last
replication, which is in most cases not in AD-1. Logs from the replication, which is in most cases not in AD-1. Logs from the
application, including the receiver side at the EU, can provide application, including the receiver side at the EU, can provide
insight, but can not help to fully isolate network problems because insight but cannot help to fully isolate network problems because of
of the IP multicast per-application operational state built across the IP multicast per-application operational state built across AD-1
AD-1 and AD-2 (aka: the (S,G) state and any other feature operational and AD-2 (aka the (S,G) state and any other operational-state
state such as DiffServ QoS). features, such as Diffserv QoS).
See Section 7 for more discussions about the privacy considerations See Section 7 for more discussion regarding the privacy
of the model described here. considerations of the model described here.
Different type of logs are known to help support operations in AD-1 Different types of logs are known to help support operations in AD-1
when provided by AD-2. This could be done as part of AD-1/AD-2 when provided by AD-2. This could be done as part of AD-1/AD-2
contracts. Note that except for implied multicast specific elements, contracts. Note that except for implied multicast-specific elements,
the options listed here are not unique or novel for IP multicast, but the options listed here are not unique or novel for IP multicast, but
they are more important for services novel to the operators than for they are more important for services novel to the operators than for
operationally well established services (such as unicast). Therefore operationally well-established services (such as unicast). We
we detail them as follows: therefore detail them as follows:
o Usage information logs at aggregate level. o Usage information logs at an aggregate level.
o Usage failure instances at an aggregate level. o Usage failure instances at an aggregate level.
o Grouped or sequenced application access. performance, behavior o Grouped or sequenced application access: performance, behavior,
and failure at an aggregate level to support potential Application and failure at an aggregate level to support potential
Provider-driven strategies. Examples of aggregate levels include application-provider-driven strategies. Examples of aggregate
grouped video clips, web pages, and sets of software download. levels include grouped video clips, web pages, and software-
download sets.
o Security logs, aggregated or summarized according to agreement o Security logs, aggregated or summarized according to agreement
(with additional detail potentially provided during security (with additional detail potentially provided during security
events, by agreement). events, by agreement).
o Access logs (EU), when needed for troubleshooting. o Access logs (EU), when needed for troubleshooting.
o Application logs (what is the application doing), when needed for o Application logs ("What is the application doing?"), when needed
shared troubleshooting. for shared troubleshooting.
o Syslogs (network management), when needed for shared o Syslogs (network management), when needed for shared
troubleshooting. troubleshooting.
The two AD's 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 upon in 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 protection or response perspective: types and
types and counts of attacks detected, related source information, counts of attacks detected, related source information, related
related target information, etc. 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.4. Operations - Service Performance and Monitoring Guidelines 4.4. Operations - Service Performance and Monitoring Guidelines
Service Performance refers to monitoring metrics related to multicast "Service performance" refers to monitoring metrics related to
delivery via probes. The focus is on the service provided by AD-2 to multicast delivery via probes. The focus is on the service provided
AD-1 on behalf of all multicast application sources (metrics may be by AD-2 to AD-1 on behalf of all multicast application sources
specified for SLA use or otherwise). Associated guidelines are as (metrics may be specified for SLA use or otherwise). Associated
follows: guidelines are as follows:
o Both AD's are expected to monitor, collect, and analyze service o Both ADs are expected to monitor, collect, and analyze service
performance metrics for multicast applications. AD-2 provides performance metrics for multicast applications. AD-2 provides
relevant performance information to AD-1; this enables AD-1 to relevant performance information to AD-1; this enables AD-1 to
create an end-to-end performance view on behalf of the multicast create an end-to-end performance view on behalf of the multicast
application source. application source.
o Both AD's are expected to agree on the type of probes to be used o Both ADs are expected to agree on the types of probes to be used
to monitor multicast delivery performance. For example, AD-2 may to monitor multicast delivery performance. For example, AD-2 may
permit AD-1's probes to be utilized in the AD-2 multicast service 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 footprint. Alternately, AD-2 may deploy its own probes and relay
performance information back to AD-1. performance information back to AD-1.
Service Monitoring generally refers to a service (as a whole) "Service monitoring" generally refers to a service (as a whole)
provided on behalf of a particular multicast application source provided on behalf of a particular multicast application source
provider. It thus involves complaints from End Users when service provider. It thus involves complaints from EUs when service problems
problems occur. EUs direct their complaints to the source provider; occur. EUs direct their complaints to the source provider; the
in turn the source provider submits these complaints to AD-1. The source provider in turn submits these complaints to AD-1. The
responsibility for service delivery lies with AD-1; as such AD-1 will responsibility for service delivery lies with AD-1; as such, AD-1
need to determine where the service problem is occurring - its own will need to determine where the service problem is occurring -- in
network or in AD-2. It is expected that each AD will have tools to its own network or in AD-2. It is expected that each AD will have
monitor multicast service status in its own network. tools to monitor multicast service status in its own network.
o Both AD's will determine how best to deploy multicast service o Both ADs will determine how best to deploy multicast service
monitoring tools. Typically, each AD will deploy its own set of monitoring tools. Typically, each AD will deploy its own set of
monitoring tools; in which case, both AD's are expected to inform monitoring tools, in which case both ADs are expected to inform
each other when multicast delivery problems are detected. each other when multicast delivery problems are detected.
o AD-2 may experience some problems in its network. For example, 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 for the AMT use cases (Sections 3.3, 3.4, and 3.5), one or more
difficulties. AD-2 may be able to fix the problem by rerouting AMT relays may be experiencing difficulties. AD-2 may be able to
the multicast streams via alternate AMT Relays. If the fix is not fix the problem by rerouting the multicast streams via alternate
successful and multicast service delivery degrades, then AD-2 AMT relays. If the fix is not successful and multicast service
needs to report the issue to AD-1. delivery degrades, then AD-2 needs to report the issue to AD-1.
o When problem notification is received from a multicast application o When a problem notification is received from a multicast
source, AD-1 determines whether the cause of the problem is within application source, AD-1 determines whether the cause of the
its own network or within the AD-2 domain. If the cause is within problem is within its own network or within AD-2. If the cause is
the AD-2 domain, then AD-1 supplies all necessary information to within AD-2, then AD-1 supplies all necessary information to AD-2.
AD-2. Examples of supporting information include the following: Examples of supporting information include the following:
o Kind of problem(s). * Kind(s) of problem(s).
o Starting point & duration of problem(s). * Starting point and duration of problem(s).
o Conditions in which problem(s) occur. * Conditions in which one or more problems occur.
o IP address blocks of affected users. * IP address blocks of affected users.
o ISPs of affected users. * ISPs of affected users.
o Type of access e.g., mobile versus desktop. * Type of access, e.g., mobile versus desktop.
o Network locations of affected EUs. * Network locations of affected EUs.
o Both AD's conduct some form of root cause analysis for multicast o Both ADs conduct some form of root-cause analysis for multicast
service delivery problems. Examples of various factors for service delivery problems. Examples of various factors for
consideration include: consideration include:
o Verification that the service configuration matches the product * Verification that the service configuration matches the product
features. features.
o Correlation and consolidation of the various customer problems * Correlation and consolidation of the various customer problems
and resource troubles into a single root service problem. and resource troubles into a single root-service problem.
o Prioritization of currently open service problems, giving * Prioritization of currently open service problems, giving
consideration to problem impact, service level agreement, etc. consideration to problem impacts, SLAs, etc.
o Conduction of service tests, including one time tests or a * Conducting service tests, including tests performed once or a
series of tests over a period of time. series of tests over a period of time.
o Analysis of test results. * Analysis of test results.
o Analysis of relevant network fault or performance data. * Analysis of relevant network fault or performance data.
o Analysis of the problem information provided by the customer * Analysis of the problem information provided by the customer.
(CP).
o Once the cause of the problem has been determined and the problem 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 has been fixed, both ADs need to work jointly to verify and
validate the success of the fix. validate the success of the fix.
4.5. Client Reliability Models/Service Assurance Guidelines 4.5. Client Reliability Models / Service Assurance Guidelines
There are multiple options for instituting reliability architectures, There are multiple options for instituting reliability architectures.
most are at the application level. Both AD's should work those out Most are at the application level. Both ADs should work these
with their contract or agreement and with the multicast application options out per their contract or agreement and also with the
source providers. multicast application source providers.
Network reliability can also be enhanced by the two AD's by Network reliability can also be enhanced by the two ADs if they
provisioning alternate delivery mechanisms via unicast means. provision alternate delivery mechanisms via unicast means.
4.6. Application Accounting Guidelines 4.6. Application Accounting Guidelines
Application level accounting needs to be handled differently in the Application-level accounting needs to be handled differently in the
application than in IP unicast because the source side does not application than in IP unicast, because the source side does not
directly deliver packets to individual receivers. Instead, this directly deliver packets to individual receivers. Instead, this
needs to be signalled back by the receiver to the source. needs to be signaled back by the receiver to the source.
For network transport diagnostics, AD-1 and AD-2 should have For network transport diagnostics, AD-1 and AD-2 should have
mechanisms in place to ensure proper accounting for the volume of mechanisms in place to ensure proper accounting for the volume of
bytes delivered through the peering point and separately the number bytes delivered through the peering point and, separately, the number
of bytes delivered to EUs. of bytes delivered to EUs.
5. Troubleshooting and Diagnostics 5. Troubleshooting and Diagnostics
Any service provider supporting multicast delivery of content should Any service provider supporting multicast delivery of content should
have the capability to collect diagnostics as part of multicast be able to collect diagnostics as part of multicast troubleshooting
troubleshooting practices and resolve network issues accordingly. practices and resolve network issues accordingly. Issues may become
Issues may become apparent or identified either through network apparent or identifiable through either (1) network monitoring
monitoring functions or by customer reported problems as described in functions or (2) problems reported by customers, as described in
section 4.4. Section 4.4.
It is recommended that multicast diagnostics will be performed It is recommended that multicast diagnostics be performed, leveraging
leveraging established operational practices such as those documented established operational practices such as those documented in
in [MDH-04]. However, given that inter-domain multicast creates a [MDH-05]. However, given that inter-domain multicast creates a
significant interdependence of proper networking functionality significant interdependence of proper networking functionality
between providers there does exist a need for providers to be able to between providers, there exists a need for providers to be able to
signal (or otherwise alert) each other if there are any issues noted signal (or otherwise alert) each other if there are any issues noted
by either one. by either one.
Service providers may also wish to allow limited read-only For troubleshooting purposes, service providers may also wish to
administrative access to their routers to their AD peers for allow limited read-only administrative access to their routers to
troubleshooting. Of specific interest are access to active their AD peers. Access to active troubleshooting tools -- especially
troubleshooting tools especially [Traceroute] and [Traceroute] and the tools discussed in [Mtrace-v2] -- is of specific
[I-D.ietf-mboned-mtrace-v2]. interest.
Another option is to include this functionality into the IP multicast Another option is to include this functionality in the IP multicast
receiver application on the EU device and allow for these diagnostics receiver application on the EU device and allow these diagnostics to
to be remotely used by support operations. Note though that AMT does be remotely used by support operations. Note, though, that AMT
not allow to pass traceroute or mtrace requests, therefore does not allow the passing of traceroute or mtrace requests;
troubleshooting in the presence of AMT does not work as well end-to- therefore, troubleshooting in the presence of AMT does not work as
end as it can with native (or even GRE encapsulated) IP multicast, well end to end as it can with native (or even GRE-encapsulated) IP
especially wrt. to traceroute and mtrace. Instead, troubleshooting multicast, especially with regard to traceroute and mtrace. Instead,
directly on the actual network devices is then more likely necessary. troubleshooting directly on the actual network devices is then more
likely necessary.
The specifics of the notification and alerts are beyond the scope of The specifics of notifications 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. Some general communications issues are 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 ADs to
facilitate information sharing related to diagnostic facilitate information-sharing related to diagnostic
troubleshooting. troubleshooting.
o A default resolution period may be considered to resolve open o A default resolution period may be considered to resolve open
issues. Alternately, mutually acceptable resolution periods could issues. Alternately, mutually acceptable resolution periods could
be established depending on the severity of the identified be established, depending on the severity of the identified
trouble. trouble.
6. Security Considerations 6. Security Considerations
6.1. DoS attacks (against state and bandwidth) 6.1. DoS Attacks (against State and Bandwidth)
Reliable operations of IP multicast requires some basic protection Reliable IP multicast operations require some basic protection
against DoS (Denial of Service) attacks. against DoS (Denial of Service) attacks.
SSM IP multicast is self protecting against attacks from illicit SSM IP multicast is self-protecting against attacks from illicit
sources. Their traffic will not be forwarded beyond the first hop sources; such traffic will not be forwarded beyond the first-hop
router because that would require (S,G) memership reports from router, because that would require (S,G) membership reports from the
receiver. Traffic from sources will only be forwarded from the valid receiver. Only valid traffic from sources will be forwarded, because
source because RPF ("Reverse Path Forwarding") is part of the RPF ("Reverse Path Forwarding") is part of the protocols. One can
protocols. One can say that [BCP38] style protection against spoofed say that protection against spoofed source traffic performed in the
source traffic is therefore built into PIM-SM/PIM-SSM. style of [BCP38] is therefore built into PIM-SM / PIM-SSM.
Receivers can attack SSM IP multicast by originating such (S,G) Receivers can attack SSM IP multicast by originating such (S,G)
membership reports. This can result in a DoS attack against state membership reports. This can result in a DoS attack against state
through the creation of a large number of (S,G) states that create through the creation of a large number of (S,G) states that create
high control plane load or even inhibit later creation of valid high control-plane load or even inhibit the later creation of a valid
(S,G). In conjunction with collaborating illicit sources it can also (S,G). In conjunction with collaborating illicit sources, it can
result in illicit sources traffic being forwarded. also result in the forwarding of traffic from illicit sources.
Today, these type of attacks are usually mitigated by explicitly Today, these types of attacks are usually mitigated by explicitly
defining the set of permissible (S,G) on e.g.: the last hop routers defining the set of permissible (S,G) on, for example, the last-hop
in replicating IP multicast to EUs; For example via (S,G) Access routers in replicating IP multicast to EUs (e.g., via (S,G) access
Control Lists applied to IGMP/MLD membership state creation. Each AD control lists applied to IGMP/MLD membership state creation). Each
is expected to prohibit (S,G) state creation for invalid sources AD (say, "ADi") is expected to know what sources located in ADi are
inside their own AD. permitted to send and what their valid (S,G)s are. ADi can therefore
also filter invalid (S,G)s for any "S" located inside ADi, but not
sources located in another AD.
In the peering case, AD-2 is without further information not aware of In the peering case, without further information, AD-2 is not aware
the set of valid (S,G) from AD-1, so this set needs to be of the set of valid (S,G) from AD-1, so this set needs to be
communicated via operational procedures from AD-1 to AD-2 to provide communicated via operational procedures from AD-1 to AD-2 to provide
protection against this type of DoS attacks. Future work could protection against this type of DoS attack. Future work could signal
signal this information in an automated way: BGP extensions, DNS this information in an automated way: BGP extensions, DNS resource
Resource Records or backend automation between AD-1 and AD-2. records, or backend automation between AD-1 and AD-2. Backend
Backend automation is the short term most viable solution because it automation is, in the short term, the most viable solution: unlike
does not require router software extensions like the other two. BGP extensions or DNS resource records, backend automation does not
Observation of traffic flowing via (S,G) state could also be used to require router software extensions. Observation of traffic flowing
automate recognition of invalid (S,G) state created by receivers in via (S,G) state could also be used to automate the recognition of
the absence of explicit information from AD-1. invalid (S,G) state created by receivers in the absence of explicit
information from AD-1.
The second DoS attack through (S,G) membership reports is when The second type of DoS attack through (S,G) membership reports exists
receivers create too much valid (S,G) state to attack bandwidth when the attacking receiver creates too much valid (S,G) state and
available to other EU. Consider the uplink into a last-hop-router the traffic carried by these (S,G)s congests bandwidth on links
connecting to 100 EU. If one EU joins to more multicast content than shared with other EUs. Consider the uplink to a last-hop router
what fits into this link, then this would impact also the quality of connecting to 100 EUs. If one EU joins to more multicast content
the same content for the other 99 EU. If traffic is not rate than what fits into this link, then this would also impact the
adaptive, the effects are even worse. quality of the same content for the other 99 EUs. If traffic is not
rate adaptive, the effects are even worse.
The mitigation is the same as what is often employed for unicast: The mitigation technique is the same as what is often employed for
Policing of per-EU total amont of traffic. Unlike unicast though, unicast: policing of the per-EU total amount of traffic. Unlike
this can not be done anywhere along the path (e.g.: on an arbitrary unicast, though, this cannot be done anywhere along the path (e.g.,
bottleneck link), but it has to happen at the point of last on an arbitrary bottleneck link); it has to happen at the point of
replication to the different EU. Simple solutions such as limiting last replication to the different EU. Simple solutions such as
the maximum number of joined (S,G) per EU are readily available, limiting the maximum number of joined (S,G)s per EU are readily
solutions that consider bandwidth consumed exist as vendor specific available; solutions that take consumed bandwidth into account are
feature in routers. Note that this is primarily a non-peering issue available as vendor-specific features in routers. Note that this is
in AD-2, it only becomes a peering issue if the peering-link itself primarily a non-peering issue in AD-2; it only becomes a peering
is not big enough to carry all possible content from AD-1 or in case issue if the peering link itself is not big enough to carry all
3.4 where the AMT relay in AD-1 is that last replication point. possible content from AD-1 or, as in Use Case 3.4, when the AMT relay
in AD-1 is that last replication point.
Limiting the amount of (S,G) state per EU is also a good first Limiting the amount of (S,G) state per EU is also a good first
measure to prohibit too much undesired "empty" state to be built measure to prohibit too much undesired "empty" state from being built
(state not carrying traffic), but it would not suffice in case of (state not carrying traffic), but it would not suffice in the case of
DDoS attack - viruses that impact a large number of EU devices. DDoS attacks, e.g., viruses that impact a large number of EU devices.
6.2. Content Security 6.2. Content Security
Content confidentiality, DRM (Digital Restrictions Management), Content confidentiality, DRM (Digital Rights Management),
authentication and authorization are optional based on the content authentication, and authorization are optional, based on the content
delivered. For content that is "FTA" (Free To Air), the following delivered. For content that is "FTA" (Free To Air), the following
considerations can be ignored and content can be sent unencrypted and considerations can be ignored, and content can be sent unencrypted
without EU authentication and authorization. Note though that the and without EU authentication and authorization. Note, though, that
mechanisms described here may also be desireable by the application the mechanisms described here may also be desirable for the
source to better track users even if the content itself would not application source to better track users even if the content itself
require it. would not require it.
For interdomain content, there are at least two models for content For inter-domain content, there are at least two models for content
confidentiality, DRM and end-user authentication and authorization: confidentiality, including (1) DRM authentication and authorization
and (2) EU authentication and authorization:
In the classical (IP)TV model, responsibility is per-domain and o In the classical (IP)TV model, responsibility is per domain, and
content is and can be passed on unencrypted. AD-1 delivers content content is and can be passed on unencrypted. AD-1 delivers
to AD-2, AD-2 can further process the content including features like content to AD-2; AD-2 can further process the content, including
ad-insertion and AD-2 is the sole point of contact regarding the features like ad insertion, and AD-2 is the sole point of contact
contact for its EUs. In this document, we do not consider this case regarding the contact for its EUs. In this document, we do not
because it typically involves higher than network layer service consider this case because it typically involves service aspects
aspects operated by AD-2 and this document focusses on the network operated by AD-2 that are higher than the network layer; this
layer AD-1/AD-2 peering case, but not the application layer peering document focuses on the network-layer AD-1/AD-2 peering case but
case. Nevertheless, this model can be derived through additional not the application-layer peering case. Nevertheless, this model
work from what is describe here. can be derived through additional work beyond what is described
here.
The other case is the one in which content confidentiality, DRM, end- o The other model is the one in which content confidentiality, DRM,
user authentication and authorization are end-to-end: EU authentication, and EU authorization are end to end:
responsibilities of the multicast application source provider and responsibilities of the multicast application source provider and
receiver application. This is the model assumed here. It is also receiver application. This is the model assumed here. It is also
the model used in Internet OTT video delivery. We discuss the the model used in Internet "Over the Top" (OTT) video delivery.
threads incurred in this model due to the use of IP multicast in AD- Below, we discuss the threats incurred in this model due to the
1/AD-2 and across the peering. use of IP multicast in AD-1 or AD-2 and across the peering point.
End-to-end encryption enables end-to-end EU authentication and End-to-end encryption enables end-to-end EU authentication and
authorization: The EU may be able to IGMP/MLD join and receive the authorization: the EU may be able to join (via IGMP/MLD) and receive
content, but it can only decrypt it when it receives the decryption the content, but it can only decrypt it when it receives the
key from the content source in AD-1. The key is the authorization. decryption key from the content source in AD-1. The key is the
Keeping that key to itself and prohibiting playout of the decrypted authorization. Keeping that key to itself and prohibiting playout of
content to non-copy-protected interfaces are typical DRM features in the decrypted content to non-copy-protected interfaces are typical
that receiver application or EU device operating system. DRM features in that receiver application or EU device operating
system.
End-to-end ecnryption is continuously attacked. Keys may be subject End-to-end encryption is continuously attacked. Keys may be subject
to brute force attack so that content can be decrypted potentially to brute-force attacks so that content can potentially be decrypted
later, or keys are extracted from the EU application/device and later, or keys are extracted from the EU application/device and
shared with other unauthenticated receivers. One important class of shared with other unauthenticated receivers. One important class of
content is where the value is in live consumption, such as sports or content is where the value is in live consumption, such as sports or
other event (concert) streaming. Extraction of keying material from other event (e.g., concert) streaming. Extraction of keying material
compromised authenticated EU and sharing with unauthenticated EU is from compromised authenticated EUs and sharing with unauthenticated
not sufficient. It is also necessary for those unauthenticated EUs EUs are not sufficient. It is also necessary for those
to get a streaming copy of the content itself. In unicast streaming, unauthenticated EUs to get a streaming copy of the content itself.
they can not get such a copy from the content source (because they In unicast streaming, they cannot get such a copy from the content
can not authenticate) and because of asymmetric bandwidths, it is source (because they cannot authenticate), and, because of asymmetric
often impossible to get the content from compromised EUs to large bandwidths, it is often impossible to get the content from
number of unauthenticated EUs. EUs behind classical 16 Mbps down, 1 compromised EUs to a large number of unauthenticated EUs. EUs behind
Mbps up ADSL links are the best example. With increasing broadband classical "16 Mbps down, 1 Mbps up" ADSL links are the best example.
access speeds unicast peer-to-peer copying of content becomes easier, With increasing broadband access speeds, unicast peer-to-peer copying
but it likely will always be easily detectable by the ADs because of of content becomes easier, but it likely will always be easily
its traffic patterns and volume. detectable by the ADs because of its traffic patterns and volume.
When IP multicast is being used without additionals security, AD-2 is When IP multicast is being used without additional security, AD-2 is
not aware which EU is authenticated for which content. Any not aware of which EU is authenticated for which content. Any
unauthenticated EU in AD-2 could therefore get a copy of the unauthenticated EU in AD-2 could therefore get a copy of the
encrypted content without suspicion by AD-2 or AD-1 and either live- encrypted content without triggering suspicion on the part of AD-2 or
deode it in the presence of compromised authenticated EU and key AD-1 and then either (1) live-decode it, in the presence of the
sharing, or later decrypt it in the presence of federated brute force compromised authenticated EU and key-sharing or (2) decrypt it later,
key cracking. in the presence of federated brute-force key-cracking.
To mitigate this issue, the last replication point that is creating To mitigate this issue, the last replication point that is creating
(S,G) copies to EUs would need to permit those copies only after (S,G) copies to EUs would need to permit those copies only after
authentication of EUs. This would establish the same authenticated authentication of the EUs. This would establish the same
EU only copy deliver thast is used in unicast. authenticated "EU only" copy that is used in unicast.
Schemes for per EU IP multicast authentication/authorization (and in Schemes for per-EU IP multicast authentication/authorization (and, as
result non-delivery/copying of per-content IP multicast traffic) have a result, non-delivery or copying of per-content IP multicast
been built in the past and are deployed in service providers for traffic) have been built in the past and are deployed in service
intradomain IPTV services, but no standard exist for this. For providers for intra-domain IPTV services, but no standards exist for
example, there is no standardized radius attribute for authenticating this. For example, there is no standardized RADIUS attribute for
the IGMP/MLD filter set, but implementations of this exist. The authenticating the IGMP/MLD filter set, but such implementations
authors are specifically also not aware of schemes where the same exist. The authors of this document are specifically also not aware
authentication credentials used to get the encryption key from the of schemes where the same authentication credentials used to get the
content source could also be used to authenticate and authorize the encryption key from the content source could also be used to
network layer IP multicast replication for the content. Such schemes authenticate and authorize the network-layer IP multicast replication
are technically not difficult to build and would avoid creating and for the content. Such schemes are technically not difficult to build
maintaining a separate network forwarding authentication/ and would avoid creating and maintaining a separate network
authorization scheme decoupled from the end-to-end authentication/ traffic-forwarding authentication/authorization scheme decoupled from
authorization system of the application. the end-to-end authentication/authorization system of the
application.
If delivery of such high value content in conjunction with the If delivery of such high-value content in conjunction with the
peering described here is desired, the short term recommendations are peering described here is desired, the short-term recommendations are
for sources to clearly isolate the source and group addresses used for sources to clearly isolate the source and group addresses used
for different content bundles, communicate those (S,G) patterns from for different content bundles, communicate those (S,G) patterns from
AD-1 to the AD-2 and let AD-2 leverage existing per-EU AD-1 to AD-2, and let AD-2 leverage existing per-EU authentication/
authentication/ authorization mechanisms in network devices to authorization mechanisms in network devices to establish filters for
establish filters for (S,G) sets to each EU. (S,G) sets to each EU.
6.3. Peering Encryption 6.3. Peering Encryption
Encryption at peering points for multicast delivery may be used per Encryption at peering points for multicast delivery may be used per
agreement between AD-1/AD-2. agreement between AD-1 and AD-2.
In the case of a private peering link, IP multicast does not have In the case of a private peering link, IP multicast does not have
attack vectors on a peering link different from those of IP unicast, attack vectors on a peering link different from those of IP unicast,
but the content owner may have defined high bars against but the content owner may have defined strict constraints against
unauthenticated copying of even the end-to-end encrypted content, and unauthenticated copying of even the end-to-end encrypted content; in
in this case AD-1/AD-2 can agree on additional transport encryption this case, AD-1 and AD-2 can agree on additional transport encryption
across that peering link. In the case of a broadcast peering across that peering link. In the case of a broadcast peering
connection (e.g.: IXP), transport encryption is also the easiest way connection (e.g., IXP), transport encryption is again the easiest way
to prohibit unauthenticated copies by other ADs on the same peering to prohibit unauthenticated copies by other ADs on the same peering
point. point.
If peering is across a tunnel going across intermittent transit ADs If peering is across a tunnel that spans intermittent transit ADs
(not discused in detail in this document), then encryption of that (not discussed in detail in this document), then encryption of that
tunnel traffic is recommended. It not only prohibits possible tunnel traffic is recommended. It not only prohibits possible
"leakage" of content, but also to protects the the information what "leakage" of content but also protects the information regarding what
content is being consumed in AD-2 (aggregated privacy protection). content is being consumed in AD-2 (aggregated privacy protection).
See the following subsection for reasons why the peering point may See Section 6.4 for reasons why the peering point may also need to be
also need to be encrypted for operational reasons. encrypted for operational reasons.
6.4. Operational Aspects 6.4. Operational Aspects
Section 4.3.3 discusses exchange of log information, this section Section 4.3.3 discusses the exchange of log information, and
discussed exchange of (S,G) information and Section 7 discusses Section 7 discusses the exchange of program information. All these
exhange of program information. All these operational pieces of data operational pieces of data should by default be exchanged via
should by default be exchanged via authenticated and encrypted peer- authenticated and encrypted peer-to-peer communication protocols
to-peer communication protocols between AD-1 and AD-2 so that only between AD-1 and AD-2 so that only the intended recipients in the
the intended recipient in the peers AD have access to it. Even peers' AD have access to it. Even exposure of the least sensitive
exposure of the least sensitive information to third parties opens up information to third parties opens up attack vectors. Putting valid
attack vectors. Putting for example valid (S,G) information into DNS (S,G) information, for example, into DNS (as opposed to passing it
(as opposed to passing it via secured channels from AD-1 to AD-2) to via secured channels from AD-1 to AD-2) to allow easier filtering of
allow easier filtering of invalid (S,G) would also allow attackers to invalid (S,G) information would also allow attackers to more easily
easier identify valid (S,G) and change their attack vector. identify valid (S,G) information and change their attack vector.
From the perspective of the ADs, security is most critical for the From the perspective of the ADs, security is most critical for log
log information as it provides operational insight into the information, as it provides operational insight into the originating
originating AD, but it also contains sensitive user data: AD but also contains sensitive user data.
Sensitive user data exported from AD-2 to AD-1 as part of logs could Sensitive user data exported from AD-2 to AD-1 as part of logs could
be as much as the equivalent of 5-tuple unicast traffic flow be as much as the equivalent of 5-tuple unicast traffic flow
accounting (but not more, e.g.: no application level information). accounting (but not more, e.g., no application-level information).
As mentioned in Section 7, in unicast, AD-1 could capture these As mentioned in Section 7, in unicast, AD-1 could capture these
traffic statistics itself because this is all about AD-1 originated traffic statistics itself because this is all about traffic flows
traffic flows to EU receivers in AD-2, and operationally passing it (originated by AD-1) to EU receivers in AD-2, and operationally
from AD-2 to AD-1 may be necessary when IP multicast is used because passing it from AD-2 to AD-1 may be necessary when IP multicast is
of the replication happening in AD-2. used because of the replication taking place in AD-2.
Nevertheless, passing such traffic statistics inside AD-1 from a Nevertheless, passing such traffic statistics inside AD-1 from a
capturing router to a backend system is likely less subject to third capturing router to a backend system is likely less subject to
party attacks then passing it interdomain from AD-2 to AD-1, so more third-party attacks than passing it "inter-domain" from AD-2 to AD-1,
diligence needs to be applied to secure it. so more diligence needs to be applied to secure it.
If any protocols used for the operational information exchange are If any protocols used for the operational exchange of information are
not easily secured at transport layer or higher (because of the use not easily secured at the transport layer or higher (because of the
of legacy products or protocols in the network), then AD-1 and AD-2 use of legacy products or protocols in the network), then AD-1 and
can also consider to ensure that all operational data exchange goes AD-2 can also consider ensuring that all operational data exchanges
across the same peering point as the traffic and use network layer go across the same peering point as the traffic and use network-layer
encryption of the peering point as discussed in before to protect it. encryption of the peering point (as discussed previously) to
protect it.
End-to-end authentication and authorization of EU may involve some End-to-end authentication and authorization of EUs may involve some
kind of token authentication and is done at the application layer kind of token authentication and are done at the application layer,
independently of the two AD's. If there are problems related to independently of the two ADs. If there are problems related to the
failure of token authentication when end-users are supported by AD-2, failure of token authentication when EUs are supported by AD-2, then
then some means of validating proper working of the token some means of validating proper operation of the token authentication
authentication process (e.g., back-end servers querying the multicast process (e.g., validating that backend servers querying the multicast
application source provider's token authentication server are application source provider's token authentication server are
communicating properly) should be considered. Implementation details communicating properly) should be considered. Implementation details
are beyond the scope of this document. are beyond the scope of this document.
Security Breach Mitigation Plan - In the event of a security breach, In the event of a security breach, the two ADs are expected to have a
the two AD's are expected to have a mitigation plan for shutting down mitigation plan for shutting down the peering point and directing
the peering point and directing multicast traffic over alternative multicast traffic over alternative peering points. It is also
peering points. It is also expected that appropriate information expected that appropriate information will be shared for the purpose
will be shared for the purpose of securing the identified breach. of securing the identified breach.
7. Privacy Considerations 7. Privacy Considerations
The described flow of information about content and the end-user The described flow of information about content and EUs as described
described in this document aims to maintain privacy: in this document aims to maintain privacy:
AD-1 is operating on behalf (or owns) the content source and is AD-1 is operating on behalf of (or owns) the content source and is
therefore part of the content-consumption relationship with the end- therefore part of the content-consumption relationship with the EU.
user. The privacy considerations between the EU and AD-1 are The privacy considerations between the EU and AD-1 are therefore
therefore in general (exception see below) the same as if no IP generally the same (with one exception; see below) as they would be
multicast was used, especially because for any privacy conscious if no IP multicast was used, especially because end-to-end encryption
content, end-to-end encryption can and should be used. can and should be used for any privacy-conscious content.
Interdomain multicast transport service related information is Information related to inter-domain multicast transport service is
provided by the AD-2 operators to AD-1. AD-2 is not required to gain provided to AD-1 by the AD-2 operators. AD-2 is not required to gain
additional insight into the user behavior through this process that additional insight into the user's behavior through this process
it would not already have without the service collaboration with AD-1 other than what it would already have without service collaboration
- unless AD-1 and AD-2 agree on it and get approval from the EU. with AD-1, unless AD-1 and AD-2 agree on it and get approval from
the EU.
For example, if it is deemed beneficial for EU to directly get For example, if it is deemed beneficial for the EU to get support
support from AD-2 then it would in general be necessary for AD-2 to directly from AD-2, then it would generally be necessary for AD-2 to
be aware of the mapping between content and network (S,G) state so be aware of the mapping between content and network (S,G) state so
that AD-2 knows which (S,G) to troubleshoot when the EU complains that AD-2 knows which (S,G) to troubleshoot when the EU complains
about problems with a specific content. The degree to which this about problems with specific content. The degree to which this
dissemination is done by AD-1 explicitly to meet privacy expectations dissemination is done by AD-1 explicitly to meet privacy expectations
of EUs is typically easy to assess by AD-1. Two simple examples: of EUs is typically easy to assess by AD-1. Two simple examples are
as follows:
For a sports content bundle, every EU will happily click on the "i o For a sports content bundle, every EU will happily click on the
approve that the content program information is shared with your "I approve that the content program information is shared with
service provider" button, to ensure best service reliability because your service provider" button, to ensure best service reliability,
service conscious AD-2 would likely also try to ensure that high because service-conscious AD-2 would likely also try to ensure
value content, such as the (S,G) for SuperBowl like content would be that high-value content, such as the (S,G) for the Super Bowl,
the first to receive care in case of network issues. would be the first to receive care in the case of network issues.
If the content in question was one where the EU expected more o If the content in question was content for which the EU expected
privacy, the EU should prefer a content bundle that included this more privacy, the EU should prefer a content bundle that included
content in a large variety of other content, have all content end-to- this content in a large variety of other content, have all content
end encrypted and the programming information not be shared with AD-2 end-to-end encrypted, and not share programming information with
to maximize privacy. Nevertheless, the privacy of the EU against AD-2, to maximize privacy. Nevertheless, the privacy of the EU
AD-2 observing traffic would still be lower than in the equivalent against AD-2 observing traffic would still be lower than in the
setup using unicast, because in unicast, AD-2 could not correlate equivalent setup using unicast, because in unicast, AD-2 could not
which EUs are watching the same content and use that to deduce the correlate which EUs are watching the same content and use that to
content. Note that even the setup in Section 3.4 where AD-2 is not deduce the content. Note that even the setup in Section 3.4,
involved in IP multicast at all does not provide privacy against this where AD-2 is not involved in IP multicast at all, does not
level of analysis by AD-2 because there is no transport layer provide privacy against this level of analysis by AD-2, because
encryption in AMT and therefore AD-2 can correlate by onpath traffic there is no transport-layer encryption in AMT; therefore, AD-2 can
analysis who is consuming the same content from an AMT relay from correlate by on-path traffic analysis who is consuming the same
both the (S,G) join messages in AMT and the identical content content from an AMT relay from both the (S,G) join messages in AMT
segments (that where replicated at the AMT relay). and the identical content segments (that were replicated at the
AMT relay).
In summary: Because only content to be consumed by multiple EUs is In summary, because only content to be consumed by multiple EUs is
carried via IP multicast here, and all that content can be end-to-end carried via IP multicast here and all of that content can be
encrypted, the only IP multicast specific privacy consideration is end-to-end encrypted, the only privacy consideration specific to IP
for AD-2 to know or reconstruct what content an EU is consuming. For multicast is for AD-2 to know or reconstruct what content an EU is
content for which this is undesirable, some form of protections as consuming. For content for which this is undesirable, some form of
explained above are possible, but ideally, the model of Section 3.4 protections as explained above are possible, but ideally, the model
could be used in conjunction with future work adding e.g.: dTLS described in Section 3.4 could be used in conjunction with future
[RFC6347] encryption between AMT relay and EU. work, e.g., adding Datagram Transport Layer Security (DTLS)
encryption [RFC6347] between the AMT relay and the EU.
Note that IP multicast by nature would permit the EU privacy against Note that IP multicast by nature would permit the EU's privacy
the countent source operator because unlike unicast, the content against the content source operator because, unlike unicast, the
source does not natively know which EU is consuming which content: In content source does not natively know which EU is consuming which
all cases where AD-2 provides replication, only AD-2 does know this content: in all cases where AD-2 provides replication, only AD-2
directly. This document does not attempt to describe a model that knows this directly. This document does not attempt to describe a
does maintain such level of privacy against the content source but model that maintains such a level of privacy against the content
only against exposure to intermediate parties, in this case AD-2. source; rather, we describe a model that only protects against
exposure to intermediate parties -- in this case, AD-2.
8. IANA Considerations 8. IANA Considerations
No considerations identified in this document. This document does not require any IANA actions.
9. Acknowledgments
The authors would like to thank the following individuals for their
suggestions, comments, and corrections:
Mikael Abrahamsson
Hitoshi Asaeda
Dale Carder
Tim Chown
Leonard Giuliano
Jake Holland
Joel Jaeggli
Albert Manfredi
Stig Venaas
Henrik Levkowetz
10. Change log [RFC Editor: Please remove]
Please see discussion on mailing list for changes before -11.
-11: version in IESG review.
-12: XML'ified version of -11, committed solely to make rfcdiff
easier. XML versions hosted on https://www.github.com/toerless/
peering-bcp
-13:
o IESG feedback. Complete details in:
https://raw.githubusercontent.com/toerless/peering-bcp/master/11-
iesg-review-reply.txt
o Ben Campbell: Location information about EU (End User) is Network
Locatio information
o Ben Campbell: Added explanation of assumption to introduction that
traffic is sourced from AD-1 to (one or many) AD-2, mentioned that
sourcing from EU is out of scope.
o Introduction: moved up bullet points about exchanges and transit
to clean up flow of assumptions.
o Ben Campbell: Added picture for the GRE case, visualized tunnels
in all pictures.
o Ben Campbell: See 13-discus.txt on github for more details of
changes for this review.
o Alissia Cooper: Added more explanation for Log Management,
explained privacy context.
o Alissia Cooper: removed pre pre-RFC5378 disclaimer.
o Alissia Cooper: removed mentioning of potential mutual
compensation between domains if the other violates SLA.
o Mirja Kuehlewind: created section 4.1.1 to discuss congestion
control more detailled, adding reference to BCP145, removed stub
CC paragraphs from section 3.1 (principle applies to every section
3.x, and did not want to duplicate text between 3.x and 4.x).
o Mirja Kuehlewind: removed section 8 (conclusion). Text was not
very good, not important to hae conclusion, maybe bring back with
better text if strong interest.
o Introduced section about broadcast peering points because there
where too many places already where references to that case
existed (4.2.4).
o Introduced section about privact considerations because of comment
by Ben Campbell and Alissa Cooper.
o Rewrote security considerations and structured it into key
aspects: DoS attacks, content protection, peering point encryption
and operational aspects.
o Kathleen Moriarty: Added operational aspects to security section
(also for Alissia), e.g.: covering securing the exchange of
operational data between ADs.
o Spencer Dawkins: Various editorial fixes. Removed BCP38 text from
section 3, superceeded be explanation of PIM-SM RPF check to
provide equvialent security to BCP38 in security section 7.1).
o Eric Roscorla: (fixed from other reviews already).
o Adam Roach: Fixed up text about MDH-04, added reference to
RFC4786.
-13: Fix for Mirja's review on must for congestion control.
11. References 9. References
11.1. Normative References 9.1. Normative References
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
DOI 10.17487/RFC2784, March 2000, DOI 10.17487/RFC2784, March 2000,
<https://www.rfc-editor.org/info/rfc2784>. <https://www.rfc-editor.org/info/rfc2784>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol,
3", RFC 3376, DOI 10.17487/RFC3376, October 2002, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<https://www.rfc-editor.org/info/rfc3376>. <https://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener [RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810, Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004, DOI 10.17487/RFC3810, June 2004,
<https://www.rfc-editor.org/info/rfc3810>. <https://www.rfc-editor.org/info/rfc3810>.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007, DOI 10.17487/RFC4760, January 2007,
<https://www.rfc-editor.org/info/rfc4760>. <https://www.rfc-editor.org/info/rfc4760>.
[RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet
Group Management Protocol Version 3 (IGMPv3) and Multicast Group Management Protocol Version 3 (IGMPv3) and Multicast
Listener Discovery Protocol Version 2 (MLDv2) for Source- Listener Discovery Protocol Version 2 (MLDv2) for
Specific Multicast", RFC 4604, DOI 10.17487/RFC4604, Source-Specific Multicast", RFC 4604,
August 2006, <https://www.rfc-editor.org/info/rfc4604>. DOI 10.17487/RFC4604, August 2006,
<https://www.rfc-editor.org/info/rfc4604>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
DOI 10.17487/RFC4609, October 2006, DOI 10.17487/RFC4609, October 2006,
<https://www.rfc-editor.org/info/rfc4609>. <https://www.rfc-editor.org/info/rfc4609>.
[RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450, [RFC7450] Bumgardner, G., "Automatic Multicast Tunneling", RFC 7450,
DOI 10.17487/RFC7450, February 2015, DOI 10.17487/RFC7450, February 2015,
<https://www.rfc-editor.org/info/rfc7450>. <https://www.rfc-editor.org/info/rfc7450>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761,
2016, <https://www.rfc-editor.org/info/rfc7761>. March 2016, <https://www.rfc-editor.org/info/rfc7761>.
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: [BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, May 2000,
May 2000, <https://www.rfc-editor.org/info/rfc2827>. <https://www.rfc-editor.org/info/rfc2827>.
[BCP41] Floyd, S., "Congestion Control Principles", BCP 41, [BCP41] Floyd, S., "Congestion Control Principles", BCP 41,
RFC 2914, DOI 10.17487/RFC2914, September 2000, RFC 2914, September 2000,
<https://www.rfc-editor.org/info/rfc2914>. <https://www.rfc-editor.org/info/rfc2914>.
[BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage [BCP145] Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085, Guidelines", BCP 145, RFC 8085, March 2017,
March 2017, <https://www.rfc-editor.org/info/rfc8085>. <https://www.rfc-editor.org/info/rfc8085>.
11.2. Informative References 9.2. Informative References
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786, Services", BCP 126, RFC 4786, DOI 10.17487/RFC4786,
December 2006, <https://www.rfc-editor.org/info/rfc4786>. December 2006, <https://www.rfc-editor.org/info/rfc4786>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[INF_ATIS_10] [INF_ATIS_10]
"CDN Interconnection Use Cases and Requirements in a "CDN Interconnection Use Cases and Requirements in a
Multi-Party Federation Environment", ATIS Standard Multi-Party Federation Environment", ATIS Standard
A-0200010, December 2012. A-0200010, December 2012.
[MDH-04] Thaler, D. and others, "Multicast Debugging Handbook", [MDH-05] Thaler, D. and B. Aboba, "Multicast Debugging Handbook",
IETF I-D draft-ietf-mboned-mdh-04.txt, May 2000. Work in Progress, draft-ietf-mboned-mdh-05, November 2000.
[Traceroute] [Traceroute]
, <http://traceroute.org/#source%20code>. "traceroute.org", <http://traceroute.org/#source%20code>.
[I-D.ietf-mboned-mtrace-v2] [Mtrace-v2]
Asaeda, H., Meyer, K., and W. Lee, "Mtrace Version 2: Asaeda, H., Meyer, K., and W. Lee, Ed., "Mtrace Version 2:
Traceroute Facility for IP Multicast", draft-ietf-mboned- Traceroute Facility for IP Multicast", Work in Progress,
mtrace-v2-20 (work in progress), October 2017. draft-ietf-mboned-mtrace-v2-22, December 2017.
Acknowledgments
The authors would like to thank the following individuals for their
suggestions, comments, and corrections:
Mikael Abrahamsson
Hitoshi Asaeda
Dale Carder
Tim Chown
Leonard Giuliano
Jake Holland
Joel Jaeggli
Henrik Levkowetz
Albert Manfredi
Stig Venaas
Authors' Addresses Authors' Addresses
Percy S. Tarapore (editor) Percy S. Tarapore (editor)
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
skipping to change at page 41, line 33 skipping to change at page 44, line 25
Phone: 1-732-420-3292 Phone: 1-732-420-3292
Email: rs1983@att.com Email: rs1983@att.com
Greg Shepherd Greg Shepherd
Cisco Cisco
Email: shep@cisco.com Email: shep@cisco.com
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Huawei USA - Futurewei Technologies Inc.
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de, toerless.eckert@huawei.com
Ram Krishnan Ram Krishnan
SupportVectors SupportVectors
Email: ramkri123@gmail.com Email: ramkri123@gmail.com
 End of changes. 334 change blocks. 
1122 lines changed or deleted 1062 lines changed or added

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