idnits 2.17.1 draft-contreras-pim-multiple-upstreams-reqs-00.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (March 7, 2015) is 3338 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PIM Working Group LM. Contreras 3 Internet-Draft Telefonica 4 Intended status: Experimental CJ. Bernardos 5 Expires: September 8, 2015 Universidad Carlos III de Madrid 6 March 7, 2015 8 Requiremnets for the extension of the MLD proxy functionality to support 9 multiple upstream interfaces 10 draft-contreras-pim-multiple-upstreams-reqs-00 12 Abstract 14 The purpose of this document is to define the requirements for a MLD 15 proxy with multiple interfaces covering a variety of applicability 16 scenarios. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on September 8, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 3 55 4. Scenarios of applicability . . . . . . . . . . . . . . . . . 4 56 4.1. Fixed network scenarios . . . . . . . . . . . . . . . . . 5 57 4.1.1. Multicast wholesale offer for residential services . 5 58 4.1.1.1. Requirements . . . . . . . . . . . . . . . . . . 5 59 4.1.2. Multicast resiliency . . . . . . . . . . . . . . . . 5 60 4.1.2.1. Requirements . . . . . . . . . . . . . . . . . . 6 61 4.1.3. Load balancing for multicast traffic in the metro 62 segment . . . . . . . . . . . . . . . . . . . . . . . 6 63 4.1.3.1. Requirements . . . . . . . . . . . . . . . . . . 6 64 4.1.4. Summary of the requirements needed for fixed network 65 scenarios . . . . . . . . . . . . . . . . . . . . . . 6 66 4.2. Mobile network scenarios . . . . . . . . . . . . . . . . 7 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 7. Normative References . . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The aim of this document is to define the functionality that an MLD 75 proxy with multiple upstream interfaces should have in order to 76 support different scenarios of applicability in both fixed and mobile 77 networks. This compatibility is needed in order to simplify node 78 functionality and to ensure an easier deployment of multicast 79 capabilities in all the use cases described in this document. 81 2. Terminology 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 84 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 85 document are to be interpreted as described in RFC2119 [RFC2119]. 87 This document uses the terminology defined in RFC4605 [RFC4605]. 88 Specifically, the definition of Upstream and Downstream interfaces, 89 which are reproduced here for completeness. 91 Upstream interface: A proxy device's interface in the direction of 92 the root of the tree. Also called the "Host interface". 94 Downstream interface: Each of a proxy device's interfaces that is 95 not in the direction of the root of the tree. Also called the 96 "Router interfaces". 98 3. Problem statement 100 The concept of MLD proxy with several upstream interfaces has emerged 101 as a way of optimizing (and in some cases enabling) service delivery 102 scenarios where separate multicast service providers are reachable 103 through the same access network infrastructure. Figure 1 presents 104 the conceptual model under consideration. 106 downstream upstream 107 interface interface A 108 | | 109 | | _______________ 110 | +-------+ v / \ 111 | | O-------( Multicast Set 1 ) 112 +----------+ v | MLD | \_______________/ 113 | Listener |------| | _______________ 114 +----------+ | Proxy | / \ 115 | O-------( Multicast Set 2 ) 116 +-------+ ^ \_______________/ 117 | 118 | 119 upstream 120 interface B 122 Figure 1: Concept of MLD proxy with multiple upstream interfaces 124 The current version of the document is focused on fixed network 125 scenarios. Mobile network scenarios will be covered in future 126 versions. 128 In the case of fixed networks, multicast wholesale services in a 129 competitive residential market require an efficient distribution of 130 multicast traffic from different operators or content providers, i.e. 131 the incumbent operator and a number of alternative providers, on the 132 network infrastructure of the former. Existing proposals are based 133 on the use of PIM routing from the metro/core network, and multicast 134 traffic aggregation on the same tree. A different approach could be 135 achieved with the use of an MLD proxy with multiple upstream 136 interfaces, each of them pointing to a distinct multicast router in 137 the metro/core border which is part of separated multicast trees deep 138 in the network. Figure 2 graphically describes this scenario. 140 downstream upstream 141 interface interface A 142 | | 143 | | _______________ 144 | +--------+ v / \ 145 | | O-------( Multicast Set 1 ) 146 | | Aggr. | \_______________/ 147 +----+ v | Switch | (e.g. from the Incumbent 148 | AN |-------| | Operator) 149 +----+ | (MLD | _______________ 150 (e.g. | Proxy) | / \ 151 DSLAM | O-------( Multicast Set 2 ) 152 /OLT) +--------+ ^ \_______________/ 153 | (e.g. from an Alternative 154 | Provider) 155 | 156 upstream 157 interface B 159 Figure 2: Example of usage of an MLD proxy with multiple upstream 160 interfaces in a fixed network scenario 162 Since those scenarios can motivate distinct needs in terms of MLD 163 proxy functionality, it is necessary to consider a comprehensive 164 approach, looking at the possible scenarios, and establishing a 165 minimum set of requirements which can allow the operation of a 166 versatile MLD proxy with multiple upstream interfaces as a common 167 entity to all of them (i.e., no different kinds of proxies depending 168 on the scenario, but a common proxy applicable to all the potential 169 scenarios). 171 4. Scenarios of applicability 173 Having multiple upstream interfaces creates a new decision space for 174 delivering the proper multicast content to the subscriber. Basically 175 it is now possible to implement channel-based or subscriber-based 176 upstream selection, according to mechanisms or policies that could be 177 defined for the multicast service provision. 179 This section describes in detail a number of scenarios of 180 applicability of an MLD proxy with multiple upstream interfaces in 181 place. A number of requirements for the MLD proxy functionality are 182 identified from those scenarios. 184 4.1. Fixed network scenarios 186 Residential broadband users get access to multiple IP services 187 through fixed network infrastructures. End user's equipment is 188 connected to an access node, and the traffic of a number of access 189 nodes is collected in aggregation switches. 191 For the multicast service, the use of an MLD proxy with multiple 192 upstream interfaces in those switches can provide service flexibility 193 in a lightweight and simpler manner if compared with PIM-routing 194 based alternatives. 196 4.1.1. Multicast wholesale offer for residential services 198 This scenario has been already introduced in the previous section, 199 and can be seen in Figure 2. There are two different operators, the 200 one operating the fixed network where the end user is connected 201 (e.g., typically an incumbent operator), and the one providing the 202 Internet service to the end user (e.g., an alternative Internet 203 service provider). Both can offer multicast streams that can be 204 subscribed by the end user, independently of which provider 205 contributes with the content. 207 Note that it is assumed that both providers offer distinct multicast 208 groups. However, more than one subscription to multicast channels of 209 different providers could take place simultaneously. 211 4.1.1.1. Requirements 213 o The MLD proxy should be able to deliver multicast control messages 214 sent by the end user to the corresponding provider's multicast 215 router. 217 o The MLD proxy should be able to deliver multicast control messages 218 sent by each of the providers to the corresponding end user. 220 4.1.2. Multicast resiliency 222 In current PIM-based solutions, the resiliency of the multicast 223 distribution relays on the routing capabilities provided by protocols 224 like PIM and VRRP. A simpler scheme could be achieved by 225 implementing different upstream interfaces on MLD proxies, providing 226 path diversity through the connection to distinct leaves of a given 227 multicast tree. 229 It is assumed that only one of the upstream interfaces is active in 230 receiving the multicast content, while the other is up and in standby 231 mode for fast switching. 233 4.1.2.1. Requirements 235 o The MLD proxy should be able to deliver multicast control messages 236 sent by the end user to the corresponding active upstream 237 interface. 239 o The MLD proxy should be able to deliver multicast control messages 240 received in the active upstream to the end users, while ignoring 241 the control messages of the standby upstream interface. 243 o The MLD proxy should be able of rapidly switching from the active 244 to the standby upstream interface in case of network failure, 245 transparently to the end user. 247 4.1.3. Load balancing for multicast traffic in the metro segment 249 A single upstream interface in existing MLD proxy functionality 250 typically forces the distribution of all the channels on the same 251 path in the last segment of the network. Multiple upstream 252 interfaces could naturally split the demand, alleviating the 253 bandwidth requirements in the metro segment. 255 4.1.3.1. Requirements 257 o The MLD proxy should be able to deliver multicast control messages 258 sent by the end user to the corresponding multicast router which 259 provides the channel of interest. 261 o The MLD proxy should be able to deliver multicast control messages 262 sent by each of the multicast routers to the corresponding end 263 user. 265 o The MLD proxy should be able to decide which upstream interface is 266 selected for any new channel request according to defined criteria 267 (e.g., load balancing). 269 4.1.4. Summary of the requirements needed for fixed network scenarios 271 Following the analysis above, a number of different requirements can 272 be identified by the MLD proxy to support multiple upstream 273 interfaces in fixed network scenarios. The following table 274 summarizes these requirements. 276 +-----------------------------------+ 277 | Fixed Network Scenarios | 278 +---------+-----------+-----------+-----------+ 279 |Functio- | Multicast | Multicast | Load | 280 |nality | Wholesale | Resiliency| Balancing | 281 +---------+-----------+-----------+-----------+ 282 |Upstream | | | | 283 |Control | X | X | X | 284 |Delivery | | | | 285 +---------+-----------+-----------+-----------+ 286 |Downstr. | | | | 287 |Control | X | X | X | 288 |Delivery | | | | 289 +---------+-----------+-----------+-----------+ 290 |Active / | | | | 291 |Standby | | X | | 292 |Upstream | | | | 293 +---------+-----------+-----------+-----------+ 294 |Upstr i/f| | | | 295 |selection| | | X | 296 |per group| | | | 297 +---------+-----------+-----------+-----------+ 298 |Upstr i/f| | | | 299 |selection| | X | | 300 |all group| | | | 301 +---------+-----------+-----------+-----------+ 303 Figure 3: Functionality needed on MLD proxy with multiple upstream 304 interfaces per application scenario in fixed networks 306 4.2. Mobile network scenarios 308 To be done. 310 5. Security Considerations 312 To be completed 314 6. IANA Considerations 316 To be completed 318 7. Normative References 320 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 321 Requirement Levels", BCP 14, RFC 2119, March 1997. 323 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 324 "Internet Group Management Protocol (IGMP) / Multicast 325 Listener Discovery (MLD)-Based Multicast Forwarding 326 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 328 Authors' Addresses 330 Luis M. Contreras 331 Telefonica 332 Ronda de la Comunicacion, s/n 333 Sur-3 building, 3rd floor 334 Madrid 28050 335 Spain 337 Email: luismiguel.contrerasmurillo@telefonica.com 338 URI: http://people.tid.es/LuisM.Contreras/ 340 Carlos J. Bernardos 341 Universidad Carlos III de Madrid 342 Av. Universidad, 30 343 Leganes, Madrid 28911 344 Spain 346 Phone: +34 91624 6236 347 Email: cjbc@it.uc3m.es 348 URI: http://www.it.uc3m.es/cjbc/