idnits 2.17.1 draft-tarapore-mboned-multicast-cdni-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 2. Overview of Inter-domain Multicast Application Transport' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 5. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 101 has weird spacing: '...Catalog all ...' -- The document date (February 25, 2013) is 4078 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RFC4607' on line 228 looks like a reference -- Missing reference section? 'RFC4604' on line 221 looks like a reference -- Missing reference section? 'RFC2784' on line 215 looks like a reference -- Missing reference section? 'IETF-ID-AMT' on line 218 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBONED Working Group Percy S. Tarapore 2 Internet Draft Robert Sayko 3 Intended status: BCP AT&T 4 Expires: August 25, 2013 Ram Krishnan 5 Brocade 6 February 25, 2013 8 Multicasting Applications Across Inter-Domain Peering Points 9 draft-tarapore-mboned-multicast-cdni-02.txt 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on August 25, 2013. 34 Copyright Notice 36 Copyright (c) 2013 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with 44 respect to this document. Code Components extracted from this 45 document must include Simplified BSD License text as described in 47 IETF I-D Multicasting Applications Across Peering Points February 2013 49 Section 4.e of the Trust Legal Provisions and are provided without 50 warranty as described in the Simplified BSD License. 52 Abstract 54 This document examines the process of transporting applications via 55 multicast across inter-domain peering points. The objective is to 56 describe the setup process for multicast-based delivery across 57 administrative domains and document supporting functionality to 58 enable this process. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Overview of Inter-domain Multicast Application Transport.......3 64 3. Inter-domain Peering Point Requirements for Multicast..........4 65 3.1. Native Multicast..........................................4 66 3.2. Peering Point Enabled with GRE Tunnel.....................4 67 3.3. Peering Point Enabled with an AMT.........................4 68 4. Supporting Functionality.......................................5 69 4.1. Network Transport and Security Guidelines.................5 70 4.2. Routing Aspects and Related Guidelines....................5 71 4.3. Back Office Functions - Billing and Logging Guidelines....5 72 4.4. Operations - Service Performance and Monitoring Guidelines5 73 4.5. Reliability Models/Service Assurance Guidelines...........5 74 4.6. Provisioning Guidelines...................................5 75 4.7. Client Models.............................................6 76 4.8. Addressing Guidelines.....................................6 77 5. Security Considerations........................................6 78 6. IANA Considerations............................................6 79 7. Conclusions....................................................6 80 8. References.....................................................6 81 8.1. Normative References......................................6 82 8.2. Informative References....................................7 83 9. Acknowledgments................................................7 85 1. Introduction 87 Several types of applications (e.g., live video streaming) are well 88 suited for delivery via multicast means. The use of multicast for 89 delivering such applications offers significant savings for 90 utilization of resources in any given administrative domain. End 91 user demand for such applications is growing. Often, this requires 92 transporting such applications across administrative domains via 93 inter-domain peering points. 95 IETF I-D Multicasting Applications Across Peering Points February 2013 97 The objective of this Best Current Practices document is twofold: 98 o Describe the process and establish guidelines for setting up 99 multicast-based delivery of applications across inter-domain 100 peering points, and 101 o Catalog all required information exchange between the 102 administrative domains to support multicast-based delivery. 104 While there are several multicast protocols available for use, this 105 BCP will limit the discussion to the peering requirements of a 106 select set of the newer and more popular protocols including: 107 o Protocol Independent Multicast - Source Specific Multicast 108 (PIM-SSM) [RFC4607] 109 o Internet Group Management Protocol (IGMP) v3 [RFC4604] 110 o Multicast Listener Discovery (MLD) [RFC4604] 112 This document therefore serves the purpose of a "Gap Analysis" 113 exercise for this process. The rectification of any gaps identified 114 - whether they involve protocol extension development or otherwise - 115 is beyond the scope of this document and is for further study. 117 2. Overview of Inter-domain Multicast Application Transport 119 A multicast-based application delivery scenario is as follows: 120 o Two independent administrative domains are interconnected via a 121 peering point. 122 o The peering point is either multicast enabled (end-to-end 123 native multicast across the two domains) or it is connected by 124 one of two possible tunnel types: 125 o A Generic Routing Encapsulation (GRE) Tunnel [RFC2784] 126 allowing multicast tunneling across the peering point, or 127 o An Automatic Multicast Tunnel (AMT) [IETF-ID-AMT]. 128 o The application originates at a source in Domain A 129 o An End User associated with Domain B requests the application 130 o The request is communicated to the application source which 131 commences the delivery via multicast 133 IETF I-D Multicasting Applications Across Peering Points February 2013 135 o Application is distributed via Multicast from the source in 136 Domain A through the Peering Point interface and then to the 137 End User through Domain B. 139 The setup of the delivery process along with associated requirements 140 is described in section 3. A comprehensive list of required 141 information that needs to be exchanged between the two domains to 142 support various functions enabling the application transport is 143 provided in section 4. 145 3. Inter-domain Peering Point Requirements for Multicast 147 The transport of applications using multicast requires that the 148 inter-domain peering point is enabled to support such a process. 149 There are three possible Use Cases for consideration. 151 3.1. Native Multicast 153 This Use Case involves end-to-end Native Multicast between the two 154 administrative domains and the peering point is also native 155 multicast enabled. 157 Interface requirements for this Use Case need to be described here. 159 3.2. Peering Point Enabled with GRE Tunnel 161 The peering point is not native multicast enabled in this Use Case. 162 There is a Generic Routing Encapsulation Tunnel provisioned over the 163 peering point. 165 Interface requirements for this Use Case need to be described here. 167 3.3. Peering Point Enabled with an AMT 169 The peering point in this Use Case is provisioned with an Automatic 170 Multicast Tunnel. 172 Interface requirements for this Use Case need to be described here. 174 IETF I-D Multicasting Applications Across Peering Points February 2013 176 4. Supporting Functionality 178 Supporting functions and related interfaces over the peering point 179 that enable the multicast transport of the application are listed in 180 this section. Critical information parameters that need to be 181 exchanged in support of these functions are enumerated along with 182 guidelines as appropriate. Specific interface functions for 183 consideration are as follows. 185 4.1. Network Transport and Security Guidelines 187 4.2. Routing Aspects and Related Guidelines 189 4.3. Back Office Functions - Billing and Logging Guidelines 191 4.4. Operations - Service Performance and Monitoring Guidelines 193 4.5. Reliability Models/Service Assurance Guidelines 195 4.6. Provisioning Guidelines 197 IETF I-D Multicasting Applications Across Peering Points February 2013 199 4.7. Client Models 201 4.8. Addressing Guidelines 203 5. Security Considerations 205 (Include discussion on DRM, AAA, Network Security) 207 6. IANA Considerations 209 7. Conclusions 211 8. References 213 8.1. Normative References 215 [RFC2784] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, 216 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000 218 [IETF-ID-AMT] G. Bumgardner, "Automatic Multicast Tunneling", draft- 219 ietf-mboned-auto-multicast-13, April 2012, Work in progress 221 [RFC4604] H. Holbrook, et al, "Using Internet Group Management 222 Protocol Version 3 (IGMPv3) and Multicast Listener Discovery 223 Protocol Version 2 (MLDv2) for Source Specific Multicast", RFC 4604, 224 August 2006 226 IETF I-D Multicasting Applications Across Peering Points February 2013 228 [RFC4607] H. Holbrook, et al, "Source Specific Multicast", RFC 4607, 229 August 2006 231 8.2. Informative References 233 9. Acknowledgments 235 IETF I-D Multicasting Applications Across Peering Points February 2013 237 Authors' Addresses 239 Percy S. Tarapore 240 AT&T 241 Phone: 1-732-420-4172 242 Email: tarapore@att.com 244 Robert Sayko 245 AT&T 246 Phone: 1-732-420-3292 247 Email: rs1983@att.com 249 Ram Krishnan 250 Brocade 251 Phone: 252 Email: ramk@brocade.com