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