idnits 2.17.1 draft-contreras-multimob-multiple-upstreams-01.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 date (February 25, 2013) is 4071 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 6224 (ref. '2') == Outdated reference: A later version (-08) exists of draft-ietf-multimob-pmipv6-ropt-01 == Outdated reference: A later version (-03) exists of draft-ietf-multimob-fast-handover-01 == Outdated reference: A later version (-07) exists of draft-schmidt-multimob-fmipv6-pfmipv6-multicast-06 == Outdated reference: A later version (-09) exists of draft-ietf-multimob-pmipv6-source-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group Luis M. Contreras 3 INTERNET-DRAFT Telefonica I+D 4 Intended Status: Proposed Standard Carlos J. Bernardos 5 Expires: April 18, 2013 Universidad Carlos III de Madrid 6 Juan Carlos Zuniga 7 InterDigital 8 February 25, 2013 10 Extension of the MLD proxy functionality to support multiple 11 upstream interfaces 12 draft-contreras-multimob-multiple-upstreams-01 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 to IETF 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), its areas, and its working groups. Note that 34 other groups may also distribute working documents as 35 Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2012 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Scenarios of applicability . . . . . . . . . . . . . . . . . . 7 69 4.1 Fixed network scenarios . . . . . . . . . . . . . . . . . . 7 70 4.1.1 Multicast wholesale offer for residential services . . 7 71 4.1.1.1 Requirements . . . . . . . . . . . . . . . . . . . 7 72 4.1.2 Multicast resiliency . . . . . . . . . . . . . . . . . 8 73 4.1.2.1 Requirements . . . . . . . . . . . . . . . . . . . 8 74 4.1.3 Load balancing for multicast traffic in the metro 75 segment . . . . . . . . . . . . . . . . . . . . . . . . 8 76 4.1.3.1 Requirements . . . . . . . . . . . . . . . . . . . 8 77 4.1.4 Summary of the requirements needed for mobile network 78 scenarios . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.2 Mobile network scenarios . . . . . . . . . . . . . . . . . 9 80 4.2.1 Applicability to multicast listener mobility . . . . . 10 81 4.2.1.1 Single MLD proxy instance on MAG . . . . . . . . . 10 82 4.2.1.1.1 Requirements . . . . . . . . . . . . . . . . . 10 83 4.2.1.2 Remote and local multicast subscription . . . . . . 10 84 4.2.1.2.1 Requirements . . . . . . . . . . . . . . . . . 11 85 4.2.1.3 Dual subscription to multicast groups during 86 handover . . . . . . . . . . . . . . . . . . . . . 11 87 4.2.1.3.1 Requirements . . . . . . . . . . . . . . . . . 12 88 4.2.2 Applicability to multicast source mobility . . . . . . 12 89 4.2.2.1 Support of remote and direct subscription in 90 basic source mobility . . . . . . . . . . . . . . . 12 91 4.2.2.1.1 Requirements . . . . . . . . . . . . . . . . . 13 92 4.2.2.2 Direct communication between source and listener 93 associated with distinct LMAs but on the same MAG . 13 95 4.2.2.3.1 Requirements . . . . . . . . . . . . . . . . . 14 96 4.2.2.3 Route optimization support in source mobility for 97 remote subscribers . . . . . . . . . . . . . . . . 14 98 4.2.2.3.1 Requirements . . . . . . . . . . . . . . . . . 14 99 4.2.3 Summary of the requirements needed for mobile network 100 scenarios . . . . . . . . . . . . . . . . . . . . . . . 15 101 5 Functional specification of an MLD proxy with multiple 102 interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . 17 103 6 Security Considerations . . . . . . . . . . . . . . . . . . . . 17 104 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 17 105 8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 17 106 9 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 107 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 108 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 109 10.2 Informative References . . . . . . . . . . . . . . . . . . 17 110 Appendix A. Basic support for multicast listener with PMIPv6 . . 18 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 113 1 Introduction 115 The aim of this document is to define the functionality that an MLD 116 proxy with multiple upstream interfaces should have in order to 117 support different scenarios of applicability in both fixed and mobile 118 networks. This compatibility is needed in order to simplify node 119 functionality and to ensure an easier deployment of multicast 120 capabilities in all the use cases described in this document. 122 2. Terminology 124 This document uses the terminology defined in [3]. Specifically, the 125 definition of Upstream and Downstream interfaces, which are 126 reproduced here for completeness. 128 Upstream interface: 129 A proxy device's interface in the direction of the root of the 130 tree. Also called the "Host interface". 132 Downstream interface: 133 Each of a proxy device's interfaces that is not in the direction 134 of the root of the tree. Also called the "Router interfaces". 136 3. Problem statement 138 The concept of MLD proxy with several upstream interfaces has emerged 139 as a way of optimizing (and in some cases enabling) service delivery 140 scenarios where separate multicast service providers are reachable 141 through the same access network infrastructure. Figure 1 presents the 142 conceptual model under consideration. 144 downstream upstream 145 interface interface A 146 | | 147 | | _______________ 148 | +-------+ v / \ 149 | | O-------( Multicast Set 1 ) 150 +----------+ v | MLD | \_______________/ 151 | Listener |------| | _______________ 152 +----------+ | Proxy | / \ 153 | O-------( Multicast Set 2 ) 154 +-------+ ^ \_______________/ 155 | 156 | 157 upstream 158 interface B 160 Figure 1. Concept of MLD proxy with multiple upstream interfaces 162 For illustrative purposes, two applications for fixed and mobile 163 networks are here introduced. They will be elaborated later on the 164 document. 166 In the case of fixed networks, multicast wholesale services in a 167 competitive residential market require an efficient distribution of 168 multicast traffic from different operators, i.e. the incumbent 169 operator and a number of alternative ones, on the network 170 infrastructure of the former. Existing proposals are based on the use 171 of PIM routing from the metro network, and multicast traffic 172 aggregation on the same tree. A different approach could be achieved 173 with the use of an MLD proxy with multiple upstream interfaces, each 174 of them pointing to a distinct multicast router in the metro border 175 which is part of separated multicast trees deep in the network. 176 Figure 2 graphically describes this scenario. 178 In the case of mobile networks, IP mobility services guarantee the 179 continuity of the IP session while a Mobile Node (MN) changes its 180 point of attachment. Proxy Mobile IPv6 (PMIPv6) [1] standardized a 181 protocol that allows the network to manage the MN mobility without 182 requiring specific support from the mobile terminal. The traffic to 183 the MN is tunneled from the Home Network making use of two entities, 184 one acting as mobility anchor, and the other as Mobility Access 185 Gateway (MAG). Multicast support in PMIPv6 [2] implies the delivery 186 of all the multicast traffic from the Home Network, via the mobility 187 anchor. However, multicast routing optimization [4] could take 188 advantage of an MLD proxy with multiple upstream interfaces by 189 supporting the decision of subscribing a multicast content from the 190 Home Network or from the local PMIPv6 domain if it is locally 191 available. Figure 3 presents this scenario. 193 Informational text is provided in Appendix A summarizing how the 194 basic solution for deploying multicast listener mobility with Proxy 195 Mobile IPv6 works. 197 downstream upstream 198 interface interface A 199 | | 200 | | _______________ 201 | +--------+ v / \ 202 | | O-------( Multicast Set 1 ) 203 | | Aggr. | \_______________/ 204 +----+ v | Switch | (e.g. from the Incumbent 205 | AN |-------| | Operator) 206 +----+ | (MLD | _______________ 207 (e.g. | Proxy) | / \ 208 DSLAM) | O-------( Multicast Set 2 ) 209 +--------+ ^ \_______________/ 210 | (e.g. from an Alternative 211 | Operator) 212 | 213 upstream 214 interface B 216 Figure 2. Example of usage of an MLD proxy with multiple 217 upstream interfaces in a fixed network scenario 219 downstream upstream 220 interface interface A 221 | | 222 | | _______________ 223 | +--------+ v / \ 224 | | O-------( Multicast Set 1 ) 225 | | | \_______________/ 226 +----+ v | MAG | e.g. from the Home Network 227 | MN |-------| | via the mobility anchor) 228 +----+ | (MLD | _______________ 229 | Proxy) | / \ 230 | O-------( Multicast Set 2 ) 231 +--------+ ^ \_______________/ 232 | (e.g. from the local PMIPv6 233 | domain via direct routing) 234 | 235 upstream 236 interface B 238 Figure 3. Example of usage of an MLD proxy with multiple 239 upstream interfaces in a mobile network scenario 241 Since those scenarios can motivate distinct needs in terms of MLD 242 proxy functionality, it is necessary to consider a comprehensive 243 approach, looking at the possible scenarios, and establishing a 244 minimum set of requirements which can allow the operation of a 245 versatile MLD proxy with multiple upstream interfaces as a common 246 entity to all of them (i.e., no different kinds of proxies depending 247 on the scenario, but a common proxy applicable to all the potential 248 scenarios). 250 4. Scenarios of applicability 252 This section describes in detail a number of scenarios of 253 applicability of an MLD proxy with multiple upstream interfaces in 254 place. A number of requirements for the MLD proxy functionality are 255 identified from those scenarios. 257 4.1 Fixed network scenarios 259 Residential broadband users get access to multiple IP services 260 through fixed network infrastructures. End user's equipment is 261 connected to an access node, and the traffic of a number of access 262 nodes is collected in aggregation switches. 264 For the multicast service, the use of an MLD proxy with multiple 265 upstream interfaces in those switches can provide service flexibility 266 in a lightweight and simpler manner if compared with PIM-routing 267 based alternatives. 269 4.1.1 Multicast wholesale offer for residential services 271 This scenario has been already introduced in the previous section, 272 and can be seen in Figure 2. There are two different operators, the 273 one operating the fixed network where the end user is connected 274 (e.g., typically an incumbent operator), and the one providing the 275 Internet service to the end user (e.g., an alternative Internet 276 service provider). Both can offer multicast streams that can be 277 subscribed by the end user, independently of which provider 278 contributes with the content. 280 Note that it is assumed that both providers offer distinct multicast 281 groups. However, more than one subscription to multicast channels of 282 different providers could take place simultaneously. 284 4.1.1.1 Requirements 286 - The MLD proxy should be able to deliver multicast control messages 287 sent by the end user to the corresponding provider's multicast 288 router. 290 - The MLD proxy should be able to deliver multicast control messages 291 sent by each of the providers to the corresponding end user. 293 4.1.2 Multicast resiliency 295 In current PIM-based solutions, the resiliency of the multicast 296 distribution relays on the routing capabilities provided by protocols 297 like PIM and VRRP. A simpler scheme could be achieved by implementing 298 different upstream interfaces on MLD proxies, providing path 299 diversity through the connection to distinct leaves of a given 300 multicast tree. 302 It is assumed that only one of the upstream interfaces is active in 303 receiving the multicast content, while the other is up and in standby 304 for fast switching. 306 4.1.2.1 Requirements 308 - The MLD proxy should be able to deliver multicast control messages 309 sent by the end user to the corresponding active upstream interface. 311 - The MLD proxy should be able to deliver multicast control messages 312 received in the active upstream to the end users, while ignoring the 313 control messages of the standby upstream interface. 315 - The MLD proxy should be able of rapidly switching from the active 316 to the standby upstream interface in case of network failure, 317 transparently to the end user. 319 4.1.3 Load balancing for multicast traffic in the metro segment 321 A single upstream interface in existing MLD proxy functionality 322 typically forces the distribution of all the channels on the same 323 path in the last segment of the network. Multiple upstream interfaces 324 could naturally split the demand, alleviating the bandwidth 325 requirements in the metro segment. 327 4.1.3.1 Requirements 329 - The MLD proxy should be able to deliver multicast control messages 330 sent by the end user to the corresponding multicast router which 331 provides the channel of interest. 333 - The MLD proxy should be able to deliver multicast control messages 334 sent by each of the multicast routers to the corresponding end user. 336 - 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 summarizes 345 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 Table I. Functionality needed on MLD proxy with multiple 375 upstream 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 [2] assumes that 396 any MN subscribed to multicast services receive the multicast traffic 397 through the associated LMA, as in the unicast case. As standard MLD 398 proxy functionality only supports one upstream interface, the MAG 399 should implement several separated MLD proxy instances, one per LMA, 400 in order to serve the multicast traffic to the MNs, according to any 401 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 - The MLD proxy should be able of delivering the multicast control 411 messages sent by the MNs to the associated LMA. 413 - The MLD proxy should be able of delivering the multicast control 414 messages sent by each of the connected LMAs to the corresponding MN. 416 - The MLD proxy should be able of routing the multicast data coming 417 from different LMAs to the corresponding MNs according to the MN to 418 LMA association. 420 - The MLD proxy should be able of maintaining a 1:1 association 421 between an MN and LMA (or downstream to upstream). 423 4.2.1.2 Remote and local multicast subscription 425 This scenario has been already introduced in the previous section, 426 and can be seen in Figure 3. Standard MLD proxy definition, with a 427 unique upstream interface per proxy, does not allow the reception of 428 multicast traffic from distinct upstream multicast routers. In other 429 words, all the multicast traffic being sent to the MLD proxy in 430 downstream traverses a concrete, unique router before reaching the 431 MAG. There are, however, situations where different multicast content 432 could reach the MLD proxy through distinct next-hop routers. 434 For instance, the solution adopted to avoid the tunnel convergence 435 problem in basic multicast PMIPv6 deployments [4] considers the 436 possibility of subscription to a multicast source local to the PMIPv6 437 domain. In that situation, some multicast content will be accesses 438 remotely, through the home network via the multicast tree mobility 439 anchor, while some other multicast content will reach the proxy 440 directly, via a local router in the domain. 442 4.2.1.2.1 Requirements 444 - The MLD proxy should be able of delivering the multicast control 445 messages sent by the MNs to the associated upstream interface based 446 on the location of the source, remote or local, for a certain 447 multicast group. 449 - The MLD proxy should be able of delivering the multicast control 450 messages sent either local or remotely to the corresponding MNs. 452 - The MLD proxy should be able of routing the multicast data coming 453 from different upstream interfaces to a certain MN according to the 454 MN subscription, either local or remote. Note that it is assumed that 455 a multicast group can be subscribed either locally or remotely, but 456 not simultaneously. However more than one subscription could happen, 457 being local or remote independently. 459 - The MLD proxy should be able of maintaining a 1:N association 460 between an MN and the remote and local multicast router (or 461 downstream to upstream). 463 - The MLD proxy should be able of switching between local or remote 464 subscription for per multicast group according to specific 465 configuration parameters (out of the scope of this document). 467 4.2.1.3 Dual subscription to multicast groups during handover 469 In the event of an MN handover, once an MN moves from a previous MAG 470 (pMAG) to a new MAG (nMAG), the nMAG needs to set up the multicast 471 status for the incoming MN, and subscribe the multicast channels it 472 was receiving before the handover event. The MN will then experience 473 a certain delay until it receives again the subscribed content. 475 A generic solution is being defined in [5] to speed up the knowledge 476 of the ongoing subscription by the nMAG. However, for the particular 477 case that the underlying radio access technology supports layer-2 478 triggers (thus requiring extra capabilities on the mobile node), 479 there could be inter-MAG cooperation for handover support if pMAG and 480 nMAG are known in advance. 482 This could be the case, for instance for those contents not already 483 arriving to the nMAG, where the nMAG temporally subscribes the 484 multicast groups of the ongoing MN's subscription via the pMAG, while 485 the multicast delivery tree among the nMAG and the mobility anchor is 486 being established. 488 A similar approach is followed in [6] despite the solution proposed 489 there differs from this approach (i.e., there is no consideration of 490 an MLD proxy with multiple interfaces). 492 4.2.1.3.1 Requirements 494 - The MLD proxy should be able of delivering the multicast control 495 messages sent by the MNs to the associated upstream interface based 496 on the handover specific moment, for a certain multicast group. 498 - The MLD proxy should be able of delivering the multicast control 499 messages sent either from pMAG or the multicast anchor to the 500 corresponding MNs, based on the handover specific moment. 502 - The MLD proxy should be able of handle the incoming packet flows 503 from the two simultaneous upstream interfaces, in order to not 504 duplicate traffic delivered on the point-to-point link to the MN. 506 - The MLD proxy should be able of maintaining a 1:N association 507 between an MN and both the remote multicast router and the pMAG (or 508 downstream to upstream). 510 - The MLD proxy should be able of switching between local or remote 511 subscription for all the multicast groups (from pMAG to multicast 512 anchor) according to specific configuration parameters (out of the 513 scope of this document). 515 4.2.2 Applicability to multicast source mobility 517 A couple of sub-cases can be identified for the multicast source 518 mobility. 520 4.2.2.1 Support of remote and direct subscription in basic source 521 mobility 523 In the basic case of source mobility, the multicast source is 524 connected to one of the downstream interfaces of an MLD proxy. 525 According to the standard specification [3] every packet sent by the 526 multicast source will be forwarded towards the root of the multicast 527 tree. 529 However, linked to the mobility listener problem, there could be the 530 case of simultaneous remote subscribers, subscribing to the multicast 531 content through the home network, and local subscribers, requesting 532 the contents directly via a multicast router residing on the same 533 PMIPv6 domain where the source is attached to. 535 Then, in order to provide the co-existence of both types of 536 subscribers, an MLD proxy with two upstream interfaces could 537 simultaneously serve all kind of multicast subscribers. 539 Basic source mobility is being defined in [7] but the solution 540 proposed there does not allow simultaneous co-existence of remote and 541 local subscribers (i.e., the content sent by the source is either 542 distributed locally to a multicast router in the PMIPv6 domain, or 543 remotely by using the bi-directional tunnel towards the mobility 544 anchor, but not both simultaneously). 546 4.2.2.1.1 Requirements 548 - The MLD proxy should be able of forwarding (replicating) the 549 multicast content to both upstream interfaces, in case of 550 simultaneous remote and local distribution. 552 - The MLD proxy should be able of handling control information 553 incoming through any of the two upstream interfaces, providing the 554 expected behavior for each of the multicast trees. 556 - The MLD proxy should be able of routing the multicast data towards 557 different upstream interfaces for both remote and local subscriptions 558 that could happen simultaneously. 560 - The MLD proxy should be able of maintaining a 1:N association 561 between an MN and both the remote and local multicast router (or 562 downstream to upstream). 564 4.2.2.2 Direct communication between source and listener associated 565 with distinct LMAs but on the same MAG 567 In a certain PMIPv6 domain can be MNs associated to distinct LMAs 568 using the same MAG to get access to their corresponding home 569 networks. For multicast communication, according to the base solution 570 [2], each MN <-> LMA association implies a distinct MLD proxy 571 instance to be invoked in the MAG. 573 In these conditions, when a mobile source is serving multicast 574 content to a mobile listener, both attached to the same MAG but each 575 of them associated to different LMAs, the multicast flow must 576 traverse the PMIPv6 domain from the MAG to the LMA where the source 577 maintains an association, then from that LMA to the LMA where the 578 listener is associated to, and finally come back to the same MAG from 579 where the flow departed. This routing is extremely inefficient. 581 An MLD proxy with multiple upstream interfaces avoids this behavior 582 since it allows to invoke a unique MLD proxy instance in the MAG. In 583 this case, the multicast source can directly communicate with the 584 multicast listener, without need for delivering the multicast traffic 585 to the LMAs. 587 4.2.2.3.1 Requirements 589 - The MLD proxy should be able of forwarding (replicating) the 590 multicast content to different upstream or downstream interfaces 591 where subscribers are present. 593 - The MLD proxy should be able of handling control information 594 incoming through any of the upstream or downstream interfaces 595 requesting a multicast flow being injected in another downstream 596 interface. 598 - The MLD proxy should be able of maintaining a 1:N association 599 between an MN and any of the upstream or downstream interfaces 600 demanding the multicast content. 602 4.2.2.3 Route optimization support in source mobility for remote 603 subscribers 605 Even in a scenario of remote subscription, there could be the case 606 where both the source and the listener are attached to the same 607 PMIPv6-Domain (for instance, no possibility of direct routing within 608 the PMIPv6, or source and listener pertaining to distinct home 609 networks). In this situation there is a possibility of route 610 optimization if inter-MAG communication is enabled, in such a way 611 that the listeners in the PMIPv6 domain are served through the 612 tunnels between MAGs, while the rest of remote listeners are served 613 through the mobility anchor. 615 A multi-upstream MLD proxy would allow the simultaneous delivery of 616 traffic to such kind of remote listeners. 618 A similar route optimization approach is proposed in [8]. 620 4.2.2.3.1 Requirements 621 - The MLD proxy should be able of forwarding (replicating) the 622 multicast content to both kinds of upstream interfaces, inter-MAG 623 tunnel interfaces and MAG to mobility anchor tunnel interface. 625 - The MLD proxy should be able of handling control information 626 incoming through any of the two types of upstream interfaces, 627 providing the expected behavior for each of the multicast trees 628 (e.g., no forwarding traffic on one inter-MAG link once there are not 629 more listeners requesting the content). 631 - The MLD proxy should be able of routing the multicast data towards 632 different upstream interfaces for both remote and route optimized 633 subscriptions that could happen simultaneously. 635 - The MLD proxy should be able of maintaining a 1:N association 636 between an MN and both the remote and local MAGs (or downstream to 637 upstream). 639 4.2.3 Summary of the requirements needed for mobile network scenarios 641 After the previous analysis, a number of different requirements can 642 be identified by the MLD proxy to support multiple upstream 643 interfaces in mobile network scenarios. The following table 644 summarizes these requirements. 646 +----------------------------------------------------+ 647 | Mobile Network Scenarios | 648 +--------------------------+-------------------------+ 649 | Mulicast Listener | Mulicast Source | 650 +---------+--------+--------+--------+--------+--------+-------+ 651 | | Single| Remote | Dual | Direct |Listener| Route | 652 |Functio- | MLD |& local | subscr.|& remote|& source|optimi.| 653 |nality | Proxy | subscr.| in HO | subscr.| on MAG | | 654 +---------+--------+--------+--------+--------+--------+-------+ 655 |Upstream | | | | | | | 656 |Control | X | X | X | X | X | X | 657 |Delivery | | | | | | | 658 +---------+--------+--------+--------+--------+--------+-------+ 659 |Downstr. | | | | | | | 660 |Control | X | X | X | | X | | 661 |Delivery | | | | | | | 662 +---------+--------+--------+--------+--------+--------+-------+ 663 |Upstream | | | | | | | 664 |Data | | | | X | | X | 665 |Delivery | | | | | | | 666 +---------+--------+--------+--------+--------+--------+-------+ 667 |Downstr. | | | | | | | 668 |Data | X | X | X | | X | | 669 |Delivery | | | | | | | 670 +---------+--------+--------+--------+--------+--------+-------+ 671 |1:1 MN to| | | | | | | 672 |upstream | X | | | | | | 673 |assoc. | | | | | | | 674 +---------+--------+--------+--------+--------+--------+-------+ 675 |1:N MN to| | | | | | | 676 |upstream | | X | X | X | X | X | 677 |assoc. | | | | | | | 678 +---------+--------+--------+--------+--------+--------+-------+ 679 |Upstr i/f| | | | | | | 680 |selection| | X | | | | | 681 |per group| | | | | | | 682 +---------+--------+--------+--------+--------+--------+-------+ 683 |Upstr i/f| | | | | | | 684 |selection| | | X | | | | 685 |all group| | | | | | | 686 +---------+--------+--------+--------+--------+--------+-------+ 687 |Upstream | | | | | | | 688 |traffic | | | | X | | X | 689 |replicat.| | | | | | | 690 +---------+--------+--------+--------+--------+--------+-------+ 692 Table II. Functionality needed on MLD proxy with multiple 693 upstream interfaces per application scenario in mobile networks 695 5 Functional specification of an MLD proxy with multiple interfaces 697 . 699 6 Security Considerations 701 . 703 7 IANA Considerations 705 . 707 8 Conclusions 709 . 711 9 Acknowledgements 713 The authors thank Stig Venaas for his valuable comments and 714 suggestions. 716 The research of Carlos J. Bernardos leading to these results has 717 received funding from the European Community's Seventh Framework 718 Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL 719 project), being also partially supported by the Ministry of Science 720 and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 721 13992-C02-01). 723 10 References 725 10.1 Normative References 727 [1] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. 728 Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 730 [2] T.C. Schmidt, M. Waehlisch, and S. Krishnan, "A Minimal 731 Deployment Option for Multicast Listeners in PMIPv6 Domains", 732 RFC6224, April 2011. 734 [3] B. Fenner, H. He, B. Haberman, and H. Sandick,"Internet Group 735 Management Protocol (IGMP) / Multicast Listener Discovery (MLD)- 736 Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, 737 August 2006. 739 10.2 Informative References 741 [4] J.C. Zuniga, L.M. Contreras, C.J. Bernardos, S. Jeon, Y. Kim, 742 "Multicast Mobility Routing Optimizations for Proxy Mobile 743 IPv6", work in progress, draft-ietf-multimob-pmipv6-ropt-01, 744 September 2012. 746 [5] L.M. Contreras, C.J. Bernardos, I. Soto, "PMIPv6 multicast 747 handover optimization by the Subscription Information 748 Acquisition through the LMA (SIAL)", work in progress, draft- 749 ietf-multimob-fast-handover-01, July 2012. 751 [6] T.C. Schmidt, M. Waehlisch, R. Koodli, G. Fairhurst, "Multicast 752 Listener Extensions for MIPv6 and PMIPv6 Fast Handovers", work 753 in progress, draft-schmidt-multimob-fmipv6-pfmipv6-multicast-06, 754 May 2012 756 [7] T.C. Schmidt, S. Gao, H. Zhang, M. Waehlisch, "Mobile Multicast 757 Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains", work in 758 progress, draft-ietf-multimob-pmipv6-source-01, July 2012. 760 [8] J. Liu, W. Luo, "Routes Optimization for Multicast Sender in 761 Proxy Mobile IPv6 Domain", work in progress, draft-liu-multimob- 762 pmipv6-multicast-ro-02, July 2012. 764 Appendix A. Basic support for multicast listener with PMIPv6 766 This section briefly summarizes the operation of Proxy Mobile IPv6 767 [1] and how multicast listener support works with PMIPv6 as specified 768 in [2]. 770 Proxy Mobile IPv6 (PMIPv6) [1] is a network-based mobility management 771 protocol which enables the network to provide mobility support to 772 standard IP terminals residing in the network. These terminals enjoy 773 this mobility service without being required to implement any 774 mobility-specific IP operations. Namely, PMIPv6 is one of the 775 mechanisms adopted by the 3GPP to support the mobility management of 776 non-3GPP terminals in future Evolved Packet System (EPS) networks. 778 PMIPv6 allows a Media Access Gateway (MAG) to establish a distinct 779 bi-directional tunnel with different Local Mobility Anchors (LMAs), 780 being each tunnel shared by the attached Mobile Nodes (MNs). Each 781 mobile node is associated with a corresponding LMA, which keeps track 782 of its current location, that is, the MAG where the mobile node is 783 attached. IP-in-IP encapsulation is used within the tunnel to forward 784 traffic between the LMA and the MAG. Figure 4 (taken from [1]) shows 785 the architecture of a PMIPv6 domain. 787 +----+ +----+ 788 |LMA1| |LMA2| 789 +----+ +----+ 790 LMAA1 -> | | <-- LMAA2 791 | | 792 \\ //\\ 793 \\ // \\ 794 \\ // \\ 795 +---\\------------- //------\\----+ 796 ( \\ IPv4/IPv6 // \\ ) 797 ( \\ Network // \\ ) 798 +------\\--------//------------\\-+ 799 \\ // \\ 800 \\ // \\ 801 \\ // \\ 802 Proxy-CoA1--> | | <-- Proxy-CoA2 803 +----+ +----+ 804 |MAG1|-----{MN2} |MAG2| 805 +----+ | +----+ 806 | | | 807 MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4 808 {MN1} {MN3} 810 Figure 4. Proxy Mobile IPv6 Domain 812 The basic solution for the distribution of multicast traffic within a 813 PMIPv6 domain [2] makes use of the bi-directional LMA-MAG tunnels. 814 The base solution follows the so-called remote subscription model, in 815 which the subscribed multicast content is delivered from the Home 816 Network. By doing so, an individual copy of every multicast flow is 817 delivered through the tunnel connecting the mobility anchor to any of 818 the access gateways in the domain. In many cases, these individual 819 copies traverse the same routers in the path towards the access 820 gateways, incurring in an inefficient distribution, equivalent to the 821 unicast distribution of the multicast content in the domain. 823 The reference scenario for multicast deployment in Proxy Mobile IPv6 824 domains is illustrated in Figure 5 (taken from [2]). 826 This fact leads to distribution inefficiencies and higher per-bit 827 delivery costs, incurred by the PMIPv6 domain operator offering 828 transport capabilities to the Home Network operator for serving their 829 MNs when attached to the PMIPv6 domain. As long as the remotely 830 subscribed multicast service is not affected, it seems worthy to 831 explore more optimal ways of distributing such content within the 832 PIMPv6 domain. 834 +-------------+ 835 | Content | 836 | Source | 837 +-------------+ 838 | 839 *** *** *** *** 840 * ** ** ** * 841 * * 842 * Fixed Internet * 843 * * 844 * ** ** ** * 845 *** *** *** *** 846 / 847 +----+ +----+ 848 |LMA1| |LMA2| Multicast Anchor 849 +----+ +----+ 850 LMAA1 | | LMAA2 851 | | 852 \\ //\\ 853 \\ // \\ 854 \\ // \\ Unicast Tunnel 855 \\ // \\ 856 \\ // \\ 857 \\ // \\ 858 Proxy-CoA1 || || Proxy-CoA2 859 +----+ +----+ 860 |MAG1| |MAG2| MLD Proxy 861 +----+ +----+ 862 | | | 863 MN-HNP1 | | MN-HNP2 | MN-HNP3 864 MN1 MN2 MN3 866 Figure 5. Reference Network for Multicast Deployment in PMIPv6 868 Authors' Addresses 870 Luis M. Contreras 871 Telefonica I+D 872 EMail: lmcm@tid.es 874 Carlos J. Bernardos 875 Universidad Carlos III de Madrid 876 EMail: cjbc@it.uc3m.es 877 Juan Carlos Zuniga 878 InterDigital Communications, LLC 879 EMail: JuanCarlos.Zuniga@InterDigital.com