--- 1/draft-ietf-mboned-interdomain-peering-bcp-01.txt 2016-03-21 10:17:22.640552156 -0700 +++ 2/draft-ietf-mboned-interdomain-peering-bcp-02.txt 2016-03-21 10:17:22.712553953 -0700 @@ -1,22 +1,22 @@ MBONED Working Group Percy S. Tarapore Internet Draft Robert Sayko Intended status: BCP AT&T Expires: July 20, 2016 Greg Shepherd Toerless Eckert Cisco Ram Krishnan Brocade - January 21, 2016 + March 21, 2016 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 This Internet-Draft is submitted in full conformance with the 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 http://datatracker.ietf.org/drafts/current/. @@ -70,29 +70,29 @@ 3.1. Native Multicast..........................................5 3.2. Peering Point Enabled with GRE Tunnel.....................7 3.3. Peering Point Enabled with an AMT - Both Domains Multicast Enabled........................................................8 3.4. Peering Point Enabled with an AMT - AD-2 Not Multicast Enabled.......................................................10 3.5. AD-2 Not Multicast Enabled - Multiple AMT Tunnels Through AD-2..........................................................12 4. Supporting Functionality......................................13 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.2 GRE Tunnel over Interconnecting Peering Point.....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.2 Application Accounting Billing Guidelines.........21 - 4.3.3 Log Management Guidelines.........................21 - 4.4. Operations - Service Performance and Monitoring Guidelines22 + 4.3.2 Application Accounting Billing Guidelines.........20 + 4.3.3 Log Management Guidelines.........................20 + 4.4. Operations - Service Performance and Monitoring Guidelines21 4.5. Client Reliability Models/Service Assurance Guidelines...24 5. Troubleshooting and Diagnostics...............................24 6. Security Considerations.......................................25 7. IANA Considerations...........................................26 8. Conclusions...................................................26 9. References....................................................26 9.1. Normative References.....................................26 9.2. Informative References...................................27 10. Acknowledgments..............................................27 @@ -110,34 +110,31 @@ o Describe the technical process and establish guidelines for setting up multicast-based delivery of applications across inter- domain peering points via a set of use cases. o Catalog all required information exchange between the administrative domains to support multicast-based delivery. This enables operators to initiate necessary processes to support inter-domain peering with multicast. 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 - purpose including Protocol Independent Multicast - Source - Specific Multicast (PIM-SSM) [RFC4607], Internet Group + purpose including PIM-SM, Protocol Independent Multicast - + Source Specific Multicast (PIM-SSM) [RFC4607], Internet Group Management Protocol (IGMP) [RFC4604], Multicast Listener - Discovery (MLD) [RFC4604], and Multicast Source Discovery - Protocol (MSDP) [RFC3618]. This BCP is independent of the - choice of multicast protocol; it focuses solely on the - implications for the inter-domain peering points. However, in - order to help explain use cases the figures will use the - 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. + Discovery (MLD) [RFC4604]. In the case of inter-domain + peering, it is recommended to use only SSM protocols. + o AD-1 and AD-2 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 for multicast delivery. The selection of an optimal AMT relay by a client is out of scope for this document. Note that AMT use is necessary only when native multicast is unavailable in the peering point (Use Case 3.3) or in the downstream administrative domain (Use Cases 3.4, and 3.5). o The collection of billing data is assumed to be done at the application level and is not considered to be a networking issue. The settlements process for end user billing and/or inter-provider billing is out of scope for this document. @@ -163,32 +160,30 @@ o The application stream originates at a source in Domain 1. o An End User associated with Domain 2 requests the application. It is assumed that the application is suitable for delivery via multicast means (e.g., live steaming of major events, software downloads to large numbers of end user devices, etc.) o The request is communicated to the application source which provides the relevant multicast delivery information to the EU device via a "manifest file". At a minimum, this file contains the {Source, Group} or (S,G) information relevant to the multicast stream. - 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. The manifest file may also contain additional information that the application client can use to locate the source and join the stream. - It should be noted that the second administrative domain - domain 2 - - may be an independent network domain (e.g., Tier 1 network - operator domain) or it could also be an Enterprise network operated - by a single customer. The peering point architecture and + 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 + operated by a single customer. The peering point architecture and requirements may have some unique aspects associated with the Enterprise case. 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. A comprehensive list of pertinent information that needs to be exchanged between the two domains to support various functions enabling the application transport is provided in section 4. @@ -583,34 +578,21 @@ needs to be a determination of the share of bandwidth reserved for multicast delivery. o QoS Requirements - Delay/latency specifications that need to be specified in an SLA. o AD Roles and Responsibilities - the role played by each AD for provisioning and maintaining the set of peering points to support multicast delivery. - From a security perspective, it is expected that normal/typical - 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. + o 4.2. Routing Aspects and Related Guidelines The main objective for multicast delivery routing is to ensure that the End User receives the multicast stream from the "most optimal" source [INF_ATIS_10] which typically: o Maximizes the multicast portion of the transport and minimizes any unicast portion of the delivery, and @@ -815,21 +798,21 @@ Provisioning aspects related to Multicast-Based inter-domain delivery are as follows. The ability to receive requested application via multicast is triggered via the manifest file. Hence, this file must be provided to the EU regarding multicast URL - and unicast fallback if applicable. AD-2 must build manifest and provision capability to 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 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 from Application Source (per agreement with AD-1) or from 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 client download site (note: this could be an Application Source site). If provided by the Application Source, then this Source would have to coordinate with AD-1 to ensure the proper client is @@ -1058,20 +1041,34 @@ facilitate information sharing related to diagnostic troubleshooting. o A default resolution period may be considered to resolve open issues. Alternately, mutually acceptable resolution periods could be established depending on the severity of the identified trouble. 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 should be the responsibility of the multicast application source provider and/or AD-1. AD-1 needs to work out the appropriate agreements with the source provider. Network has no DRM responsibilities, but might have authentication and authorization obligations. These though are consistent with normal operations of a CDN to insure end user reliability, security and network security.