draft-ietf-mboned-interdomain-peering-bcp-06.txt | draft-ietf-mboned-interdomain-peering-bcp-07.txt | |||
---|---|---|---|---|
MBONED Working Group Percy S. Tarapore | MBONED Working Group Percy S. Tarapore | |||
Internet Draft Robert Sayko | Internet Draft Robert Sayko | |||
Intended status: BCP AT&T | Intended status: BCP AT&T | |||
Expires: May 15, 2017 Greg Shepherd | Expires: August 1, 2017 Greg Shepherd | |||
Toerless Eckert | Toerless Eckert | |||
Cisco | Cisco | |||
Ram Krishnan | Ram Krishnan | |||
Brocade | Brocade | |||
November 15, 2016 | February 1, 2017 | |||
Use of Multicast Across Inter-Domain Peering Points | Use of Multicast Across Inter-Domain Peering Points | |||
draft-ietf-mboned-interdomain-peering-bcp-06.txt | draft-ietf-mboned-interdomain-peering-bcp-07.txt | |||
Status of this Memo | Status of this Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
months and may be updated, replaced, or obsoleted by other documents | months and may be updated, replaced, or obsoleted by other documents | |||
at any time. It is inappropriate to use Internet-Drafts as | at any time. It is inappropriate to use Internet-Drafts as | |||
reference material or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on May 15, 2017. | This Internet-Draft will expire on August 1, 2017. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2017 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with | carefully, as they describe your rights and restrictions with | |||
respect to this document. Code Components extracted from this | respect to this document. Code Components extracted from this | |||
document must include Simplified BSD License text as described in | document must include Simplified BSD License text as described in | |||
Section 4.e of the Trust Legal Provisions and are provided without | Section 4.e of the Trust Legal Provisions and are provided without | |||
warranty as described in the Simplified BSD License. | warranty as described in the Simplified BSD License. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
This document may contain material from IETF Documents or IETF | This document may contain material from IETF Documents or IETF | |||
Contributions published or made publicly available before November | Contributions published or made publicly available before November | |||
10, 2008. The person(s) controlling the copyright in some of this | 10, 2008. The person(s) controlling the copyright in some of this | |||
material may not have granted the IETF Trust the right to allow | material may not have granted the IETF Trust the right to allow | |||
modifications of such material outside the IETF Standards Process. | modifications of such material outside the IETF Standards Process. | |||
Without obtaining an adequate license from the person(s) controlling | Without obtaining an adequate license from the person(s) controlling | |||
the copyright in such materials, this document may not be modified | the copyright in such materials, this document may not be modified | |||
outside the IETF Standards Process, and derivative works of it may | outside the IETF Standards Process, and derivative works of it may | |||
not be created outside the IETF Standards Process, except to format | not be created outside the IETF Standards Process, except to format | |||
skipping to change at page 2, line 48 ¶ | skipping to change at page 2, line 48 ¶ | |||
Enabled.......................................................10 | Enabled.......................................................10 | |||
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through | 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through | |||
AD-2..........................................................12 | AD-2..........................................................12 | |||
4. Supporting Functionality......................................14 | 4. Supporting Functionality......................................14 | |||
4.1. Network Interconnection Transport and Security Guidelines15 | 4.1. Network Interconnection Transport and Security Guidelines15 | |||
4.2. Routing Aspects and Related Guidelines...................15 | 4.2. Routing Aspects and Related Guidelines...................15 | |||
4.2.1 Native Multicast Routing Aspects..................16 | 4.2.1 Native Multicast Routing Aspects..................16 | |||
4.2.2 GRE Tunnel over Interconnecting Peering Point.....17 | 4.2.2 GRE Tunnel over Interconnecting Peering Point.....17 | |||
4.2.3 Routing Aspects with AMT Tunnels.....................17 | 4.2.3 Routing Aspects with AMT Tunnels.....................17 | |||
4.3. Back Office Functions - Provisioning and Logging Guidelines | 4.3. Back Office Functions - Provisioning and Logging Guidelines | |||
..............................................................19 | ..............................................................20 | |||
4.3.1 Provisioning Guidelines...........................20 | 4.3.1 Provisioning Guidelines...........................20 | |||
4.3.2 Application Accounting Guidelines.................21 | 4.3.2 Application Accounting Guidelines.................21 | |||
4.3.3 Log Management Guidelines.........................22 | 4.3.3 Log Management Guidelines.........................22 | |||
4.4. Operations - Service Performance and Monitoring Guidelines22 | 4.4. Operations - Service Performance and Monitoring Guidelines22 | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
4.5. Client Reliability Models/Service Assurance Guidelines...25 | 4.5. Client Reliability Models/Service Assurance Guidelines...25 | |||
5. Troubleshooting and Diagnostics...............................25 | 5. Troubleshooting and Diagnostics...............................25 | |||
6. Security Considerations.......................................26 | 6. Security Considerations.......................................26 | |||
7. IANA Considerations...........................................27 | 7. IANA Considerations...........................................27 | |||
8. Conclusions...................................................27 | 8. Conclusions...................................................27 | |||
9. References....................................................27 | 9. References....................................................27 | |||
9.1. Normative References.....................................27 | 9.1. Normative References.....................................27 | |||
9.2. Informative References...................................28 | 9.2. Informative References...................................28 | |||
10. Acknowledgments..............................................29 | 10. Acknowledgments..............................................29 | |||
1. Introduction | 1. Introduction | |||
Several types of applications (e.g., live video streaming, software | Content and data from several types of applications (e.g., live | |||
downloads) are well suited for delivery via multicast means. The use | video streaming, software downloads) are well suited for delivery | |||
of multicast for delivering such applications offers significant | via multicast means. The use of multicast for delivering such | |||
savings for utilization of resources in any given administrative | content/data offers significant savings for utilization of resources | |||
domain. End user demand for such applications is growing. Often, | in any given administrative domain. End user demand for such | |||
this requires transporting such applications across administrative | content/data is growing. Often, this requires transporting the | |||
domains via inter-domain peering points. | content/data across administrative domains via inter-domain peering | |||
points. | ||||
The objective of this Best Current Practices document is twofold: | The objective of this Best Current Practices document is twofold: | |||
o Describe the technical process and establish guidelines for | o Describe the technical process and establish guidelines for | |||
setting up multicast-based delivery of applications across inter- | setting up multicast-based delivery of application content/data | |||
domain peering points via a set of use cases. | across inter-domain peering points via a set of use cases. | |||
o Catalog all required information exchange between the | o Catalog all required information exchange 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 stated as follows: | The scope and assumptions for this document are stated as follows: | |||
o For the purpose of this document, the term "peering point" | o For the purpose of this document, the term "peering point" | |||
refers to an interface between two networks/administrative | refers to an interface between two networks/administrative | |||
domains over which traffic is exchanged between them. A | domains over which traffic is exchanged between them. A | |||
Network-Network Interface (NNI) is an example of a peering | Network-Network Interface (NNI) is an example of a peering | |||
point. | point. | |||
o Administrative Domain 1 (AD-1) is enabled with native | o Administrative Domain 1 (AD-1) is enabled with native | |||
multicast. A peering point exists between AD-1 and AD-2. | multicast. A peering point exists 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 [RFC4609], Protocol Independent | purpose including PIM-SM [RFC4609], Protocol Independent | |||
Multicast - Source Specific Multicast (PIM-SSM) [RFC7761], | Multicast - Source Specific Multicast (PIM-SSM) [RFC7761], | |||
Internet Group Management Protocol (IGMP) [RFC3376], and | Internet Group Management Protocol (IGMP) [RFC3376], and | |||
Multicast Listener Discovery (MLD) [RFC3810]. | Multicast Listener Discovery (MLD) [RFC3810]. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
o As described in Section 2, the source IP address of the | o As described in Section 2, the source IP address of the | |||
multicast stream in the originating AD (AD-1) is known. Under | multicast stream in the originating AD (AD-1) is known. Under | |||
this condition, PIM-SSM use is beneficial as it allows the | this condition, PIM-SSM use is beneficial as it allows the | |||
receiver's upstream router to directly send a JOIN message to | receiver's upstream router to directly send a JOIN message to | |||
the source without the need of invoking an intermediate | the source without the need of invoking an intermediate | |||
Rendezvous Point (RP). Use of SSM also presents an improved | Rendezvous Point (RP). Use of SSM also presents an improved | |||
threat mitigation profile against attack, as described in | threat mitigation profile against attack, as described in | |||
[RFC4609]. Hence, in the case of inter-domain peering, it is | [RFC4609]. Hence, in the case of inter-domain peering, it is | |||
recommended to use only SSM protocols; the setup of inter- | recommended to use only SSM protocols; the setup of inter- | |||
skipping to change at page 5, line 5 ¶ | skipping to change at page 5, line 5 ¶ | |||
between many operators, is not in scope for this document. | between many operators, is not in scope for this document. | |||
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: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
o Two independent administrative domains are interconnected via a | o Two independent administrative domains are interconnected via a | |||
peering point. | peering point. | |||
o The peering point is either multicast enabled (end-to-end | o The peering point is either multicast enabled (end-to-end | |||
native multicast across the two domains) or it is connected by | native multicast across the two domains) or it is connected by | |||
one of two possible tunnel types: | one of two possible tunnel types: | |||
o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] | o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] | |||
allowing multicast tunneling across the peering point, or | allowing multicast tunneling across the peering point, or | |||
o An Automatic Multicast Tunnel (AMT) [RFC7450]. | o An Automatic Multicast Tunnel (AMT) [RFC7450]. | |||
o The application stream originates at a source in Domain 1. The | o A service provider controls one or more application sources in | |||
source IP address is known. | AD-1 which will send multicast IP packets for one or more | |||
o An End User associated with Domain 2 requests the application. | (S,G)s. It is assumed that the service being provided is | |||
It is assumed that the application is suitable for delivery via | suitable for delivery via multicast (e.g. live video streaming | |||
multicast means (e.g., live steaming of major events, software | of popular events, software downloads to many devices, etc.), | |||
downloads to large numbers of end user devices, etc.) | and that the packet streams will be part of a suitable | |||
o The request is communicated to the application source which | multicast transport protocol. | |||
provides the relevant multicast delivery information to the EU | o An End User (EU) controls a device connected to AD-2, which | |||
device. This information is in the form of appropriate | runs an application client compatible with the service | |||
metadata. At a minimum, this metadata includes the {Source, | provider's application source. | |||
Group} or (S,G) information relevant to the multicast stream. | o The application client joins appropriate (S,G)s in order to | |||
It may also contain additional information that the application | receive the data necessary to provide the service to the EU. | |||
client can use to locate the source and join the stream. The | The mechanisms by which the application client learns the | |||
delivery method by which the source transmits this information | appropriate (S,G)s are an implementation detail of the | |||
is determined via arrangements between the source and the two | application, and are out of scope for this document. | |||
Administrative Domains. The description of the delivery method | ||||
and the format of the metadata is out of scope for this | ||||
document. | ||||
o The application client in the EU device then joins the | ||||
multicast stream distributed by the application source in | ||||
domain 1 utilizing the (S,G) information provided in the | ||||
manifest file. | ||||
Note that domain 2 may be an independent network domain (e.g., Tier | Note that domain 2 may be an independent network domain (e.g., Tier | |||
1 network operator domain) or it could also be an Enterprise network | 1 network operator domain) or it could also be an Enterprise network | |||
operated by a single customer. The peering point architecture and | operated by a single customer. The peering point architecture and | |||
requirements may have some unique aspects associated with the | requirements may have some unique aspects associated with the | |||
Enterprise case. | Enterprise case. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
The Use Cases describing various architectural configurations for | The Use Cases describing various architectural configurations for | |||
the multicast distribution along with associated requirements is | the multicast distribution along with associated requirements is | |||
described in section 3. Unique aspects related to the Enterprise | described in section 3. Unique aspects related to the Enterprise | |||
network possibility will be described in this section. A | network possibility will be described in this section. A | |||
comprehensive list of pertinent information that needs to be | comprehensive list of pertinent information that needs to be | |||
exchanged between the two domains to support various functions | exchanged between the two domains to support various functions | |||
enabling the application transport is provided in section 4. | enabling the application transport is provided in section 4. | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
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 is enabled to support such a process. | |||
There are five possible Use Cases for consideration. | There are five Use Cases for consideration in this document. | |||
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 | administrative domains and the peering point is also native | |||
multicast enabled - Figure 1. | multicast enabled - Figure 1. | |||
------------------- ------------------- | ------------------- ------------------- | |||
/ AD-1 \ / AD-2 \ | / AD-1 \ / AD-2 \ | |||
/ (Multicast Enabled) \ / (Multicast Enabled) \ | / (Multicast Enabled) \ / (Multicast Enabled) \ | |||
skipping to change at page 7, line 5 ¶ | skipping to change at page 6, line 42 ¶ | |||
AD = Administrative Domain (Independent Autonomous System) | AD = Administrative Domain (Independent Autonomous System) | |||
AS = Application (e.g., Content) Multicast Source | AS = Application (e.g., Content) Multicast Source | |||
BR = Border Router | BR = Border Router | |||
I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) | I1 = AD-1 and AD-2 Multicast Interconnection (e.g., MBGP) | |||
I2 = AD-2 and EU Multicast Connection | I2 = AD-2 and EU Multicast Connection | |||
Figure 1 - Content Distribution via End to End Native Multicast | Figure 1 - Content Distribution via End to End Native Multicast | |||
Advantages of this configuration are: | Advantages of this configuration are: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
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 unicast transmissions. | compared to unicast transmissions. | |||
From the perspective of AD-1, the one disadvantage associated with | From the perspective of AD-1, the one disadvantage associated with | |||
native multicast into AD-2 instead of individual unicast to every EU | native multicast into AD-2 instead of individual unicast to every EU | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
in AD-2 is that it does not have the ability to count the number of | in AD-2 is that it does not have the ability to count the number of | |||
End Users as well as the transmitted bytes delivered to them. This | End Users as well as the transmitted bytes delivered to them. This | |||
information is relevant from the perspective of customer billing and | information is relevant from the perspective of customer billing and | |||
operational logs. It is assumed that such data will be collected by | operational logs. It is assumed that such data will be collected by | |||
the application layer. The application layer mechanisms for | the application layer. The application layer mechanisms for | |||
generating this information need to be robust enough such that all | generating this information need to be robust enough such that all | |||
pertinent requirements for the source provider and the AD operator | pertinent requirements for the source provider and the AD operator | |||
are satisfactorily met. The specifics of these methods are beyond | are satisfactorily met. The specifics of these methods are beyond | |||
the scope of this document. | the scope of this document. | |||
skipping to change at page 8, line 4 ¶ | skipping to change at page 7, line 44 ¶ | |||
to AD-2 only if such delivery has been accepted by contract. | to AD-2 only if such delivery has been accepted by contract. | |||
d. Relevant information on multicast streams delivered to End Users | d. Relevant information on multicast streams delivered to End Users | |||
in AD-2 is assumed to be collected by available capabilities in | in AD-2 is assumed to be collected by available capabilities in | |||
the application layer. The precise nature and formats of the | the application layer. The precise nature and formats of the | |||
collected information will be determined by directives from the | collected information will be determined by directives from the | |||
source owner and the domain operators. | source owner and the domain operators. | |||
e. The interconnection of AD-1 and AD-2 should minimally follow | e. The interconnection of AD-1 and AD-2 should minimally follow | |||
guidelines for traffic filtering between autonomous systems | guidelines for traffic filtering between autonomous systems | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
[BCP38]. Filtering guidelines specific to the multicast control- | [BCP38]. Filtering guidelines specific to the multicast control- | |||
plane and data-plane are described in section 6. | plane and data-plane are described in section 6. | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
3.2. Peering Point Enabled with GRE Tunnel | 3.2. Peering Point Enabled with GRE Tunnel | |||
The peering point is not native multicast enabled in this Use Case. | The peering point is not native multicast enabled in this Use Case. | |||
There is a Generic Routing Encapsulation Tunnel provisioned over the | There is a Generic Routing Encapsulation Tunnel provisioned over the | |||
peering point. In this case, the interconnection I1 between AD-1 and | peering point. In this case, the interconnection I1 between AD-1 and | |||
AD-2 in Figure 1 is multicast enabled via a Generic Routing | AD-2 in Figure 1 is multicast enabled via a Generic Routing | |||
Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast | Encapsulation Tunnel (GRE) [RFC2784] and encapsulating the multicast | |||
protocols across the interface. The routing configuration is | protocols across the interface. The routing configuration is | |||
basically unchanged: Instead of BGP (SAFI2) across the native IP | basically unchanged: Instead of BGP (SAFI2) across the native IP | |||
multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across | multicast link between AD-1 and AD-2, BGP (SAFI2) is now run across | |||
skipping to change at page 9, line 5 ¶ | skipping to change at page 8, line 47 ¶ | |||
o GRE tunnel requires manual configuration. | o GRE tunnel requires manual configuration. | |||
o The GRE must be established prior to stream starting. | o The GRE must be established prior to stream starting. | |||
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: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
Guidelines (a) through (d) are the same as those described in Use | Guidelines (a) through (d) are the same as those described in Use | |||
Case 3.1. Two additional guidelines are as follows: | 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. | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
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 is such that it only | |||
advertises the routes to the application sources and not to the | advertises the routes to the application sources and not to the | |||
entire network. This practice will prevent unauthorized 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 (e.g., if application - e.g., | |||
content - is not part of an agreed inter-domain partnership). | content - is not part of an agreed inter-domain partnership). | |||
3.3. Peering Point Enabled with an AMT - Both Domains Multicast | 3.3. Peering Point Enabled with an AMT - Both Domains Multicast | |||
Enabled | Enabled | |||
skipping to change at page 10, line 5 ¶ | skipping to change at page 9, line 44 ¶ | |||
AR = AMT Relay | AR = AMT Relay | |||
AG = AMT Gateway | AG = AMT Gateway | |||
I1 = AMT Interconnection between AD-1 and AD-2 | I1 = AMT Interconnection between AD-1 and AD-2 | |||
I2 = AD-2 and EU Multicast Connection | I2 = AD-2 and EU Multicast Connection | |||
Figure 2 - AMT Interconnection between AD-1 and AD-2 | Figure 2 - AMT Interconnection between AD-1 and AD-2 | |||
Advantages of this configuration: | Advantages of this configuration: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
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: | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
o Dynamic interconnection between Gateway-Relay pair across | o Dynamic interconnection between Gateway-Relay pair across | |||
the peering point. | the peering point. | |||
o Ability to serve clients and servers with differing | o Ability to serve clients and servers with differing | |||
policies. | policies. | |||
Disadvantages of this configuration: | Disadvantages of this configuration: | |||
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 end users or the number of | |||
skipping to change at page 11, line 5 ¶ | skipping to change at page 11, line 5 ¶ | |||
across the peering points once the Gateway in AD-2 receives the | across the peering points once the Gateway in AD-2 receives the | |||
(S, G) information from the EU. | (S, G) information from the EU. | |||
3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled | 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled | |||
In this AMT Use Case, the second administrative domain AD-2 is not | In this AMT Use Case, the second administrative domain AD-2 is not | |||
multicast enabled. This implies that the interconnection between AD- | multicast enabled. This implies that the interconnection between AD- | |||
2 and the End User is also not multicast enabled as depicted in | 2 and the End User is also not multicast enabled as depicted in | |||
Figure 3. | Figure 3. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
------------------- ------------------- | ------------------- ------------------- | |||
/ AD-1 \ / AD-2 \ | / AD-1 \ / AD-2 \ | |||
/ (Multicast Enabled) \ / (Non-Multicast \ | / (Multicast Enabled) \ / (Non-Multicast \ | |||
/ \ / Enabled) \ | / \ / Enabled) \ | |||
| +----+ | | | | | +----+ | | | | |||
| | | +------+ | | | +----+ | | | | +------+ | | | +----+ | |||
| | AS |------>| AR |-|---------|-----------------------|-->|EU/G| | | | AS |------>| AR |-|---------|-----------------------|-->|EU/G| | |||
| | | +------+ | | |I2 +----+ | | | | +------+ | | |I2 +----+ | |||
\ +----+ / \ / | \ +----+ / \ / | |||
skipping to change at page 12, line 5 ¶ | skipping to change at page 12, line 5 ¶ | |||
o Dynamic interconnection between Gateway-Relay pair across | o Dynamic interconnection between Gateway-Relay pair across | |||
the peering point. | the peering point. | |||
o Ability to serve clients and servers with differing | o Ability to serve clients and servers with differing | |||
policies. | policies. | |||
o Each AMT tunnel serves as a count for each End User and is also | o Each AMT tunnel serves as a count for each End User and is also | |||
able to track data usage (bytes) delivered to the EU. | able to track data usage (bytes) delivered to the EU. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
Disadvantages of this configuration: | Disadvantages of this configuration: | |||
o Additional devices (AMT Gateway and Relay pairs) are introduced | o Additional devices (AMT Gateway and Relay pairs) are introduced | |||
into the transport path. | into the transport path. | |||
o Assuming multiple peering points between the domains, the EU | o Assuming multiple peering points between the domains, the EU | |||
Gateway needs to be able to find the "correct" AMT Relay in AD- | Gateway needs to be able to find the "correct" AMT Relay in AD- | |||
1. | 1. | |||
skipping to change at page 13, line 5 ¶ | skipping to change at page 13, line 5 ¶ | |||
G) information to the Gateway for this purpose. | G) information to the Gateway for this purpose. | |||
e. The AMT tunnel capabilities are expected to be sufficient for | e. The AMT tunnel capabilities are expected to be sufficient for | |||
the purpose of collecting relevant information on the multicast | the purpose of collecting relevant information on the multicast | |||
streams delivered to End Users in AD-2. | streams delivered to End Users in AD-2. | |||
3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 | 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2 | |||
This is a variation of Use Case 3.4 as follows: | This is a variation of Use Case 3.4 as follows: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
------------------- ------------------- | ------------------- ------------------- | |||
/ AD-1 \ / AD-2 \ | / AD-1 \ / AD-2 \ | |||
/ (Multicast Enabled) \ / (Non-Multicast \ | / (Multicast Enabled) \ / (Non-Multicast \ | |||
/ \ / Enabled) \ | / \ / Enabled) \ | |||
| +----+ | |+--+ +--+ | | | +----+ | |+--+ +--+ | | |||
| | | +------+ | ||AG| |AG| | +----+ | | | | +------+ | ||AG| |AG| | +----+ | |||
| | AS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| | | | AS |------>| AR |-|-------->||AR|------------->|AR|-|-->|EU/G| | |||
| | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ | | | | +------+ | I1 ||1 | I2 |2 | |I3 +----+ | |||
\ +----+ / \+--+ +--+ / | \ +----+ / \+--+ +--+ / | |||
skipping to change at page 14, line 5 ¶ | skipping to change at page 14, line 5 ¶ | |||
AD-2. An AMT node comprises co-location of an AMT Gateway and an | AD-2. An AMT node comprises co-location of an AMT Gateway and an | |||
AMT Relay. One such node is at the AD-2 side of the peering point | AMT Relay. One such node is at the AD-2 side of the peering point | |||
(node AGAR1 in Figure 4). | (node AGAR1 in Figure 4). | |||
o Single AMT tunnel established across peering point linking AMT | o Single AMT tunnel established across peering point linking AMT | |||
Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. | Relay in AD-1 to the AMT Gateway in the AMT node AGAR1 in AD-2. | |||
o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to | o AMT tunnels linking AMT node AGAR1 at peering point in AD-2 to | |||
other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 | other AMT nodes located at the edges of AD-2: e.g., AMT tunnel I2 | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 in | linking AMT Relay in AGAR1 to AMT Gateway in AMT node AGAR2 in | |||
Figure 4. | Figure 4. | |||
o AMT tunnels linking EU device (via Gateway client embedded in | o AMT tunnels linking EU device (via Gateway client embedded in | |||
device) and AMT Relay in appropriate AMT node at edge of AD-2: | device) and AMT Relay in appropriate AMT node at edge of AD-2: | |||
e.g., I3 linking EU Gateway in device to AMT Relay in AMT node | e.g., I3 linking EU Gateway in device to AMT Relay in AMT node | |||
AGAR2. | AGAR2. | |||
The advantage for such a chained set of AMT tunnels is that the | The advantage for such a chained set of AMT tunnels is that the | |||
skipping to change at page 15, line 5 ¶ | skipping to change at page 15, line 5 ¶ | |||
4. Supporting Functionality | 4. Supporting Functionality | |||
Supporting functions and related interfaces over the peering point | Supporting functions and related interfaces over the peering point | |||
that enable the multicast transport of the application are listed in | that enable the multicast transport of the application are listed in | |||
this section. Critical information parameters that need to be | this section. Critical information parameters that need to be | |||
exchanged in support of these functions are enumerated along with | exchanged in support of these functions are enumerated along with | |||
guidelines as appropriate. Specific interface functions for | guidelines as appropriate. Specific interface functions for | |||
consideration are as follows. | consideration are as follows. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
4.1. Network Interconnection Transport and Security Guidelines | 4.1. Network Interconnection Transport and Security Guidelines | |||
The term "Network Interconnection Transport" refers to the | The term "Network Interconnection Transport" refers to the | |||
interconnection points between the two Administrative Domains. The | interconnection points between the two Administrative Domains. The | |||
following is a representative set of attributes that will need to be | following is a representative set of attributes that will need to be | |||
agreed to between the two administrative domains to support | agreed to between the two administrative domains to support | |||
multicast delivery. | multicast delivery. | |||
o Number of Peering Points. | o Number of Peering Points. | |||
skipping to change at page 16, line 5 ¶ | skipping to change at page 16, line 5 ¶ | |||
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.2. Routing Aspects and Related Guidelines | 4.2. Routing Aspects and Related Guidelines | |||
The main objective for multicast delivery routing is to ensure that | The main objective for multicast delivery routing is to ensure that | |||
the End User receives the multicast stream from the "most optimal" | the End User receives the multicast stream from the "most optimal" | |||
source [INF_ATIS_10] which typically: | source [INF_ATIS_10] which typically: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
o Maximizes the multicast portion of the transport and minimizes | o Maximizes the multicast portion of the transport and minimizes | |||
any unicast portion of the delivery, and | any unicast portion of the delivery, and | |||
o Minimizes the overall combined network(s) route distance. | o Minimizes the overall combined network(s) route distance. | |||
This routing objective applies to both Native and AMT; the actual | This routing objective applies to both Native and AMT; the actual | |||
methodology of the solution will be different for each. Regardless, | methodology of the solution will be different for each. Regardless, | |||
the routing solution is expected to be: | the routing solution is expected to be: | |||
skipping to change at page 17, line 5 ¶ | skipping to change at page 17, line 5 ¶ | |||
data. The "S" portion provides the name or IP address of the | data. The "S" portion provides the name or IP address of the | |||
source of the multicast stream. The metadata may also contain | source of the multicast stream. The metadata may also contain | |||
alternate delivery information such as specifying the unicast | alternate delivery information such as specifying the unicast | |||
address of the stream. | address of the stream. | |||
o The client uses the join message with S,G to join the multicast | o The client uses the join message with S,G to join the multicast | |||
stream [RFC4604]. | stream [RFC4604]. | |||
To facilitate this process, the two AD's need to do the following: | To facilitate this process, the two AD's need to do the following: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
o Advertise the source id(s) over the Peering Points. | o Advertise the source id(s) over the Peering Points. | |||
o Exchange relevant Peering Point information such as Capacity and | o Exchange relevant Peering Point information such as Capacity and | |||
Utilization. | Utilization. | |||
o Implement compatible multicast protocols to ensure proper | o 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 | |||
skipping to change at page 18, line 5 ¶ | skipping to change at page 18, line 5 ¶ | |||
o AMT Relays: These serve the purpose of tunneling UDP multicast | o AMT Relays: These serve the purpose of tunneling UDP multicast | |||
traffic to the receivers (i.e., End Points). The AMT Relay will | traffic to the receivers (i.e., End Points). The AMT Relay will | |||
receive the traffic natively from the multicast media source and | receive the traffic natively from the multicast media source and | |||
will replicate the stream on behalf of the downstream AMT | will replicate the stream on behalf of the downstream AMT | |||
Gateways, encapsulating the multicast packets into unicast | Gateways, encapsulating the multicast packets into unicast | |||
packets and sending them over the tunnel toward the AMT Gateway. | packets and sending them over the tunnel toward the AMT Gateway. | |||
In addition, the AMT Relay may perform various usage and | In addition, the AMT Relay may perform various usage and | |||
activity statistics collection. This results in moving the | activity statistics collection. This results in moving the | |||
replication point closer to the end user, and cuts down on | replication point closer to the end user, and cuts down on | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
traffic across the network. Thus, the linear costs of adding | traffic across the network. Thus, the linear costs of adding | |||
unicast subscribers can be avoided. However, unicast replication | unicast subscribers can be avoided. However, unicast replication | |||
is still required for each requesting endpoint within the | is still required for each requesting endpoint within the | |||
unicast-only network. | unicast-only network. | |||
o AMT Gateway (GW): The Gateway will reside on an on End-Point - | o AMT Gateway (GW): The Gateway will reside on an on End-Point - | |||
this may be a Personal Computer (PC) or a Set Top Box (STB). The | this may be a Personal Computer (PC) or a Set Top Box (STB). The | |||
AMT Gateway receives join and leave requests from the | AMT Gateway receives join and leave requests from the | |||
Application via an Application Programming Interface (API). In | Application via an Application Programming Interface (API). In | |||
skipping to change at page 18, line 35 ¶ | skipping to change at page 18, line 35 ¶ | |||
point. One advantage to this arrangement is that the tunnel is | point. One advantage to 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 ADs can coordinate and advertise special AMT Relay | element. The two ADs can coordinate and advertise special AMT Relay | |||
Anycast addresses with each other - though they may alternately | Anycast addresses with each other - though they may alternately | |||
decide to simply provision Relay addresses, though this would not be | decide to simply provision Relay addresses, though this would not be | |||
an optimal 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 more complicated AMT situations as | |||
AD-2 is not multicast enabled. For these cases, the End User device | AD-2 is not multicast enabled. For these cases, the End User device | |||
needs to be able to setup an AMT tunnel in the most optimal manner. | needs to be able to setup an AMT tunnel in the most optimal manner. | |||
Using an Anycast IP address for AMT Relays allows for all AMT | There are many methods by which relay selection can be done | |||
Gateways to find the "closest" AMT Relay - the nearest edge of the | including the use of DNS based queries and static lookup tables | |||
multicast topology of the source. An example of a basic delivery | [RFC7450]. The choice of the method is implementation dependent and | |||
via an AMT Multicast process for these two Use Cases is as follows: | is up to the network operators. Comparison of various methods is out | |||
of scope for this document; it is for further study. | ||||
An illustrative example of a relay selection based on DNS queries | ||||
and Anycast IP addresses process for Use Cases 3.4 and 3.5 is | ||||
described here. Using an Anycast IP address for AMT Relays allows | ||||
for all AMT Gateways to find the "closest" AMT Relay - the nearest | ||||
edge of the multicast topology of the source. Note that this is | ||||
strictly illustrative; the choice of the method is up to the network | ||||
operators. The basic process is as follows: | ||||
o Appropriate metadata is obtained by the EU client application. The | o Appropriate metadata is obtained by the EU client application. The | |||
metadata contains instructions directing the EU client to an | 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 the "S,G" data. The "S" | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
portion provides the URI (name or IP address) of the source of the | portion 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 alternate | originated by that source. The metadata may also contain alternate | |||
delivery information such as the address of the unicast form of | delivery information such as the address of the unicast form of | |||
the content to be used, for example, if the multicast stream | the content to be used, for example, if the multicast stream | |||
becomes unavailable. | becomes unavailable. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
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 "pseudo- | |||
address" shared among the relays that can gain multicast access to | address" shared among the relays that can gain multicast access to | |||
the source. | the source. | |||
skipping to change at page 19, line 44 ¶ | skipping to change at page 20, line 5 ¶ | |||
protocol messages). | protocol messages). | |||
o AMT Relay receives the "S,G" information and uses the S,G to join | o AMT Relay receives the "S,G" information and uses the S,G to join | |||
the appropriate multicast stream, if it has not already subscribed | the appropriate multicast stream, if it has not already subscribed | |||
to that stream. | to that stream. | |||
o AMT Relay encapsulates the multicast stream into the tunnel | o AMT Relay encapsulates the multicast stream into the tunnel | |||
between the Relay and the Gateway, providing the requested content | between the Relay and the Gateway, providing the requested content | |||
to the EU. | to the EU. | |||
Note: Further routing discussion on optimal method to find "best AMT | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
Relay/GW combination" and information exchange between AD's to be | ||||
provided. | ||||
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: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
o Servers and Content Management systems that support the delivery | o Servers and Content Management systems that support the delivery | |||
of applications via multicast and interactions between ADs. | of applications via multicast and interactions between ADs. | |||
o Functionality associated with logging, reporting, ordering, | o Functionality associated with logging, reporting, ordering, | |||
provisioning, maintenance, service assurance, settlement, etc. | provisioning, maintenance, service assurance, settlement, etc. | |||
4.3.1 Provisioning Guidelines | 4.3.1 Provisioning Guidelines | |||
Resources for basic connectivity between ADs Providers need to be | Resources for basic connectivity between ADs Providers need to be | |||
provisioned as follows: | provisioned as follows: | |||
skipping to change at page 20, line 46 ¶ | skipping to change at page 21, line 4 ¶ | |||
Native multicast functionality is assumed to be available across | Native multicast functionality is assumed to be available across | |||
many ISP backbones, peering and access networks. If however, native | many ISP backbones, peering and access networks. If however, native | |||
multicast is not an option (Use Cases 3.4 and 3.5), then: | multicast is not an option (Use Cases 3.4 and 3.5), then: | |||
o EU must have multicast client to use AMT multicast obtained either | o EU must have multicast client to use AMT multicast obtained either | |||
from Application Source (per agreement with AD-1) or from AD-1 or | from Application Source (per agreement with AD-1) or from AD-1 or | |||
AD-2 (if delegated by the Application Source). | AD-2 (if delegated by the Application Source). | |||
o If provided by AD-1/AD-2, then the EU could be redirected to a | o If provided by AD-1/AD-2, then the EU could be redirected to a | |||
client download site (note: this could be an Application Source | client download site (note: this could be an Application Source | |||
site). If provided by the Application Source, then this Source | site). If provided by the Application Source, then this Source | |||
would have to coordinate with AD-1 to ensure the proper client is | ||||
provided (assuming multiple possible clients). | ||||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
would have to coordinate with AD-1 to ensure the proper 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 & group | |||
addresses for streams it is allowed to join. | addresses for streams it is allowed to join. | |||
o DNS across each AD must be provisioned to enable a client GW to | o DNS across each AD must be provisioned to enable a client GW to | |||
locate the optimal AMT Relay (i.e. longest multicast path and | locate the optimal AMT Relay (i.e. longest multicast path and | |||
shortest unicast tunnel) with connectivity to the content's | shortest unicast tunnel) with connectivity to the content's | |||
multicast source. | multicast source. | |||
Provisioning Aspects Related to Operations and Customer Care are | Provisioning Aspects Related to Operations and Customer Care are | |||
stated as follows. | stated as follows. | |||
skipping to change at page 22, line 5 ¶ | skipping to change at page 22, line 5 ¶ | |||
associated with the account(s) utilized for delivered applications. | associated with the account(s) utilized for delivered applications. | |||
Supporting guidelines are as follows: | Supporting guidelines are as follows: | |||
o A unique identifier is recommended to designate each master | o A unique identifier is recommended to designate each master | |||
account. | account. | |||
o AD-2 is expected to set up "accounts" (logical facility generally | o AD-2 is expected to set up "accounts" (logical facility generally | |||
protected by login/password/credentials) for use by AD-1. Multiple | protected by login/password/credentials) for use by AD-1. Multiple | |||
accounts and multiple types/partitions of accounts can apply, e.g. | accounts and multiple types/partitions of accounts can apply, e.g. | |||
customer accounts, security accounts, etc. | customer accounts, security accounts, etc. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
4.3.3 Log Management Guidelines | 4.3.3 Log Management Guidelines | |||
Successful delivery of applications via multicast between pairs of | Successful delivery of applications via multicast between pairs of | |||
interconnecting ADs requires that appropriate logs will be exchanged | interconnecting ADs requires that appropriate logs will be exchanged | |||
between them in support. Associated guidelines are as follows. | between them in support. Associated guidelines are as follows. | |||
AD-2 needs to supply logs to AD-1 per existing contract(s). Examples | AD-2 needs to supply logs to AD-1 per existing contract(s). Examples | |||
of log types include the following: | of log types include the following: | |||
skipping to change at page 23, line 5 ¶ | skipping to change at page 23, line 5 ¶ | |||
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 | Service Performance refers to monitoring metrics related to | |||
multicast delivery via probes. The focus is on the service provided | multicast delivery via probes. The focus is on the service provided | |||
by AD-2 to AD-1 on behalf of all multicast application sources | by AD-2 to AD-1 on behalf of all multicast application sources | |||
(metrics may be specified for SLA use or otherwise). Associated | (metrics may be specified for SLA use or otherwise). Associated | |||
guidelines are as follows: | guidelines are as follows: | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
o Both AD's are expected to monitor, collect, and analyze service | o Both AD's 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 AD's are expected to agree on the type 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 | |||
skipping to change at page 24, line 5 ¶ | skipping to change at page 24, line 5 ¶ | |||
difficulties. AD-2 may be able to fix the problem by rerouting | difficulties. AD-2 may be able to fix the problem by rerouting | |||
the multicast streams via alternate AMT Relays. If the fix is not | the multicast streams via alternate AMT Relays. If the fix is not | |||
successful and multicast service delivery degrades, then AD-2 | successful and multicast service delivery degrades, then AD-2 | |||
needs to report the issue to AD-1. | needs to report the issue to AD-1. | |||
o When problem notification is received from a multicast | o When problem notification is received from a multicast | |||
application source, AD-1 determines whether the cause of the | application source, AD-1 determines whether the cause of the | |||
problem is within its own network or within the AD-2 domain. If | problem is within its own network or within the AD-2 domain. If | |||
the cause is within the AD-2 domain, then AD-1 supplies all | the cause is within the AD-2 domain, then AD-1 supplies all | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
necessary information to AD-2. Examples of supporting information | necessary information to AD-2. Examples of supporting information | |||
include the following: | include the following: | |||
o Kind of problem(s). | o Kind of problem(s). | |||
o Starting point & duration of problem(s). | o Starting point & duration of problem(s). | |||
o Conditions in which problem(s) occur. | o Conditions in which problem(s) occur. | |||
skipping to change at page 25, line 5 ¶ | skipping to change at page 25, line 5 ¶ | |||
o Analysis of relevant network fault or performance data. | o Analysis of relevant network fault or performance data. | |||
o Analysis of the problem information provided by the customer | o Analysis of the problem information provided by the customer | |||
(CP). | (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 AD's need to work jointly to verify and | |||
validate the success of the fix. | validate the success of the fix. | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
o Faults in service could lead to SLA violation for which the | o Faults in service could lead to SLA violation for which the | |||
multicast application source provider may have to be compensated | multicast application source provider may have to be compensated | |||
by AD-1. Subsequently, AD-1 may have to be compensated by AD-2 | by AD-1. Subsequently, AD-1 may have to be compensated by AD-2 | |||
based on the contract. | based on the contract. | |||
4.5. Client Reliability Models/Service Assurance Guidelines | 4.5. Client Reliability Models/Service Assurance Guidelines | |||
There are multiple options for instituting reliability | There are multiple options for instituting reliability | |||
architectures, most are at the application level. Both AD's should | architectures, most are at the application level. Both AD's should | |||
skipping to change at page 26, line 5 ¶ | skipping to change at page 26, line 5 ¶ | |||
troubleshooting commands in a secure manner. | troubleshooting commands in a secure manner. | |||
The specifics of the notification and alerts are beyond the scope of | The specifics of the notification and alerts are beyond the scope of | |||
this document, but general guidelines are similar to those described | this document, but general guidelines are similar to those described | |||
in section 4.4 (Service Performance and Monitoring). Some general | in section 4.4 (Service Performance and Monitoring). Some general | |||
communications issues are stated as follows. | communications issues are stated as follows. | |||
o Appropriate communications channels will be established between | o Appropriate communications channels will be established between | |||
the customer service and operations groups from both AD's to | the customer service and operations groups from both AD's to | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
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 | issues. Alternately, mutually acceptable resolution periods | |||
could be established depending on the severity of the | could be established depending on the severity of the | |||
identified trouble. | identified trouble. | |||
6. Security Considerations | 6. Security Considerations | |||
skipping to change at page 27, line 5 ¶ | skipping to change at page 27, line 5 ¶ | |||
example, [BCP38] style filtering could be deployed by both AD's to | example, [BCP38] style filtering could be deployed by both AD's to | |||
ensure that only legitimately sourced multicast content is exchanged | ensure that only legitimately sourced multicast content is exchanged | |||
between them. | between them. | |||
Authentication and authorization of EU to receive multicast content | Authentication and authorization of EU to receive multicast content | |||
is done at the application layer between the client application and | is done at the application layer between the client application and | |||
the source. This may involve some kind of token authentication and | the source. This may involve some kind of token authentication and | |||
is done at the application layer independently of the two AD's. If | is done at the application layer independently of the two AD's. If | |||
there are problems related to failure of token authentication when | there are problems related to failure of token authentication when | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
end-users are supported by AD-2, then some means of validating | end-users are supported by AD-2, then some means of validating | |||
proper working of the token authentication process (e.g., back-end | proper working of the token authentication process (e.g., back-end | |||
servers querying the multicast application source provider's token | servers querying the multicast application source provider's token | |||
authentication server are communicating properly) should be | authentication server are communicating properly) should be | |||
considered. Implementation details are beyond the scope of this | considered. Implementation details are beyond the scope of this | |||
document. | document. | |||
7. IANA Considerations | 7. IANA Considerations | |||
No considerations identified in this document | ||||
8. Conclusions | 8. Conclusions | |||
This Best Current Practice document provides detailed Use Case | This Best Current Practice document provides detailed Use Case | |||
scenarios for the transmission of applications via multicast across | scenarios for the transmission of applications via multicast across | |||
peering points between two Administrative Domains. A detailed set of | peering points between two Administrative Domains. A detailed set of | |||
guidelines supporting the delivery is provided for all Use Cases. | guidelines supporting the delivery is provided for all Use Cases. | |||
For Use Cases involving AMT tunnels (cases 3.4 and 3.5), it is | For Use Cases involving AMT tunnels (cases 3.4 and 3.5), it is | |||
recommended that proper procedures are implemented such that the | recommended that proper procedures are implemented such that the | |||
various AMT Gateways (at the End User devices and the AMT nodes in | various AMT Gateways (at the End User devices and the AMT nodes in | |||
skipping to change at page 28, line 5 ¶ | skipping to change at page 27, line 49 ¶ | |||
[RFC3376] B. Cain, et al, "Internet Group Management Protocol, | [RFC3376] B. Cain, et al, "Internet Group Management Protocol, | |||
Version 3", RFC 3376, October 2002 | Version 3", RFC 3376, October 2002 | |||
[RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol", | [RFC3618] B. Fenner, et al, "Multicast Source Discovery Protocol", | |||
RFC 3618, October 2003 | RFC 3618, October 2003 | |||
[RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery | [RFC3810] R. Vida and L. Costa, "Multicast Listener Discovery | |||
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004 | Version 2 (MLDv2) for IPv6", RFC 3810, June 2004 | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | ||||
[RFC4271] Y. Rekhter, et al, "A Border Gateway Protocol 4 (BGP-4)", | [RFC4271] Y. Rekhter, et al, "A Border Gateway Protocol 4 (BGP-4)", | |||
RFC 4271, January 2006 | RFC 4271, January 2006 | |||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
[RFC4604] H. Holbrook, et al, "Using Internet Group Management | [RFC4604] H. Holbrook, et al, "Using Internet Group Management | |||
Protocol Version 3 (IGMPv3) and Multicast Listener Discovery | Protocol Version 3 (IGMPv3) and Multicast Listener Discovery | |||
Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, | Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, | |||
August 2006 | August 2006 | |||
[RFC4609] P. Savola, et al, "Protocol Independent Multicast - Sparse | [RFC4609] P. Savola, et al, "Protocol Independent Multicast - Sparse | |||
Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", | Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", | |||
RFC 4609, August 2006 | RFC 4609, August 2006 | |||
[RFC7450] G. Bumgardner, "Automatic Multicast Tunneling", RFC 7450, | [RFC7450] G. Bumgardner, "Automatic Multicast Tunneling", RFC 7450, | |||
skipping to change at page 29, line 5 ¶ | skipping to change at page 29, line 5 ¶ | |||
[MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D | [MDH-04] D. Thaler, et al, "Multicast Debugging Handbook", IETF I-D | |||
draft-ietf-mboned-mdh-04.txt, May 2000 | draft-ietf-mboned-mdh-04.txt, May 2000 | |||
[Traceroute] http://traceroute.org/#source%20code | [Traceroute] http://traceroute.org/#source%20code | |||
[draft-MTraceroute] H. Asaeda, K, Meyer, and W. Lee, "Mtrace Version | [draft-MTraceroute] H. Asaeda, K, Meyer, and W. Lee, "Mtrace Version | |||
2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace- | 2: Traceroute Facility for IP Multicast", draft-ietf-mboned-mtrace- | |||
v2-16, October 2016, work in progress | v2-16, October 2016, work in progress | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | |||
10. Acknowledgments | 10. Acknowledgments | |||
IETF I-D Multicast Across Inter-Domain Peering Points November 2016 | 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 | ||||
IETF I-D Multicast Across Inter-Domain Peering Points February 2017 | ||||
Authors' Addresses | Authors' Addresses | |||
Percy S. Tarapore | Percy S. Tarapore | |||
AT&T | AT&T | |||
Phone: 1-732-420-4172 | Phone: 1-732-420-4172 | |||
Email: tarapore@att.com | Email: tarapore@att.com | |||
Robert Sayko | Robert Sayko | |||
AT&T | AT&T | |||
End of changes. 51 change blocks. | ||||
85 lines changed or deleted | 108 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |