draft-ietf-mboned-interdomain-peering-bcp-01.txt   draft-ietf-mboned-interdomain-peering-bcp-02.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: July 20, 2016 Greg Shepherd Expires: July 20, 2016 Greg Shepherd
Toerless Eckert Toerless Eckert
Cisco Cisco
Ram Krishnan Ram Krishnan
Brocade Brocade
January 21, 2016 March 21, 2016
Use of Multicast Across Inter-Domain Peering Points Use of Multicast Across Inter-Domain Peering Points
draft-ietf-mboned-interdomain-peering-bcp-01.txt draft-ietf-mboned-interdomain-peering-bcp-02.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/.
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.1. Native Multicast..........................................5 3.1. Native Multicast..........................................5
3.2. Peering Point Enabled with GRE Tunnel.....................7 3.2. Peering Point Enabled with GRE Tunnel.....................7
3.3. Peering Point Enabled with an AMT - Both Domains Multicast 3.3. Peering Point Enabled with an AMT - Both Domains Multicast
Enabled........................................................8 Enabled........................................................8
3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast
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......................................13 4. Supporting Functionality......................................13
4.1. Network Interconnection Transport and Security Guidelines14 4.1. Network Interconnection Transport and Security Guidelines14
4.2. Routing Aspects and Related Guidelines...................15 4.2. Routing Aspects and Related Guidelines...................14
4.2.1 Native Multicast Routing Aspects..................15 4.2.1 Native Multicast Routing Aspects..................15
4.2.2 GRE Tunnel over Interconnecting Peering Point.....16 4.2.2 GRE Tunnel over Interconnecting Peering Point.....16
4.2.3 Routing Aspects with AMT Tunnels.....................16 4.2.3 Routing Aspects with AMT Tunnels.....................16
4.3. Back Office Functions - Billing and Logging Guidelines...19 4.3. Back Office Functions - Billing and Logging Guidelines...18
4.3.1 Provisioning Guidelines...........................19 4.3.1 Provisioning Guidelines...........................19
4.3.2 Application Accounting Billing Guidelines.........21 4.3.2 Application Accounting Billing Guidelines.........20
4.3.3 Log Management Guidelines.........................21 4.3.3 Log Management Guidelines.........................20
4.4. Operations - Service Performance and Monitoring Guidelines22 4.4. Operations - Service Performance and Monitoring Guidelines21
4.5. Client Reliability Models/Service Assurance Guidelines...24 4.5. Client Reliability Models/Service Assurance Guidelines...24
5. Troubleshooting and Diagnostics...............................24 5. Troubleshooting and Diagnostics...............................24
6. Security Considerations.......................................25 6. Security Considerations.......................................25
7. IANA Considerations...........................................26 7. IANA Considerations...........................................26
8. Conclusions...................................................26 8. Conclusions...................................................26
9. References....................................................26 9. References....................................................26
9.1. Normative References.....................................26 9.1. Normative References.....................................26
9.2. Informative References...................................27 9.2. Informative References...................................27
10. Acknowledgments..............................................27 10. Acknowledgments..............................................27
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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 applications across inter-
domain peering points via a set of use cases. 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 Administrative Domain 1 (AD-1) is enabled with native
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 Protocol Independent Multicast - Source purpose including PIM-SM, Protocol Independent Multicast -
Specific Multicast (PIM-SSM) [RFC4607], Internet Group Source Specific Multicast (PIM-SSM) [RFC4607], Internet Group
Management Protocol (IGMP) [RFC4604], Multicast Listener Management Protocol (IGMP) [RFC4604], Multicast Listener
Discovery (MLD) [RFC4604], and Multicast Source Discovery Discovery (MLD) [RFC4604]. In the case of inter-domain
Protocol (MSDP) [RFC3618]. This BCP is independent of the peering, it is recommended to use only SSM protocols.
choice of multicast protocol; it focuses solely on the o AD-1 and AD-2 are assumed to adopt compatible protocols. The
implications for the inter-domain peering points. However, in use of different protocols is beyond the scope of this
order to help explain use cases the figures will use the document.
general SSM flows and architectures.
o Network Administrative Domains involved in setting up
multicast peering points are assumed to adopt compatible
protocols. The use of different protocols is beyond the scope
of this document.
o It is assumed that an AMT Relay will be available to a client o It is assumed that an AMT Relay will be available to a client
for multicast delivery. The selection of an optimal AMT relay for multicast delivery. The selection of an optimal AMT relay
by a client is out of scope for this document. Note that AMT by a client is out of scope for this document. Note that AMT
use is necessary only when native multicast is unavailable in use is necessary only when native multicast is unavailable in
the peering point (Use Case 3.3) or in the downstream the peering point (Use Case 3.3) or in 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 The collection of billing data is assumed to be done at the
application level and is not considered to be a networking application level and is not considered to be a networking
issue. The settlements process for end user billing and/or issue. The settlements process for end user billing and/or
inter-provider billing is out of scope for this document. inter-provider billing is out of scope for this document.
skipping to change at page 5, line 4 skipping to change at page 4, line 39
o The application stream originates at a source in Domain 1. o The application stream originates at a source in Domain 1.
o An End User associated with Domain 2 requests the application. o An End User associated with Domain 2 requests the application.
It is assumed that the application is suitable for delivery via It is assumed that the application is suitable for delivery via
multicast means (e.g., live steaming of major events, software multicast means (e.g., live steaming of major events, software
downloads to large numbers of end user devices, etc.) downloads to large numbers of end user devices, etc.)
o The request is communicated to the application source which o The request is communicated to the application source which
provides the relevant multicast delivery information to the EU provides the relevant multicast delivery information to the EU
device via a "manifest file". At a minimum, this file contains device via a "manifest file". At a minimum, this file contains
the {Source, Group} or (S,G) information relevant to the the {Source, Group} or (S,G) information relevant to the
multicast stream. multicast stream.
o The application client in the EU device then joins the o The application client in the EU device then joins the
multicast stream distributed by the application source in multicast stream distributed by the application source in
domain 1 utilizing the (S,G) information provided in the domain 1 utilizing the (S,G) information provided in the
manifest file. The manifest file may also contain additional manifest file. The manifest file may also contain additional
information that the application client can use to locate the information that the application client can use to locate the
source and join the stream. source and join the stream.
It should be noted that the second administrative domain - domain 2 Note that domain 2 may be an independent network domain (e.g., Tier
- may be an independent network domain (e.g., Tier 1 network 1 network operator domain) or it could also be an Enterprise network
operator domain) or it could also be an Enterprise network operated operated by a single customer. The peering point architecture and
by a single customer. The peering point architecture and
requirements may have some unique aspects associated with the requirements may have some unique aspects associated with the
Enterprise case. Enterprise case.
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.
skipping to change at page 14, line 42 skipping to change at page 14, line 42
needs to be a determination of the share of bandwidth reserved needs to be a determination of the share of bandwidth reserved
for multicast delivery. for multicast delivery.
o QoS Requirements - Delay/latency specifications that need to be o QoS Requirements - Delay/latency specifications that need to be
specified in an SLA. 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.
From a security perspective, it is expected that normal/typical o
security procedures will be followed by each AD to facilitate
multicast delivery to registered and authenticated end users. Some
security aspects for consideration are:
o Encryption - Peering point links may be encrypted per agreement
if dedicated for multicast delivery.
o Security Breach Mitigation Plan - In the event of a security
breach, the two AD's are expected to have a mitigation plan for
shutting down the peering point and directing multicast traffic
over alternated peering points. It is also expected that
appropriate information will be shared for the purpose of securing
the identified breach.
4.2. Routing Aspects and Related Guidelines 4.2. Routing Aspects and Related Guidelines
The main objective for multicast delivery routing is to ensure that The main objective for multicast delivery routing is to ensure that
the End User receives the multicast stream from the "most optimal" the End User receives the multicast stream from the "most optimal"
source [INF_ATIS_10] which typically: source [INF_ATIS_10] which typically:
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
skipping to change at page 20, line 5 skipping to change at page 19, line 31
Provisioning aspects related to Multicast-Based inter-domain Provisioning aspects related to Multicast-Based inter-domain
delivery are as follows. delivery are as follows.
The ability to receive requested application via multicast is The ability to receive requested application via multicast is
triggered via the manifest file. Hence, this file must be provided triggered via the manifest file. Hence, this file must be provided
to the EU regarding multicast URL - and unicast fallback if to the EU regarding multicast URL - and unicast fallback if
applicable. AD-2 must build manifest and provision capability to applicable. AD-2 must build manifest and provision capability to
provide the file to the EU. provide the file to the EU.
Native multicast functionality is assumed to be available in across Native multicast functionality is assumed to be available 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 would have to coordinate with AD-1 to ensure the proper client is
skipping to change at page 25, line 30 skipping to change at page 25, line 9
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
From a security perspective, normal security procedures are expected
to be followed by each AD to facilitate multicast delivery to
registered and authenticated end users. Additionally:
o Encryption - Peering point links may be encrypted per agreement
if dedicated for multicast delivery.
o Security Breach Mitigation Plan - In the event of a security
breach, the two AD's are expected to have a mitigation plan for
shutting down the peering point and directing multicast traffic
over alternated peering points. It is also expected that
appropriate information will be shared for the purpose of securing
the identified breach.
DRM and Application Accounting, Authorization and Authentication DRM and Application Accounting, Authorization and Authentication
should be the responsibility of the multicast application source should be the responsibility of the multicast application source
provider and/or AD-1. AD-1 needs to work out the appropriate provider and/or AD-1. AD-1 needs to work out the appropriate
agreements with the source provider. agreements with the source provider.
Network has no DRM responsibilities, but might have authentication Network has no DRM responsibilities, but might have authentication
and authorization obligations. These though are consistent with and authorization obligations. These though are consistent with
normal operations of a CDN to insure end user reliability, security normal operations of a CDN to insure end user reliability, security
and network security. and network security.
 End of changes. 13 change blocks. 
39 lines changed or deleted 35 lines changed or added

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