idnits 2.17.00 (12 Aug 2021) /tmp/idnits64571/draft-contreras-pim-multiple-upstreams-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 (July 3, 2013) is 3237 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: draft-ietf-multimob-handover-optimization has been published as RFC 7161 == Outdated reference: draft-ietf-multimob-pmipv6-ropt has been published as RFC 7028 Summary: 0 errors (**), 0 flaws (~~), 4 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 I+D 4 Intended status: Experimental CJ. Bernardos 5 Expires: January 4, 2014 UC3M 6 JC. Zuniga 7 InterDigital 8 July 3, 2013 10 Extension of the MLD proxy functionality to support multiple upstream 11 interfaces 12 draft-contreras-pim-multiple-upstreams-00 14 Abstract 16 This document presents different scenarios of applicability for an 17 MLD proxy running more than one upstream interface. Since those 18 scenarios impose different requirements on the MLD proxy with 19 multiple upstream interfaces, it is important to ensure that the 20 proxy functionality addresses all of them for compatibility. 22 The purpose of this document is to define the requirements in an MLD 23 proxy with multiple interfaces covering a variety of applicability 24 scenarios, and to specify the proxy functionality to satisfy all of 25 them. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 4, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 64 4. Scenarios of applicability . . . . . . . . . . . . . . . . . . 7 65 4.1. Fixed network scenarios . . . . . . . . . . . . . . . . . 7 66 4.1.1. Multicast wholesale offer for residential services . . 8 67 4.1.1.1. Requirements . . . . . . . . . . . . . . . . . . . 8 68 4.1.2. Multicast resiliency . . . . . . . . . . . . . . . . . 8 69 4.1.2.1. Requirements . . . . . . . . . . . . . . . . . . . 8 70 4.1.3. Load balancing for multicast traffic in the metro 71 segment . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.1.3.1. Requirements . . . . . . . . . . . . . . . . . . . 9 73 4.1.4. Summary of the requirements needed for mobile 74 network scenarios . . . . . . . . . . . . . . . . . . 9 75 4.2. Mobile network scenarios . . . . . . . . . . . . . . . . . 10 76 4.2.1. Applicability to multicast listener mobility . . . . . 10 77 4.2.1.1. Single MLD proxy instance on MAG . . . . . . . . . 11 78 4.2.1.1.1. Requirements . . . . . . . . . . . . . . . . . 11 79 4.2.1.2. Remote and local multicast subscription . . . . . 11 80 4.2.1.2.1. Requirements . . . . . . . . . . . . . . . . . 12 81 4.2.1.3. Dual subscription to multicast groups during 82 handover . . . . . . . . . . . . . . . . . . . . . 12 83 4.2.1.3.1. Requirements . . . . . . . . . . . . . . . . . 13 84 4.2.2. Applicability to multicast source mobility . . . . . . 13 85 4.2.2.1. Support of remote and direct subscription in 86 basic source mobility . . . . . . . . . . . . . . 13 87 4.2.2.1.1. Requirements . . . . . . . . . . . . . . . . . 14 88 4.2.2.2. Direct communication between source and 89 listener associated with distinct LMAs but on 90 the same MAG . . . . . . . . . . . . . . . . . . . 14 91 4.2.2.2.1. Requirements . . . . . . . . . . . . . . . . . 15 92 4.2.2.3. Route optimization support in source mobility 93 for remote subscribers . . . . . . . . . . . . . . 15 94 4.2.2.3.1. Requirements . . . . . . . . . . . . . . . . . 15 95 4.2.3. Summary of the requirements needed for mobile 96 network scenarios . . . . . . . . . . . . . . . . . . 16 97 5. Functional specification of an MLD proxy with multiple 98 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 18 99 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 100 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 101 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 18 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 19 105 Appendix A. Basic support for multicast listener with PMIPv6 . . 19 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 108 1. Introduction 110 The aim of this document is to define the functionality that an MLD 111 proxy with multiple upstream interfaces should have in order to 112 support different scenarios of applicability in both fixed and mobile 113 networks. This compatibility is needed in order to simplify node 114 functionality and to ensure an easier deployment of multicast 115 capabilities in all the use cases described in this document. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC2119 [RFC2119]. 123 This document uses the terminology defined in RFC4605 [RFC4605]. 124 Specifically, the definition of Upstream and Downstream interfaces, 125 which are reproduced here for completeness. 127 Upstream interface: A proxy device's interface in the direction of 128 the root of the tree. Also called the "Host interface". 130 Downstream interface: Each of a proxy device's interfaces that is 131 not in the direction of the root of the tree. Also called the 132 "Router interfaces". 134 3. Problem statement 136 The concept of MLD proxy with several upstream interfaces has emerged 137 as a way of optimizing (and in some cases enabling) service delivery 138 scenarios where separate multicast service providers are reachable 139 through the same access network infrastructure. Figure 1 presents 140 the conceptual model under consideration. 142 downstream upstream 143 interface interface A 144 | | 145 | | _______________ 146 | +-------+ v / \ 147 | | O-------( Multicast Set 1 ) 148 +----------+ v | MLD | \_______________/ 149 | Listener |------| | _______________ 150 +----------+ | Proxy | / \ 151 | O-------( Multicast Set 2 ) 152 +-------+ ^ \_______________/ 153 | 154 | 155 upstream 156 interface B 158 Figure 1: Concept of MLD proxy with multiple upstream interfaces 160 For illustrative purposes, two applications for fixed and mobile 161 networks are here introduced. They will be elaborated later on the 162 document. 164 In the case of fixed networks, multicast wholesale services in a 165 competitive residential market require an efficient distribution of 166 multicast traffic from different operators, i.e. the incumbent 167 operator and a number of alternative ones, on the network 168 infrastructure of the former. Existing proposals are based on the 169 use of PIM routing from the metro network, and multicast traffic 170 aggregation on the same tree. A different approach could be achieved 171 with the use of an MLD proxy with multiple upstream interfaces, each 172 of them pointing to a distinct multicast router in the metro border 173 which is part of separated multicast trees deep in the network. 174 Figure 2 graphically describes this scenario. 176 In the case of mobile networks, IP mobility services guarantee the 177 continuity of the IP session while a Mobile Node (MN) changes its 178 point of attachment. Proxy Mobile IPv6 (PMIPv6) RFC5213 [RFC5213] 179 standardized a protocol that allows the network to manage the MN 180 mobility without requiring specific support from the mobile terminal. 181 The traffic to the MN is tunneled from the Home Network making use of 182 two entities, one acting as mobility anchor, and the other as 183 Mobility Access Gateway (MAG). Multicast support in PMIPv6 RFC6224 184 [RFC6224] implies the delivery of all the multicast traffic from the 185 Home Network, via the mobility anchor. However, multicast routing 186 optimization [I-D.ietf-multimob-pmipv6-ropt] could take advantage of 187 an MLD proxy with multiple upstream interfaces by supporting the 188 decision of subscribing a multicast content from the Home Network or 189 from the local PMIPv6 domain if it is locally available. Figure 3 190 presents this scenario. 192 Informational text is provided in Appendix A summarizing how the 193 basic solution for deploying multicast listener mobility with Proxy 194 Mobile IPv6 works. 196 downstream upstream 197 interface interface A 198 | | 199 | | _______________ 200 | +--------+ v / \ 201 | | O-------( Multicast Set 1 ) 202 | | Aggr. | \_______________/ 203 +----+ v | Switch | (e.g. from the Incumbent 204 | AN |-------| | Operator) 205 +----+ | (MLD | _______________ 206 (e.g. | Proxy) | / \ 207 DSLAM) | O-------( Multicast Set 2 ) 208 +--------+ ^ \_______________/ 209 | (e.g. from an Alternative 210 | Operator) 211 | 212 upstream 213 interface B 215 Figure 2: Example of usage of an MLD proxy with multiple upstream 216 interfaces in a fixed network scenario 217 downstream upstream 218 interface interface A 219 | | 220 | | _______________ 221 | +--------+ v / \ 222 | | O-------( Multicast Set 1 ) 223 | | | \_______________/ 224 +----+ v | MAG | e.g. from the Home Network 225 | MN |-------| | via the mobility anchor) 226 +----+ | (MLD | _______________ 227 | Proxy) | / \ 228 | O-------( Multicast Set 2 ) 229 +--------+ ^ \_______________/ 230 | (e.g. from the local PMIPv6 231 | domain via direct routing) 232 | 233 upstream 234 interface B 236 Figure 3: Example of usage of an MLD proxy with multiple upstream 237 interfaces in a mobile network scenario 239 Since those scenarios can motivate distinct needs in terms of MLD 240 proxy functionality, it is necessary to consider a comprehensive 241 approach, looking at the possible scenarios, and establishing a 242 minimum set of requirements which can allow the operation of a 243 versatile MLD proxy with multiple upstream interfaces as a common 244 entity to all of them (i.e., no different kinds of proxies depending 245 on the scenario, but a common proxy applicable to all the potential 246 scenarios). 248 4. Scenarios of applicability 250 This section describes in detail a number of scenarios of 251 applicability of an MLD proxy with multiple upstream interfaces in 252 place. A number of requirements for the MLD proxy functionality are 253 identified from those scenarios. 255 4.1. Fixed network scenarios 257 Residential broadband users get access to multiple IP services 258 through fixed network infrastructures. End user's equipment is 259 connected to an access node, and the traffic of a number of access 260 nodes is collected in aggregation switches. 262 For the multicast service, the use of an MLD proxy with multiple 263 upstream interfaces in those switches can provide service flexibility 264 in a lightweight and simpler manner if compared with PIM-routing 265 based alternatives. 267 4.1.1. Multicast wholesale offer for residential services 269 This scenario has been already introduced in the previous section, 270 and can be seen in Figure 2. There are two different operators, the 271 one operating the fixed network where the end user is connected 272 (e.g., typically an incumbent operator), and the one providing the 273 Internet service to the end user (e.g., an alternative Internet 274 service provider). Both can offer multicast streams that can be 275 subscribed by the end user, independently of which provider 276 contributes with the content. 278 Note that it is assumed that both providers offer distinct multicast 279 groups. However, more than one subscription to multicast channels of 280 different providers could take place simultaneously. 282 4.1.1.1. Requirements 284 o The MLD proxy should be able to deliver multicast control messages 285 sent by the end user to the corresponding provider's multicast 286 router. 288 o The MLD proxy should be able to deliver multicast control messages 289 sent by each of the providers to the corresponding end user. 291 4.1.2. Multicast resiliency 293 In current PIM-based solutions, the resiliency of the multicast 294 distribution relays on the routing capabilities provided by protocols 295 like PIM and VRRP. A simpler scheme could be achieved by 296 implementing different upstream interfaces on MLD proxies, providing 297 path diversity through the connection to distinct leaves of a given 298 multicast tree. 300 It is assumed that only one of the upstream interfaces is active in 301 receiving the multicast content, while the other is up and in standby 302 for fast switching. 304 4.1.2.1. Requirements 306 o The MLD proxy should be able to deliver multicast control messages 307 sent by the end user to the corresponding active upstream 308 interface. 310 o The MLD proxy should be able to deliver multicast control messages 311 received in the active upstream to the end users, while ignoring 312 the control messages of the standby upstream interface. 314 o The MLD proxy should be able of rapidly switching from the active 315 to the standby upstream interface in case of network failure, 316 transparently to the end user. 318 4.1.3. Load balancing for multicast traffic in the metro segment 320 A single upstream interface in existing MLD proxy functionality 321 typically forces the distribution of all the channels on the same 322 path in the last segment of the network. Multiple upstream 323 interfaces could naturally split the demand, alleviating the 324 bandwidth requirements in the metro segment. 326 4.1.3.1. Requirements 328 o The MLD proxy should be able to deliver multicast control messages 329 sent by the end user to the corresponding multicast router which 330 provides the channel of interest. 332 o The MLD proxy should be able to deliver multicast control messages 333 sent by each of the multicast routers to the corresponding end 334 user. 336 o The MLD proxy should be able to decide which upstream interface is 337 selected for any new channel request according to defined criteria 338 (e.g., load balancing). 340 4.1.4. Summary of the requirements needed for mobile network scenarios 342 Following the analysis above, a number of different requirements can 343 be identified by the MLD proxy to support multiple upstream 344 interfaces in fixed network scenarios. The following table 345 summarizes these requirements. 347 +-----------------------------------+ 348 | Fixed Network Scenarios | 349 +---------+-----------+-----------+-----------+ 350 |Functio- | Multicast | Multicast | Load | 351 |nality | Wholesale | Resiliency| Balancing | 352 +---------+-----------+-----------+-----------+ 353 |Upstream | | | | 354 |Control | X | X | X | 355 |Delivery | | | | 356 +---------+-----------+-----------+-----------+ 357 |Downstr. | | | | 358 |Control | X | X | X | 359 |Delivery | | | | 360 +---------+-----------+-----------+-----------+ 361 |Active / | | | | 362 |Standby | | X | | 363 |Upstream | | | | 364 +---------+-----------+-----------+-----------+ 365 |Upstr i/f| | | | 366 |selection| | | X | 367 |per group| | | | 368 +---------+-----------+-----------+-----------+ 369 |Upstr i/f| | | | 370 |selection| | X | | 371 |all group| | | | 372 +---------+-----------+-----------+-----------+ 374 Figure 4: Functionality needed on MLD proxy with multiple upstream 375 interfaces per application scenario in fixed networks 377 4.2. Mobile network scenarios 379 The mobile networks considered in this document are supposed to run 380 PMIPv6 protocol for IP mobility management. A brief description of 381 multicast provision in PMIPv6-based networks can be found in Appendix 382 A. 384 The use of an MLD proxy supporting multiple upstream interfaces can 385 improve the performance and the scalability of multicast-capable 386 PMIPv6 domains. 388 4.2.1. Applicability to multicast listener mobility 390 Three sub-cases can be identified for the multicast listener 391 mobility. 393 4.2.1.1. Single MLD proxy instance on MAG 395 The base solution for multicast service in PMIPv6 RFC6224 [RFC6224] 396 assumes that any MN subscribed to multicast services receive the 397 multicast traffic through the associated LMA, as in the unicast case. 398 As standard MLD proxy functionality only supports one upstream 399 interface, the MAG should implement several separated MLD proxy 400 instances, one per LMA, in order to serve the multicast traffic to 401 the MNs, according to any particular LMA-MN association. 403 A way of avoiding the multiplicity of MLD proxy instance in a MAG is 404 to deploy a unique MLD proxy instance with multiple upstream 405 interfaces, one per LMA, without any change in the multicast traffic 406 distribution. 408 4.2.1.1.1. Requirements 410 o The MLD proxy should be able of delivering the multicast control 411 messages sent by the MNs to the associated LMA. 413 o The MLD proxy should be able of delivering the multicast control 414 messages sent by each of the connected LMAs to the corresponding 415 MN. 417 o The MLD proxy should be able of routing the multicast data coming 418 from different LMAs to the corresponding MNs according to the MN 419 to LMA association. 421 o The MLD proxy should be able of maintaining a 1:1 association 422 between an MN and LMA (or downstream to upstream). 424 4.2.1.2. Remote and local multicast subscription 426 This scenario has been already introduced in the previous section, 427 and can be seen in Figure 3. Standard MLD proxy definition, with a 428 unique upstream interface per proxy, does not allow the reception of 429 multicast traffic from distinct upstream multicast routers. In other 430 words, all the multicast traffic being sent to the MLD proxy in 431 downstream traverses a concrete, unique router before reaching the 432 MAG. There are, however, situations where different multicast 433 content could reach the MLD proxy through distinct next-hop routers. 435 For instance, the solution adopted to avoid the tunnel convergence 436 problem in basic multicast PMIPv6 deployments 437 [I-D.ietf-multimob-pmipv6-ropt] considers the possibility of 438 subscription to a multicast source local to the PMIPv6 domain. In 439 that situation, some multicast content will be accesses remotely, 440 through the home network via the multicast tree mobility anchor, 441 while some other multicast content will reach the proxy directly, via 442 a local router in the domain. 444 4.2.1.2.1. Requirements 446 o The MLD proxy should be able of delivering the multicast control 447 messages sent by the MNs to the associated upstream interface 448 based on the location of the source, remote or local, for a 449 certain multicast group. 451 o The MLD proxy should be able of delivering the multicast control 452 messages sent either local or remotely to the corresponding MNs. 454 o The MLD proxy should be able of routing the multicast data coming 455 from different upstream interfaces to a certain MN according to 456 the MN subscription, either local or remote. Note that it is 457 assumed that a multicast group can be subscribed either locally or 458 remotely, but not simultaneously. However more than one 459 subscription could happen, being local or remote independently. 461 o The MLD proxy should be able of maintaining a 1:N association 462 between an MN and the remote and local multicast router (or 463 downstream to upstream). 465 o The MLD proxy should be able of switching between local or remote 466 subscription for per multicast group according to specific 467 configuration parameters (out of the scope of this document). 469 4.2.1.3. Dual subscription to multicast groups during handover 471 In the event of an MN handover, once an MN moves from a previous MAG 472 (pMAG) to a new MAG (nMAG), the nMAG needs to set up the multicast 473 status for the incoming MN, and subscribe the multicast channels it 474 was receiving before the handover event. The MN will then experience 475 a certain delay until it receives again the subscribed content. 477 A generic solution is being defined in 478 [I-D.ietf-multimob-handover-optimization] to speed up the knowledge 479 of the ongoing subscription by the nMAG. However, for the particular 480 case that the underlying radio access technology supports layer-2 481 triggers (thus requiring extra capabilities on the mobile node), 482 there could be inter-MAG cooperation for handover support if pMAG and 483 nMAG are known in advance. 485 This could be the case, for instance for those contents not already 486 arriving to the nMAG, where the nMAG temporally subscribes the 487 multicast groups of the ongoing MN's subscription via the pMAG, while 488 the multicast delivery tree among the nMAG and the mobility anchor is 489 being established. 491 A similar approach is followed in 492 [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] despite the solution 493 proposed there differs from this approach (i.e., there is no 494 consideration of an MLD proxy with multiple interfaces). 496 4.2.1.3.1. Requirements 498 o The MLD proxy should be able of delivering the multicast control 499 messages sent by the MNs to the associated upstream interface 500 based on the handover specific moment, for a certain multicast 501 group. 503 o The MLD proxy should be able of delivering the multicast control 504 messages sent either from pMAG or the multicast anchor to the 505 corresponding MNs, based on the handover specific moment. 507 o The MLD proxy should be able of handle the incoming packet flows 508 from the two simultaneous upstream interfaces, in order to not 509 duplicate traffic delivered on the point-to-point link to the MN. 511 o The MLD proxy should be able of maintaining a 1:N association 512 between an MN and both the remote multicast router and the pMAG 513 (or downstream to upstream). 515 o The MLD proxy should be able of switching between local or remote 516 subscription for all the multicast groups (from pMAG to multicast 517 anchor) according to specific configuration parameters (out of the 518 scope of this document). 520 4.2.2. Applicability to multicast source mobility 522 A couple of sub-cases can be identified for the multicast source 523 mobility. 525 4.2.2.1. Support of remote and direct subscription in basic source 526 mobility 528 In the basic case of source mobility, the multicast source is 529 connected to one of the downstream interfaces of an MLD proxy. 530 According to the standard specification RFC4605 [RFC4605] every 531 packet sent by the multicast source will be forwarded towards the 532 root of the multicast tree. 534 However, linked to the mobility listener problem, there could be the 535 case of simultaneous remote subscribers, subscribing to the multicast 536 content through the home network, and local subscribers, requesting 537 the contents directly via a multicast router residing on the same 538 PMIPv6 domain where the source is attached to. 540 Then, in order to provide the co-existence of both types of 541 subscribers, an MLD proxy with two upstream interfaces could 542 simultaneously serve all kind of multicast subscribers. 544 Basic source mobility is being defined in RFC4605 [RFC4605] but the 545 solution proposed there does not allow simultaneous co-existence of 546 remote and local subscribers (i.e., the content sent by the source is 547 either distributed locally to a multicast router in the PMIPv6 548 domain, or remotely by using the bi-directional tunnel towards the 549 mobility anchor, but not both simultaneously). 551 4.2.2.1.1. Requirements 553 o The MLD proxy should be able of forwarding (replicating) the 554 multicast content to both upstream interfaces, in case of 555 simultaneous remote and local distribution. 557 o The MLD proxy should be able of handling control information 558 incoming through any of the two upstream interfaces, providing the 559 expected behavior for each of the multicast trees. 561 o The MLD proxy should be able of routing the multicast data towards 562 different upstream interfaces for both remote and local 563 subscriptions that could happen simultaneously. 565 o The MLD proxy should be able of maintaining a 1:N association 566 between an MN and both the remote and local multicast router (or 567 downstream to upstream). 569 4.2.2.2. Direct communication between source and listener associated 570 with distinct LMAs but on the same MAG 572 In a certain PMIPv6 domain can be MNs associated to distinct LMAs 573 using the same MAG to get access to their corresponding home 574 networks. For multicast communication, according to the base 575 solution RFC6224 [RFC6224], each MN - LMA association implies a 576 distinct MLD proxy instance to be invoked in the MAG. 578 In these conditions, when a mobile source is serving multicast 579 content to a mobile listener, both attached to the same MAG but each 580 of them associated to different LMAs, the multicast flow must 581 traverse the PMIPv6 domain from the MAG to the LMA where the source 582 maintains an association, then from that LMA to the LMA where the 583 listener is associated to, and finally come back to the same MAG from 584 where the flow departed. This routing is extremely inefficient. 586 An MLD proxy with multiple upstream interfaces avoids this behavior 587 since it allows to invoke a unique MLD proxy instance in the MAG. In 588 this case, the multicast source can directly communicate with the 589 multicast listener, without need for delivering the multicast traffic 590 to the LMAs. 592 4.2.2.2.1. Requirements 594 o The MLD proxy should be able of forwarding (replicating) the 595 multicast content to different upstream or downstream interfaces 596 where subscribers are present. 598 o The MLD proxy should be able of handling control information 599 incoming through any of the upstream or downstream interfaces 600 requesting a multicast flow being injected in another downstream 601 interface. 603 o The MLD proxy should be able of maintaining a 1:N association 604 between an MN and any of the upstream or downstream interfaces 605 demanding the multicast content. 607 4.2.2.3. Route optimization support in source mobility for remote 608 subscribers 610 Even in a scenario of remote subscription, there could be the case 611 where both the source and the listener are attached to the same 612 PMIPv6-Domain (for instance, no possibility of direct routing within 613 the PMIPv6, or source and listener pertaining to distinct home 614 networks). In this situation there is a possibility of route 615 optimization if inter-MAG communication is enabled, in such a way 616 that the listeners in the PMIPv6 domain are served through the 617 tunnels between MAGs, while the rest of remote listeners are served 618 through the mobility anchor. 620 A multi-upstream MLD proxy would allow the simultaneous delivery of 621 traffic to such kind of remote listeners. 623 A similar route optimization approach is proposed in 624 [I-D.liu-multimob-pmipv6-multicast-ro]. 626 4.2.2.3.1. Requirements 628 o The MLD proxy should be able of forwarding (replicating) the 629 multicast content to both kinds of upstream interfaces, inter-MAG 630 tunnel interfaces and MAG to mobility anchor tunnel interface. 632 o The MLD proxy should be able of handling control information 633 incoming through any of the two types of upstream interfaces, 634 providing the expected behavior for each of the multicast trees 635 (e.g., no forwarding traffic on one inter-MAG link once there are 636 not more listeners requesting the content). 638 o The MLD proxy should be able of routing the multicast data towards 639 different upstream interfaces for both remote and route optimized 640 subscriptions that could happen simultaneously. 642 o The MLD proxy should be able of maintaining a 1:N association 643 between an MN and both the remote and local MAGs (or downstream to 644 upstream). 646 4.2.3. Summary of the requirements needed for mobile network scenarios 648 After the previous analysis, a number of different requirements can 649 be identified by the MLD proxy to support multiple upstream 650 interfaces in mobile network scenarios. The following table 651 summarizes these requirements. 653 +----------------------------------------------------+ 654 | Mobile Network Scenarios | 655 +--------------------------+-------------------------+ 656 | Mulicast Listener | Mulicast Source | 657 +---------+--------+--------+--------+--------+--------+-------+ 658 | | Single| Remote | Dual | Direct |Listener| Route | 659 |Functio- | MLD |& local | subscr.|& remote|& source|optimi.| 660 |nality | Proxy | subscr.| in HO | subscr.| on MAG | | 661 +---------+--------+--------+--------+--------+--------+-------+ 662 |Upstream | | | | | | | 663 |Control | X | X | X | X | X | X | 664 |Delivery | | | | | | | 665 +---------+--------+--------+--------+--------+--------+-------+ 666 |Downstr. | | | | | | | 667 |Control | X | X | X | | X | | 668 |Delivery | | | | | | | 669 +---------+--------+--------+--------+--------+--------+-------+ 670 |Upstream | | | | | | | 671 |Data | | | | X | | X | 672 |Delivery | | | | | | | 673 +---------+--------+--------+--------+--------+--------+-------+ 674 |Downstr. | | | | | | | 675 |Data | X | X | X | | X | | 676 |Delivery | | | | | | | 677 +---------+--------+--------+--------+--------+--------+-------+ 678 |1:1 MN to| | | | | | | 679 |upstream | X | | | | | | 680 |assoc. | | | | | | | 681 +---------+--------+--------+--------+--------+--------+-------+ 682 |1:N MN to| | | | | | | 683 |upstream | | X | X | X | X | X | 684 |assoc. | | | | | | | 685 +---------+--------+--------+--------+--------+--------+-------+ 686 |Upstr i/f| | | | | | | 687 |selection| | X | | | | | 688 |per group| | | | | | | 689 +---------+--------+--------+--------+--------+--------+-------+ 690 |Upstr i/f| | | | | | | 691 |selection| | | X | | | | 692 |all group| | | | | | | 693 +---------+--------+--------+--------+--------+--------+-------+ 694 |Upstream | | | | | | | 695 |traffic | | | | X | | X | 696 |replicat.| | | | | | | 697 +---------+--------+--------+--------+--------+--------+-------+ 699 Figure 5: Functionality needed on MLD proxy with multiple upstream 700 interfaces per application scenario in mobile networks 702 5. Functional specification of an MLD proxy with multiple interfaces 704 To be completed 706 6. Security Considerations 708 To be completed 710 7. IANA Considerations 712 To be completed 714 8. Acknowledgments 716 The authors thank Stig Venaas for his valuable comments and 717 suggestions. 719 The research of Carlos J. Bernardos leading to these results has 720 received funding from the European Community's Seventh Framework 721 Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL 722 project), being also partially supported by the Ministry of Science 723 and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 724 13992-C02-01). 726 9. References 728 9.1. Normative References 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, March 1997. 733 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 734 "Internet Group Management Protocol (IGMP) / Multicast 735 Listener Discovery (MLD)-Based Multicast Forwarding 736 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 738 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 739 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 741 9.2. Informative References 743 [I-D.ietf-multimob-handover-optimization] 744 Contreras, L., Bernardos, C., and I. Soto, "PMIPv6 745 multicast handover optimization by the Subscription 746 Information Acquisition through the LMA (SIAL)", 747 draft-ietf-multimob-handover-optimization-02 (work in 748 progress), February 2013. 750 [I-D.ietf-multimob-pmipv6-ropt] 751 Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. 752 Kim, "Multicast Mobility Routing Optimizations for Proxy 753 Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-06 (work in 754 progress), June 2013. 756 [I-D.liu-multimob-pmipv6-multicast-ro] 757 Liu, J. and W. Luo, "Routes Optimization for Multicast 758 Sender in Proxy Mobile IPv6 Domain", 759 draft-liu-multimob-pmipv6-multicast-ro-02 (work in 760 progress), July 2012. 762 [I-D.schmidt-multimob-fmipv6-pfmipv6-multicast] 763 Schmidt, T., Waehlisch, M., Koodli, R., and G. Fairhurst, 764 "Multicast Listener Extensions for MIPv6 and PMIPv6 Fast 765 Handovers", 766 draft-schmidt-multimob-fmipv6-pfmipv6-multicast-07 (work 767 in progress), October 2012. 769 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 770 Deployment for Multicast Listener Support in Proxy Mobile 771 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 773 Appendix A. Basic support for multicast listener with PMIPv6 775 This section briefly summarizes the operation of Proxy Mobile IPv6 776 RFC5213 [RFC5213] and how multicast listener support works with 777 PMIPv6 as specified in RFC6224 [RFC6224]. 779 Proxy Mobile IPv6 (PMIPv6) RFC5213 [RFC5213] is a network-based 780 mobility management protocol which enables the network to provide 781 mobility support to standard IP terminals residing in the network. 782 These terminals enjoy this mobility service without being required to 783 implement any mobility-specific IP operations. Namely, PMIPv6 is one 784 of the mechanisms adopted by the 3GPP to support the mobility 785 management of non-3GPP terminals in future Evolved Packet System 786 (EPS) networks. 788 PMIPv6 allows a Media Access Gateway (MAG) to establish a distinct 789 bi-directional tunnel with different Local Mobility Anchors (LMAs), 790 being each tunnel shared by the attached Mobile Nodes (MNs). Each 791 mobile node is associated with a corresponding LMA, which keeps track 792 of its current location, that is, the MAG where the mobile node is 793 attached. IP-in-IP encapsulation is used within the tunnel to 794 forward traffic between the LMA and the MAG. Figure 4 (taken from 795 RFC5213 [RFC5213]) shows the architecture of a PMIPv6 domain. 797 +----+ +----+ 798 |LMA1| |LMA2| 799 +----+ +----+ 800 LMAA1 -> | | <-- LMAA2 801 | | 802 \\ //\\ 803 \\ // \\ 804 \\ // \\ 805 +---\\------------- //------\\----+ 806 ( \\ IPv4/IPv6 // \\ ) 807 ( \\ Network // \\ ) 808 +------\\--------//------------\\-+ 809 \\ // \\ 810 \\ // \\ 811 \\ // \\ 812 Proxy-CoA1--> | | <-- Proxy-CoA2 813 +----+ +----+ 814 |MAG1|-----{MN2} |MAG2| 815 +----+ | +----+ 816 | | | 817 MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4 818 {MN1} {MN3} 820 Figure 6: Proxy Mobile IPv6 Domain 822 The basic solution for the distribution of multicast traffic within a 823 PMIPv6 domain RFC6224 [RFC6224] makes use of the bi-directional LMA- 824 MAG tunnels. The base solution follows the so-called remote 825 subscription model, in which the subscribed multicast content is 826 delivered from the Home Network. By doing so, an individual copy of 827 every multicast flow is delivered through the tunnel connecting the 828 mobility anchor to any of the access gateways in the domain. In many 829 cases, these individual copies traverse the same routers in the path 830 towards the access gateways, incurring in an inefficient 831 distribution, equivalent to the unicast distribution of the multicast 832 content in the domain. 834 The reference scenario for multicast deployment in Proxy Mobile IPv6 835 domains is illustrated in Figure 5 (taken from RFC6224 [RFC6224]). 837 This fact leads to distribution inefficiencies and higher per-bit 838 delivery costs, incurred by the PMIPv6 domain operator offering 839 transport capabilities to the Home Network operator for serving their 840 MNs when attached to the PMIPv6 domain. As long as the remotely 841 subscribed multicast service is not affected, it seems worthy to 842 explore more optimal ways of distributing such content within the 843 PIMPv6 domain. 845 +-------------+ 846 | Content | 847 | Source | 848 +-------------+ 849 | 850 *** *** *** *** 851 * ** ** ** * 852 * * 853 * Fixed Internet * 854 * * 855 * ** ** ** * 856 *** *** *** *** 857 / 858 +----+ +----+ 859 |LMA1| |LMA2| Multicast Anchor 860 +----+ +----+ 861 LMAA1 | | LMAA2 862 | | 863 \\ //\\ 864 \\ // \\ 865 \\ // \\ Unicast Tunnel 866 \\ // \\ 867 \\ // \\ 868 \\ // \\ 869 Proxy-CoA1 || || Proxy-CoA2 870 +----+ +----+ 871 |MAG1| |MAG2| MLD Proxy 872 +----+ +----+ 873 | | | 874 MN-HNP1 | | MN-HNP2 | MN-HNP3 875 MN1 MN2 MN3 877 Figure 7: Reference Network for Multicast Deployment in PMIPv6 879 Authors' Addresses 881 Luis M. Contreras 882 Telefonica I+D 883 Ronda de la Comunicacion, s/n 884 Sur-3 building, 3rd floor 885 Madrid 28050 886 Spain 888 Email: lmcm@tid.es 890 Carlos J. Bernardos 891 Universidad Carlos III de Madrid 892 Av. Universidad, 30 893 Leganes, Madrid 28911 894 Spain 896 Phone: +34 91624 6236 897 Email: cjbc@it.uc3m.es 898 URI: http://www.it.uc3m.es/cjbc/ 900 Juan Carlos 901 InterDigital Communications, LLC 902 1000 Sherbrooke Street West, 10th floor 903 Montreal, Quebec H3A 3G4 904 Canada 906 Email: JuanCarlos.Zuniga@InterDigital.com