idnits 2.17.1 draft-ietf-multimob-pmipv6-ropt-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6224]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 964 has weird spacing: '... oo oo ...' == Line 965 has weird spacing: '... oo oo ...' == Line 1031 has weird spacing: '... oo oo...' == Line 1032 has weird spacing: '... oo oo ...' == Line 1033 has weird spacing: '... oo oo ...' == (3 more instances...) -- The document date (September 11, 2012) is 4245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-12) exists of draft-ietf-netext-pmipv6-sipto-option-05 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group JC. Zuniga 3 Internet-Draft InterDigital 4 Intended status: Informational LM. Contreras 5 Expires: March 15, 2013 Telefonica I+D 6 CJ. Bernardos 7 UC3M 8 S. Jeon 9 Instituto de Telecomunicacoes 10 Y. Kim 11 Soongsil University 12 September 11, 2012 14 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 15 draft-ietf-multimob-pmipv6-ropt-01 17 Abstract 19 The MULTIMOB group has specified a base solution to support IP 20 multicasting in a PMIPv6 domain [RFC6224]. In this document, some 21 enhancements to the base solution are described. These enhancements 22 include the use of a multicast tree mobility anchor as the 23 topological anchor point for multicast traffic, as well as a direct 24 routing option where the MAG can provide access to multicast content 25 in the local network. These enhancements provide benefits such as 26 reducing multicast traffic replication and supporting different 27 PMIPv6 deployments scenarios. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on March 15, 2013. 46 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 3. Multicast Tree Mobility Anchor (MTMA) . . . . . . . . . . . . 6 66 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.2. Operations of the Mobile Node . . . . . . . . . . . . . . 7 68 3.3. Operations of the Mobile Access Gateway . . . . . . . . . 8 69 3.3.1. MAG as MLD Proxy . . . . . . . . . . . . . . . . . . . 8 70 3.3.2. MAG as Multicast Router . . . . . . . . . . . . . . . 11 71 3.4. Operations of the Multicast Tree Mobility Anchor . . . . . 12 72 4. Direct Routing . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 4.2. Operations of the Mobile Node . . . . . . . . . . . . . . 13 75 4.3. Operations of the Mobile Access Gateway . . . . . . . . . 13 76 4.3.1. MAG as MLD Proxy . . . . . . . . . . . . . . . . . . . 14 77 4.3.2. MAG as multicast router . . . . . . . . . . . . . . . 17 78 5. Functions and Requirements . . . . . . . . . . . . . . . . . . 17 79 5.1. Extension to the Binding Update List in MAG . . . . . . . 17 80 5.2. Extension of the Policy Profile Information including 81 multicast related parameters . . . . . . . . . . . . . . . 17 82 5.3. Data Structure in MTMA . . . . . . . . . . . . . . . . . . 18 83 6. Dynamic Selection Support . . . . . . . . . . . . . . . . . . 18 84 6.1. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 18 85 6.2. Any Source Multicast Scenario . . . . . . . . . . . . . . 19 86 6.3. Source Specific Multicast Scenario . . . . . . . . . . . . 20 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 89 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 91 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 92 10.2. Informative References . . . . . . . . . . . . . . . . . . 21 93 Appendix A. MTMA Deployment Use Cases . . . . . . . . . . . . . . 22 94 A.1. PMIPv6 domain with ratio 1:1 . . . . . . . . . . . . . . . 22 95 A.2. PMIPv6 domain with ratio N:1 . . . . . . . . . . . . . . . 22 96 A.3. PMIPv6 domain with ratio 1:N . . . . . . . . . . . . . . . 24 97 A.4. PMIPv6 domain with H-LMA . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving 103 the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the 104 Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the 105 network and does the mobility management on behalf of the Mobile Node 106 (MN). The Local Mobility Anchor (LMA) is the home agent for the MN 107 and the topological anchor point. PMIPv6 was originally designed for 108 unicast traffic. However, a PMIPv6 domain may handle data from both 109 unicast and multicast sources. 111 The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by 112 IPv4 hosts to report their IP multicast group memberships to 113 neighboring multicast routers. Multicast Listener Discovery (MLDv2) 114 [RFC3810] is used in a similar way by IPv6 routers to discover the 115 presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4065] 116 allows an intermediate (i.e. edge) node to appear as a multicast 117 router to downstream hosts, and as a host to upstream multicast 118 routers. IGMP and MLD related protocols however were not originally 119 designed to address IP mobility of multicast listeners (i.e. IGMP 120 and MLD protocols were originally designed for fixed networks). 122 The MULTIMOB group has specified a base solution to support IP 123 multicast listener mobility in a PMIPv6 domain [RFC6224], which 124 describes deployment options without modifying mobility and multicast 125 protocol standards. The PMIPv6 allows a MAG to establish multiple 126 PMIPv6 tunnels with different LMAs, e.g. up to one per MN. In the 127 presence of multicast traffic, multiple instances of the same traffic 128 can converge to the same MAG. Hence, when IP multicasting is applied 129 into PMIPv6, it leads to redundant traffic at a MAG. This is the so- 130 called "Tunnel Convergence problem". 132 To address this issue, a comprehensive solution is proposed in this 133 document, consisting of two complementary enhancements: multicast 134 anchor and direct routing. The former uses a multicast tree mobility 135 anchor (MTMA) as the topological anchor point for remotely delivering 136 multicast traffic, while the latter uses direct routing taking 137 advantage of local multicast source availability, allowing a MAG to 138 connect directly to a multicast router for simple access to local 139 content. Neither of the schemes has any impact on the MN to support 140 multicast listener mobility. 142 The MTMA details are described in section 3. Section 4 describes the 143 direct routing technique. Section 5 describes the details about the 144 dynamic selection at the MAG between direct routing (e.g. for local 145 access) and MTMA (e.g. for remote access). 147 2. Terminology 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in RFC2119 [RFC2119]. 153 This document uses the terminology defined in [RFC5213], [RFC6275], 154 and [RFC3810]. Specifically, the definition of PMIPv6 domain is 155 reused from [RFC5213] and reproduced here for completeness. 157 Proxy Mobile IPv6 Domain (PMIPv6-Domain): Proxy Mobile IPv6 domain 158 refers to the network where the mobility management of a mobile 159 node is handled using the Proxy Mobile IPv6 protocol as defined in 160 [RFC5213]. The Proxy Mobile IPv6 domain includes local mobility 161 anchors and mobile access gateways between which security 162 associations can be set up and authorization for sending Proxy 163 Binding Updates on behalf of the mobile nodes can be ensured. 165 In this draft we refine such definition from the point of view of the 166 kind of traffic served to the MN in the following way: 168 PMIPv6 unicast domain: PMIPv6 unicast domain refers to the network 169 covered by one LMA for unicast service. This service allows MN 170 mobility as it moves from one MAG to another associated to that 171 LMA regarding its unicast traffic. 173 PMIPv6 multicast domain: PMIPv6 multicast domain refers to the 174 network covered by one network element named MTMA (defined below) 175 for multicast service in such a way that an MN using that service 176 is not aware of mobility as it moves from one MAG to another. 178 From the definitions above, it can stated that a PMIPv6 domain can 179 have several PMIPv6 unicast domains and PMIPv6 multicast domains. 180 Additionally, some other definitions are introduced, as follows. 182 MTMA or multicast tree mobility anchor: an entity working as 183 topological anchor point for multicast traffic. 185 H-LMA or Hybrid-LMA: an entity dedicated to both unicast and 186 multicast services, that is, it is able to work as both LMA and 187 MTMA simultaneously. 189 Direct routing: it uses native multicast infrastructure for 190 retrieving multicast data. For the operator having its own local 191 content, this technique also includes the case that content source 192 is directly connected to a MAG. 194 3. Multicast Tree Mobility Anchor (MTMA) 196 An MTMA can be used to serve as the mobility anchor for multicast 197 traffic. Typically, the MTMA will be used to get access to multicast 198 content remotely. 200 The MTMA connects to the MAG as described in [RFC6224] and it can 201 reuse native PMIPv6 features such as tunnel establishment and 202 security [RFC5213], heartbeat [RFC5847], etc. Unicast traffic will 203 go normally to the LMAs in the PMIPv6 domain as described in 204 [RFC5213]. 206 This section describes how the MTMA works in scenarios of MN 207 attachment and multicast mobility. It concentrates on the case of 208 both LMA and MTMA defining a unique PMIPv6 domain. Some other 209 different deployment scenarios are presented in Appendix A. 211 3.1. Overview 213 Figure 1 shows an example of a PMIPv6 domain supporting multicast 214 mobility. The LMA is dedicated to unicast traffic, and the MTMA is 215 dedicated to multicast traffic. The MTMA can be considered to be a 216 form of upstream multicast router with tunnel interfaces allowing 217 remote subscription for the MNs. Note that there can be multiple 218 LMAs for unicast traffic in a given PMIPv6 domain (not shown in 219 Figure 1 for simplicity). Similarly, more than one MTMA could be 220 deployed by the operator (not shown in Figure 1). 222 As shown in Figure 1, MAG1 may connect to both unicast (LMAs) and 223 multicast (MTMAs) entities. Thus, a given MN may simultaneously 224 receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 225 receive unicast traffic, multicast traffic, or both, whereas MN3 226 receives multicast traffic only. 228 +--------------+ 229 |Content Source| 230 +--------------+ 231 | 232 | 233 *** *** *** *** *** *** *** *** 234 * ** ** ** * * ** ** ** * 235 * * * * 236 * Unicast Traffic * * Multicast Traffic * 237 * * * * 238 * ** ** ** * * ** ** ** * 239 *** *** *** ** *** *** *** *** 240 | | 241 | | 242 | | 243 +-----+ +------+ 244 Unicast | LMA | | MTMA | Multicast 245 Anchor +-----+ +------+ Anchor 246 \\ // || 247 \\ // || 248 \\ // || 249 \\ // || 250 \\ // || 251 \\ // || 252 \\ // || 253 \\ // || 254 \\ // || 255 +-----+ +-----+ 256 | MAG1| | MAG2| MLD Proxy 257 +-----+ +-----+ 258 | | | 259 | | | 260 {MN1} {MN2} {MN3} 262 Figure 1: Architecture of Multicast Tree Mobility Anchor (MTMA) 264 3.2. Operations of the Mobile Node 266 The MN operation is not impacted by the existence of an MTMA as 267 anchor for the multicast traffic being subscribed. The MN will act 268 according to the stated operations in [RFC5213] and [RFC6224]. 270 This draft considers that every MN requesting multicast-only services 271 is previously registered in a PMIPv6 unicast domain to get a unicast 272 IP address. The registration can also be required also for several 273 purposes such as remote management, billing, etc. 275 3.3. Operations of the Mobile Access Gateway 277 There are two main functionalities in the MAG when it is connected to 278 an MTMA. One when the MAG incorporates MLD proxy functions as per 279 [RFC4605]. The other case is when the MAG functions as a multicast 280 router as per [RFC4601] or [RFC4607]. 282 The following sections describe the MAG for both cases in more 283 detail. 285 3.3.1. MAG as MLD Proxy 287 If the MAG has MLD proxy functionality only, once the MLD proxy 288 instance is configured to obtain the multicast traffic remotely from 289 the MTMA, the system behavior remains static. 291 In case of remote subscription, all MAGs that are connected to the 292 MTMA must support the MLD proxy [RFC4605] function. Specifically in 293 Figure 1, each of the MAG1-MTMA and MAG2-MTMA tunnel interfaces 294 define an MLD proxy domain. The MNs are considered to be on the 295 downstream interface of the MLD proxy (of the MAG), and the MTMA is 296 considered to be on the upstream interface (of the MAG) as per 297 [RFC4605]. Note that the MAG could also be an IGMP proxy. For 298 brevity this document will refer primarily to MLD proxy, but all 299 references to "MLD proxy" should be understood to also include "IGMP/ 300 MLD proxy" functionality. 302 3.3.1.1. Multicast Establishment 304 Figure 2 shows the procedure when MN1 attaches to MAG, and 305 establishes associations with LMA (unicast) and MTMA (multicast). 307 MN1 MAG LMA MTMA 308 | (MLD Proxy) (Unicast) (Multicast) 309 MN attaches to MAG1 | | | 310 | | | | 311 |------Rtr Sol----- ->| | | 312 | |--PBU -- >| | 313 | | | | 314 | |<-- PBA --| | 315 | | | | 316 | |=Unicast= | | 317 | | Tunnel | | 318 |<-----Rtr Adv ------ | | | 319 | | | | 320 |< ------ Unicast Traffic------ >| | 321 | | | | 322 | |==Multicast Tunnel ==| 323 | | | | 324 |<--MLD Query --------| | | 325 | | | | 326 MN requires | | | 327 multicast services | | | 328 | | | | 329 |---MLD Report (G) -->| | | 330 | | | | 331 | |---- Aggregated ---> | 332 | | MLD Report (G) | 333 | | | | 334 | | | | 335 |< --------- Multicast Traffic ----------- >| 336 | | | | 338 Figure 2: MN Attachment and Multicast Service Establishment for MTMA 340 In Figure 2, MAG first establishes the PMIPv6 tunnel with LMA for 341 unicast traffic as defined in [RFC5213] after being triggered by the 342 Router Solicitation message from MN1. Unicast traffic will then flow 343 between MN1 and LMA. 345 For multicast traffic, a multicast tunnel may have been pre- 346 configured between MAG and MTMA, or may be dynamically established 347 when the first MN appears at the MAG. 349 MN1 sends the MLD report message (when required by its upper layer 350 applications) as defined in [RFC3810] in response to an MLD Query 351 from MAG. The MAG, acting as a MLD Proxy defined in [RFC4605], will 352 then send an Aggregated MLD Report to the multicast anchor, MTMA 353 (assuming that this is a new multicast group which the MAG had not 354 previously subscribed to). Multicast traffic will then flow from the 355 MTMA towards MN1. 357 3.3.1.2. Multicast Mobility 359 Figure 3 illustrates the mobility scenario for multicast traffic. 360 Specifically, MN2 with ongoing multicast subscription moves from MAG1 361 to MAG2. Note that, for simplicity, in this scenario we only 362 consider the tunnel of MAG2 with MTMA (for multicast traffic) and we 363 does not show any unicast traffic. Of course, if it was desired to 364 support unicast traffic, it would be served by a tunnel between MAG2 365 and LMA. 367 According to the baseline solution signaling method described in 368 [RFC6224], after MN2 mobility, MAG2 acting in its role of MLD proxy 369 will send an MLD Query to the newly observed MN on its downlink. 370 Assuming that the subsequent MLD Report from MN2 requests membership 371 for a new multicast group (from MAG2's point of view), this will then 372 result in an Aggregated MLD Report being sent to the MTMA from MAG2. 373 This message will be sent through a multicast tunnel between MAG2 and 374 MTMA (pre-established or dynamically established) . 376 When MN2 detaches, MAG1 may keep the multicast tunnel with the 377 multicast MTMA if there are still other MNs using the multicast 378 tunnel. Even if there are no MNs currently on the multicast tunnel, 379 MAG1 may decide to keep the multicast tunnel for potential future 380 use. 382 As discussed above, existing MLD (and MLD proxy) signaling will 383 handle a large part of the multicast mobility management for the MN. 385 MN2 MAG1 MAG2 LMA MTMA 386 | (MLD Proxy) (MLD Proxy) (Unicast)(Multicast) 387 | | | | | 388 MN Attached | | | | 389 to MAG1 | | | | 390 | | | | | 391 | |========= Multicast Tunnel ======= | 392 | | | | | 393 MN Detaches | | | | 394 from MAG1 | | | | 395 | | | | | 396 | | | | | 397 MN Attaches | | | | 398 to MAG2 | | | | 399 | | | | | 400 |---------Rtr Sol------ >| | | 401 | | |--- PBU -- >| | 402 | | | | | 403 | | |<-- PBA ----| | 404 | | | | | 405 |<-----Rtr Adv --------- | | | 406 | | | | | 407 | | |==Multicast Tunnel === | 408 | | | | | 409 |<---------MLD Query---- | | | 410 | | | | | 411 |---MLD Report (G) ----> | | | 412 | | | | | 413 | | |---- Aggregated -----> | 414 | | | MLD Report (G) | 415 | | | | | 416 | | | | | 417 |< --------- Multicast Traffic ---------------- >| 418 | | | | | 419 | | | | | 421 Figure 3: Multicast Mobility Signaling for MTMA 423 3.3.2. MAG as Multicast Router 425 If the MAG is a multicast router, the system behavior when operating 426 with remote subscription is as described before, considering that a 427 multicast routing protocol is running between the MAG and the MTMA on 428 the tunnel interface. Even once the MAG has decided to obtain the 429 multicast traffic remotely based for instance on routing information 430 and/or network management criteria, this decision can be dynamically 431 changed if such criteria changes. This behavior is further described 432 in section Section 6.2. 434 3.4. Operations of the Multicast Tree Mobility Anchor 436 The MTMA provides connectivity to the multicast infrastructure out of 437 the PMIPv6 domain. The MTMA itself could either act as an additional 438 MLD proxy (only in the case where all the connected MAGs act also as 439 MLD proxies), reporting to a further node an aggregated view of the 440 subscriptions in a PMIPv6 multicast domain; or it can act as a 441 designated multicast router for all the MAGs in a PMIPv6 multicast 442 domain. The MTMA will then request the multicast content on behalf 443 of the MAGs (and MNs behind them). In addition, the MTMA will create 444 and maintain the corresponding multicast forwarding states per each 445 tunnel interface towards the MAGs. Whatever the role played, when 446 the MAGs act as MLD proxy, the MTMA becomes the MLD querier of the 447 MLD proxy instance located in each MAG. 449 4. Direct Routing 451 Direct routing uses native multicast infrastructure, allowing a MAG 452 to directly connect a multicast router in the PMIPv6 domain. A MAG 453 can act as a MLD proxy or multicast router for redirecting multicast 454 packets. 456 The main purpose of direct routing is to provide optimal routing for 457 local content. As a consequence, it alleviates the MTMA of the 458 channel management and data delivery of locally available content. 459 Unicast traffic will go normally to the LMAs in the PMIPv6 domain. 461 This section describes how the direct routing works in scenarios of 462 MN attachment and multicast mobility. 464 4.1. Overview 466 Figure 4 shows the architecture for the local routing case using 467 native multicasting infrastructure 468 [I-D.deng-multimob-pmip6-requirement]. 470 The LMA is dedicated to unicast traffic, and the multicast traffic is 471 obtained from an upstream multicast router present in the PMIPv6 472 domain. Note that there can be multiple LMAs for unicast traffic 473 (not shown in Figure 1) in a given PMIPv6 domain. 475 As shown in Figure 4, a MAG may connect to both unicast (LMA) and 476 multicast (MR) nodes. Thus, a given MN may simultaneously receive 477 both unicast and multicast traffic. 479 As seen in Figure 4, each MAG has a direct connection (i.e., not 480 using the tunnel interface) with a multicast router. To facilitate 481 IGMP/MLD signaling and multicast packets forwarding, a MLD proxy 482 function defined in [RFC4605], or multicast routing function SHOULD 483 be placed on the MAG. 485 Multicast Tree 486 : 487 : || - PMIPv6 Tunnel 488 +----------+ +----------+ | - Multicast Data Path 489 | LMA | | MR | 490 +----------+ +----------+ 491 || \\ / | 492 || \\ / | 493 || \\ / | 494 || \\ / | 495 || \\ / | 496 || \\ / | 497 || \\ | 498 || /\\ | 499 || / \\ | 500 || / \\ | 501 || / \\ | 502 || / \\ | 503 +----------+ +----------+ 504 | P-MAG | | N-MAG | MLD Proxy or Multicast Router 505 +----------+ +----------+ 506 : : 507 +------+ +------+ 508 | MN | -----> | MN | 509 +------+ +------+ 511 Figure 4: Architecture for direct routing based PMIPv6 multicasting 513 4.2. Operations of the Mobile Node 515 The MN operation is not impacted by the direct routing option. The 516 MN will act according to the stated operations in [RFC5213] and 517 [RFC6224]. 519 This draft considers that every MN requesting multicast-only services 520 is previously registered in a PMIPv6 unicast domain to get a unicast 521 IP address. This registration can also be required for several 522 purposes such as remote management, billing, etc. 524 4.3. Operations of the Mobile Access Gateway 526 There are two main functionalities in the MAG when it supports direct 527 routing. One is the when the MAG incorporates MLD proxy functions as 528 per [RFC4605]. The other case is when the MAG functions as a 529 multicast router as per [RFC4601] or [RFC4607]. 531 The following sections describe the MAG for both cases in more 532 detail. 534 4.3.1. MAG as MLD Proxy 536 In case the MAG only incorporates MLD proxy functionality, for every 537 one of the MLD proxy instances invoked in the MAG it is necessary to 538 define at configuration time the upstream interface from where the 539 multicast traffic will be received. This decision requires to define 540 whether the multicast subscription by an MLD proxy instance for all 541 the multicast channels will be local (if the upstream interface 542 points to a multicast router internal to the PMIPv6 domain) or remote 543 (in case of the upstream interface is the bi-directional tunnel 544 towards the LMA, for the architecture in [RFC6224], or the MTMA, for 545 the multicast listener optimization described in this document). 547 4.3.1.1. Multicast Establishment 549 If the MAG has MLD proxy functionality only, once the MLD proxy 550 instance is configured to obtain the multicast traffic locally, the 551 system behavior remains static. 553 In Figure 5, the MAG first establishes the PMIPv6 tunnel with LMA for 554 unicast traffic as defined in [RFC5213] after being triggered by the 555 Router Solicitation message from the MN. Unicast traffic will then 556 flow between the MN and LMA. 558 For multicast traffic, it is assumed that the upstream interface of 559 the MLD proxy instance has been configured pointing to a multicast 560 router internal to the PMIPv6 domain (or towards an additional MLD 561 proxy node in the domain), for all the multicast channels (which, in 562 consequence, have to be local). There should be direct connectivity 563 between the MAG and the local multicast router (or additional MLD 564 proxy). 566 Upon detecting node attachment from an incoming interface, the MAG 567 adds each downstream interface to the MLD Proxy instance with 568 upstream link to a MR according to the standard MLD proxy operations 569 and sends an MLD Query message towards the MN. The MN sends the MLD 570 report message (when required by its upper layer applications) as 571 defined in [RFC3810] in response to an MLD Query from MAG.Upon 572 receiving the MLD Report message from each incoming interface, the 573 MAG checks the MLD Proxy instance associated with the downstream 574 interface and then the MLD Report messages will be aggregated and 575 forwarded to the upstream link associated with the MR (assuming that 576 this is a new multicast group which the MAG had not previously 577 subscribed to). Multicast traffic will then flow from the local 578 multicast router towards the MN. 580 MN MAG LMA MR 581 | (MLD Proxy) (Unicast) (Multicast) 582 MN attaches to MAG1 | | | 583 | | | | 584 |------Rtr Sol----- ->| | | 585 | |---- PBU --->| | 586 | | | | 587 | |<--- PBA ----| | 588 | | | | 589 | |== Unicast ==| | 590 | | Tunnel | | 591 |<---- Rtr Adv -------| | | 592 | | | | 593 |<------- Unicast Traffic --------->| | 594 | | | | 595 | | | | 596 |<--- MLD Query ------|<------ MLD Query ---------| 597 | | | | 598 MN requires | | | 599 multicast services | | | 600 | | | | 601 |-- MLD Report (G) -->| | | 602 | | | | 603 | |------- Aggregated ------->| 604 | | MLD Report (G) | 605 | | | | 606 | | | | 607 |<------------ Multicast Traffic ---------------->| 608 | | | | 610 Figure 5: Multicast service establishment for direct routing 612 4.3.1.2. Multicast mobility 614 MN P-MAG N-MAG LMA MR 615 | | | | | 616 | | | | | 617 |<------------|<-- Multicast Data----------------| 618 | | . | | | 619 | | . | | | 620 | | . | | | 621 Link Handover | | | 622 Disconnected Detection | | | 623 | | | | | 624 | | | | | 625 | | MN Attachment | | 626 | | | | | 627 | | | | | 628 |------- Rtr. Sol. ------>| | | 629 | | | | | 630 |<------ MLD Query -------| | | 631 | | | | | 632 |------- MLD Report ----->| | | 633 | | | Aggregated | 634 | | |---- MLD Report ----->| 635 | | | | | 636 | | | | | 637 |<------------------------|<-- Multicast Data ---| 638 | | | | | 639 | | | | | 640 | | |--- PBU -->| | 641 | | | | | 642 | | |<-- PBA ---| | 643 | | | | | 645 Figure 6: Multicast mobility signaling for direct routing 647 Figure 6 shows the handover operation procedure in the local direct 648 routing architecture. When an MN hands off to the next MAG (N-MAG) 649 from the previous MAG (P-MAG), the N-MAG detects the newly arrived 650 attached MN and performs binding update procedure by exchanging PBU/ 651 PBA signaling messages with LMA. At the same time, a MLD Proxy 652 instance detecting the new MN transmits an MLD query message to the 653 MN. After receiving the MLD query message, the MN sends an MLD 654 report message that includes the multicast group information. The 655 N-MAG then sends an aggregated MLD report message to the upstream 656 link associated with the MR. In the direct routing case, an upstream 657 interface of MLD Proxy instance is decided towards certain multicast 658 router based on the operator's configuration or multicast routing, as 659 compared to the base solution defined in [RFC6224] where it is 660 determined for each MN based on the Proxy Binding Update List. When 661 the N-MAG receives the multicast packets from the MR, it then simply 662 forwards them without tunnel encapsulation. The N-MAG updates the 663 MN's location information to the LMA by exchanging PBU/PBA signaling 664 messages. 666 4.3.2. MAG as multicast router 668 If the MAG behaves as a multicast router, the MAG then implements a 669 multicast routing protocol. This allows the MAG to make decisions 670 about from where to receive the traffic of any multicast channel, 671 based on routing information and/or network management criteria. The 672 selected incoming interface for receiving multicast traffic will be 673 then the one matching such criteria, and it could drive to either a 674 local or remote subscription. Some situations are introduced in the 675 next section. 677 If the MAG is a multicast router, the system behavior when operating 678 with local subscription is as before, but extending the role of the 679 MAG to be a multicast router, and running a multicast routing 680 protocol among the MAG and local multicast router serving the 681 multicast traffic. Once the MAG decides to obtain the multicast 682 traffic locally based in routing information and/or network 683 management criteria, this can be dynamically changed if such criteria 684 change. 686 5. Functions and Requirements 688 A set of new functions and structures are needed in PMIPv6 to allow 689 the use of the solution described in this document. The following 690 sub-sections describe these required extensions. 692 5.1. Extension to the Binding Update List in MAG 694 The Binding Update List in the MAG must be updated to be able to 695 handle the fact that more than one entity (i.e. LMA and MTMA) may be 696 serving the mobile node. 698 5.2. Extension of the Policy Profile Information including multicast 699 related parameters 701 A given mobile node's policy profile information must be updated to 702 be able to store the IPv6 addresses of both the LMA and MTMA, for the 703 remote subscription case. 705 Additionally, when the MAG act as multicast router in the local 706 subscription case it is required to keep registration of the IP 707 address for the rendez-vous point in the PMIPv6 domain, when PIM-SM 708 is used. When using PIM-SSM, the IP addresses of the local multicast 709 sources have to be also registered. 711 5.3. Data Structure in MTMA 713 The MTMA does not directly interact with the MNs attached to any of 714 the MAGs. The MTMA only manages the multicast groups subscribed per 715 MAG on behalf of the MNs attached to it. Having this in mind, the 716 relevant information to be stored in the MTMA should be the tunnel 717 interface identifier (tunnel-if-id) of the bi-directional tunnel for 718 multicast between the MTMA and every MAG (e.g. similar to what it is 719 stated in [RFC5213] for the unicast case), the IP addresses of the 720 multicast group delivered per tunnel to each of the MAGs, and the IP 721 addresses of the sources injecting the multicast traffic per tunnel 722 to the multicast domain defined by the MTMA. 724 6. Dynamic Selection Support 726 As mentioned above, the MAG as multicast router provides some 727 flexibility for choosing local versus remote multicast subscription. 728 With this approach IP multicast traffic can selectively be received 729 from the home, visited or local domains, and the selection of traffic 730 can be based on operator policies. Considering PIM as the multicast 731 routing protocol running on the MAG, it is possible to find out two 732 situations where such dynamic selection can occur, according to the 733 PIM flavor on place. For all the scenarios below we consider a 734 certain multicast flow being injected by two different sources, one 735 local to the PMIPv6 domain and one remote through the home network, 736 by using an MTMA. 738 6.1. Use Cases 740 The MAG has different options to subscribe to a multicast group, such 741 as: 743 - Via the tunnel with the LMA unicast [RFC6224] 745 - Via the tunnel with the MTMA (as described in Section 3) 747 - Via local subscription/routing (as described in Section 4) 749 Also, the content can be located in different places. For instance, 750 the content might be locally available (e.g. TV channels offered in 751 the visited domain), or the content might be remote (e.g. TV 752 channels offered in the home domain). In case the content is 753 available remotely at the home network it is preferred to subscribe 754 via the MTMA tunnel to home. However, if the content is available 755 locally, it is preferred to subscribe at the MAG (local break point) 756 instead of via the home network. The MAG may therefore have to 757 choose which approach needs to be taken to subscribe to a particular 758 content requested by a particular MN. 760 - If the IP address of the source injecting a certain multicast 761 group is local (scope: local domain), the MAG should get access to 762 it via local subscription (or routing, if the MAG is a multicast 763 router). 765 - If IP address of the source injecting a certain multicast group 766 is global (or the scope is broader than the local domain), the MAG 767 may have to decide among the different available options (i.e. 768 RFC6224, Local Routing, or MTMA). This can be achieved through 769 some static or dynamic configuration at the MAG. 771 6.2. Any Source Multicast Scenario 773 This situation applies for both PIM-SM and BIDIR PIM variants. In 774 this case, once the MAG receives the MLD report from the MN 775 requesting the multicast channel in the form (*,G), the MAG could 776 decide what multicast flow subscribes to (either the local or the 777 remote one). 779 The subscription can be statically pre-configured or dynamically 780 configured based on some rule. For instance, static configuration 781 can be made per MN (user), such as "multicast traffic from user X 782 should always go through the home (i.e., via the tunnel with the 783 MTMA/LMA-as-per-RFC6224), while traffic from user Y should go via 784 local subscription". Also, configuration profiles can also be more 785 complex and include considerations on types of traffic or IP flows, 786 such as "traffic of type A from user X should always go through the 787 home, traffic of type B from user X should be subscribed locally" 788 using routing information and/or network management criteria. 789 Similarly, routing information can be received dynamically. For 790 example, at user's registration time PBU/PBA signaling can be used to 791 carry the profile information similar to what is described in 792 [I-D.ietf-netext-pmipv6-sipto-option]. Also, routing information can 793 be exchanged dynamically when the multicast group subscription is 794 made. 796 In case of using PIM-SM, another scenario is possible. PIM-SM allows 797 switching from a multicast shared-tree to a source-specific tree to 798 optimize the path for traffic delivery. The location of the 799 rendezvous point and the multicast source can either be in the PMIPv6 800 domain or the home network, so the optimization could be from local 801 subscription to remote subscription or vice versa. The possibility 802 of switching to a source-based tree, and the time for doing so is 803 implementation-dependent, and this could be triggered immediately 804 (e.g. after reception of the first multicast packet) or after some 805 time, or may not even switch at all. 807 6.3. Source Specific Multicast Scenario 809 This situation applies for PIM-SSM. Then, in a source-specific 810 multicast scenario [RFC4607], the MAG would send the PIM request to 811 the corresponding interface based on the multicast source address 812 indicated on the (S,G) subscription requested by the MN in the MLD 813 Report, using the routing information. 815 7. IANA Considerations 817 TBD. 819 8. Security Considerations 821 This draft discusses the operations of existing protocols without 822 modifications. It does not introduce new security threats beyond the 823 current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], 824 IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605]. 826 9. Authors 828 Additional co-authors of this document are: 830 Akbar Rahman 832 InterDigital Communications, LLC 834 E-mail: akbar.rahman@interdigital.com 836 Ignacio Soto 838 Universidad Politecnica de Madrid 840 E-mail: isoto@dit.upm.es 842 10. References 843 10.1. Normative References 845 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 846 Requirement Levels", BCP 14, RFC 2119, March 1997. 848 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 849 Thyagarajan, "Internet Group Management Protocol, Version 850 3", RFC 3376, October 2002. 852 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 853 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 855 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 856 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 858 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 859 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 860 Protocol Specification (Revised)", RFC 4601, August 2006. 862 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 863 "Internet Group Management Protocol (IGMP) / Multicast 864 Listener Discovery (MLD)-Based Multicast Forwarding 865 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 867 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 868 IP", RFC 4607, August 2006. 870 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 871 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 873 [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, 874 S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile 875 IPv6", RFC 5847, June 2010. 877 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 878 in IPv6", RFC 6275, July 2011. 880 10.2. Informative References 882 [I-D.deng-multimob-pmip6-requirement] 883 Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, 884 "Multicast Support Requirements for Proxy Mobile IPv6", 885 draft-deng-multimob-pmip6-requirement-02 (work in 886 progress), July 2009. 888 [I-D.ietf-netext-pmipv6-sipto-option] 889 Gundavelli, S., Zhou, X., Korhonen, J., and R. Koodli, 890 "IPv4 Traffic Offload Selector Option for Proxy Mobile 891 IPv6", draft-ietf-netext-pmipv6-sipto-option-05 (work in 892 progress), August 2012. 894 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 895 Deployment for Multicast Listener Support in Proxy Mobile 896 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 898 Appendix A. MTMA Deployment Use Cases 900 From the network architecture point of view, there are several 901 options when considering the multicast tree mobility anchor (MTMA) 902 approach. These options can be distinguished in terms of the number 903 of LMAs and MTMAs present in a PMIPv6 domain and the service 904 relationship that a set of MNs gets from them, in the form of a "LMA 905 : MTMA" ratio. According to that, it is possible to differentiate 906 the following approaches: 908 A set of MNs is served in a PMIPv6 domain by two entities, one 909 MTMA for multicast service, and one LMA for unicast, in such a way 910 that the ratio is 1:1 (one common PMIPv6 unicast and multicast 911 domain). 913 A set of MNs is served in a PMIPv6 domain by several entities, one 914 MTMA for multicast service, while the others (LMAs) for unicast, 915 in such a way that the ratio is N:1 (N PMIPv6 unicast domains 916 coexist with a unique multicast domain). 918 A set of MNs is served in a PMIPv6 domain by several entities, one 919 LMA for unicast, while the others (MTMAs) are devoted to multicast 920 service, in such a way that the ratio is 1:N (one single PMIPv6 921 unicast domain coexists with multiple multicast domains). 923 Scenarios with an N:M ratio are considered to be a combination of the 924 previous ones. 926 A.1. PMIPv6 domain with ratio 1:1 928 This approach basically refers to the architecture presented in 929 Figure 1. Within this approach, a common set of MNs is served by a 930 couple of entities, one LMA for unicast and one MTMA for multicast. 931 All the MNs of the set are served by these two elements as they move 932 in the PMIPv6 domain. 934 A.2. PMIPv6 domain with ratio N:1 936 This approach basically refers to the situation where a common set of 937 MNs is served by a unique MTMA for multicast service, but 938 simultaneously there are subsets from that group of MNs which are 939 served by distinct LMAs for unicast service as they move in the 940 PMIPv6 domain. Each particular MN association with the LMAs 941 (unicast) and MTMA (multicast) remains always the same as it moves in 942 the PMIPv6 domain. 944 Figure 7 shows the scenario here described. 946 +----------------+ +----------------+ 947 |Content Source A| |Content Source B| 948 +----------------+ +----------------+ 949 | | 950 | | 951 *** *** *** *** *** *** *** *** *** *** *** 952 * ** ** ** ** ** ** ** ** ** ** * 953 * * 954 * Fixed Internet * 955 * (Unicast & Multicast Traffic) * 956 * ** ** ** ** ** ** ** ** ** ** * 957 *** *** *** *** *** *** *** *** *** *** *** 958 | | | 959 | | | 960 | | | 961 +------+ +-----------------+ +------+ 962 | LMA1 | | MTMA2 | | LMA3 | 963 +------+ +-----------------+ +------+ 964 || \\ oo oo oo oo // || 965 || \\ oo oo oo oo // || 966 || \\ oo oo oo oo // || 967 || \\ oo oo oo oo // || 968 || \\oo oo oo oo // || 969 || \\ oo oo oo// || 970 || oo\\ oo oo // || 971 || oo \\ oo oo //oo || 972 || oo \\ oo oo // oo || 973 || oo \\ oo oo // oo || 974 +------+ +--------+ +--------+ +--------+ 975 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 976 +------+ +--------+ +--------+ +--------+ 977 | | | | | | | | 978 | | | | | | | | 979 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 981 Figure 7: PMIPv6 domain with ratio N:1 983 The Figure 7 proposes an architecture where there are two entities 984 acting as LMAs, LMA1 and LMA3, while there is another one, named 985 MTMA2, working as multicast tree mobility anchor. LMA1 and LMA3 986 constitute two distinct unicast domains, whereas MTMA2 forms a single 987 multicast domain. The tunnels among MAGs and LMAs represented by 988 lines ("||") indicate a tunnel transporting unicast traffic, while 989 the tunnels among MAGs and MTMA2 depicted with circles ("o") show a 990 tunnel transporting multicast traffic. 992 In the figure it can be observed that all the MNs are served by MTMA2 993 for the incoming multicast traffic from sources A or B. However, 994 there are different subsets regarding unicast traffic which maintain 995 distinct associations within the PMIPv6 domain. For instance, the 996 subset formed by MN10, MN11, MN20 and MN21 is served by LMA1 for 997 unicast, and the rest of MNs are being served by LMA3. For the 998 scenario described above, the association between each MN and the 999 corresponding LMA and MTMA is permanently maintained. 1001 A.3. PMIPv6 domain with ratio 1:N 1003 This approach is related to a scenario where a common group of MNs is 1004 served by a unique LMA for unicast service, but simultaneously there 1005 are subsets from that group of MNs which are served by distinct MTMAs 1006 for multicast service as they move in the PMIPv6 domain. Each 1007 particular MN association with the LMA and MTMAs (unicast and 1008 multicast respectively) remains always the same as it moves in the 1009 PMIPv6 domain. 1011 Figure 8 shows the scenario here described. 1013 +----------------+ +----------------+ 1014 |Content Source A| |Content Source B| 1015 +----------------+ +----------------+ 1016 | | 1017 | | 1018 *** *** *** *** *** *** *** *** *** *** *** 1019 * ** ** ** ** ** ** ** ** ** ** * 1020 * * 1021 * Fixed Internet * 1022 * (Unicast & Multicast Traffic) * 1023 * ** ** ** ** ** ** ** ** ** ** * 1024 *** *** *** *** *** *** *** *** *** *** *** 1025 | | | 1026 | | | 1027 | | | 1028 +------+ +-----------------+ +------+ 1029 | MTMA1| | LMA2 | | MTMA3| 1030 +------+ +-----------------+ +------+ 1031 oo oo // || || \\ oo oo 1032 oo oo // || || \\ oo oo 1033 oo oo // || || \\ oo oo 1034 oo oo // || || \\ oo oo 1035 oo oo// || || \\ oo oo 1036 oo oo || || \\oo oo 1037 oo //oo || || \\ oo 1038 oo // oo || || oo\\ oo 1039 oo // oo || || oo \\ oo 1040 oo // oo || || oo \\ oo 1041 +------+ +--------+ +--------+ +--------+ 1042 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 1043 +------+ +--------+ +--------+ +--------+ 1044 | | | | | | | | 1045 | | | | | | | | 1046 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 1048 Figure 8: PMIPv6 domain with ratio 1:N 1050 The Figure 8 proposes an architecture where the LMA2 is the unique 1051 LMA for a certain group of MNs, while there are two others entities, 1052 MTMA1 and MTMA3, acting as MTMAs for different subsets of MNs of the 1053 same group. MTMA1 and MTMA3 constitute two distinct multicast 1054 domains, whereas LMA2 forms a single unicast domain. Each MTMA could 1055 be devoted to carry on a different content (for instance, MTMA1 for 1056 source A and MTMA3 for source B) or not. Looking at the picture, the 1057 subset formed by MN10, MN11, MN20 and MN21 is served by MTMA1 for 1058 multicast. The rest of MNs are being served by MTMA3 also for 1059 multicast. Finally, all of them are served by LMA2 for unicast. For 1060 the scenario described above, the association between each MN and the 1061 corresponding LMA and MTMA is permanently maintained. 1063 A.4. PMIPv6 domain with H-LMA 1065 The H-LMA is defined as an entity which simultaneously transports 1066 unicast and multicast service, that is, it simultaneously works as 1067 LMA and MTMA. In the context of the MTMA solution, an H-LMA can play 1068 the role of MTMA for an entire group of MNs in a PMIPv6 domain, while 1069 acting simultaneously as LMA for a subset of them. The figure 9 1070 adapts the PMIPv6 domain with ratio N:1 scenario of figure 7 to the 1071 case where MTMA2 is an H-LMA, which serves multicast traffic to all 1072 the MNs in the picture, and simultaneously, it is able to serve 1073 unicast traffic to the subset formed by MN30, MN40 and MN41. 1075 +----------------+ +----------------+ 1076 |Content Source A| |Content Source B| 1077 +----------------+ +----------------+ 1078 | | 1079 | | 1080 *** *** *** *** *** *** *** *** *** *** *** 1081 * ** ** ** ** ** ** ** ** ** ** * 1082 * * 1083 * Fixed Internet * 1084 * (Unicast & Multicast Traffic) * 1085 * ** ** ** ** ** ** ** ** ** ** * 1086 *** *** *** *** *** *** *** *** *** *** *** 1087 | | | 1088 | | | 1089 | | | 1090 +------+ +-----------------+ +------+ 1091 | LMA1 | | H-LMA | | LMA3 | 1092 +------+ +-----------------+ +------+ 1093 || \\ oo db db oo // || 1094 || \\ oo db db oo // || 1095 || \\ oo db db oo // || 1096 || \\ oo db db oo // || 1097 || \\oo db db oo // || 1098 || \\ db db oo// || 1099 || oo\\ db db // || 1100 || oo \\ db db //oo || 1101 || oo \\ db db // oo || 1102 || oo \\ db db // oo || 1103 +------+ +--------+ +--------+ +--------+ 1104 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 1105 +------+ +--------+ +--------+ +--------+ 1106 | | | | | | | | 1107 | | | | | | | | 1108 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 1110 Figure 9: PMIPv6 domain with H-LMA 1112 Figure 8 presents a PMIPv6 network where there are two pure unicast 1113 LMAs, LMA1 and LMA3, and a hybrid LMA, labeled as H-LMA in the 1114 figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4. 1115 The tunnels among MAGs and LMAs represented by lines ("||") indicate 1116 a tunnel transporting exclusively unicast traffic, the tunnels 1117 depicted with circles ("o") show a tunnel transporting exclusively 1118 multicast traffic, and the tunnels with mixed lines and circles 1119 ("db") describe a tunnel transporting both types of traffic 1120 simultaneously. 1122 All of the MNs in the figure receive the multicast traffic from H-LMA 1123 (one single multicast domain), but it is possible to distinguish 1124 three subsets from the unicast service perspective (that is, three 1125 unicast domains). The first subset is the one formed by MN10, MN11 1126 and MN 20, which receives unicast traffic from LMA1. A second subset 1127 is the one formed by MN21 and MN30, which receives unicast traffic 1128 from H-LMA. And finally, a third subset is built on MN31, MN40 and 1129 MN41, which receives unicast traffic from LMA3. For the scenario 1130 described above, the association between each MN and the 1131 corresponding LMA and H-LMA is permanently maintained. 1133 Authors' Addresses 1135 Juan Carlos Zuniga 1136 InterDigital Communications, LLC 1137 1000 Sherbrooke Street West, 10th floor 1138 Montreal, Quebec H3A 3G4 1139 Canada 1141 Email: JuanCarlos.Zuniga@InterDigital.com 1142 URI: http://www.InterDigital.com/ 1144 Luis M. Contreras 1145 Telefonica I+D 1146 Don Ramon de la Cruz, 82-84 1147 Madrid 28006 1148 Spain 1150 Email: lmcm@tid.es 1152 Carlos J. Bernardos 1153 Universidad Carlos III de Madrid 1154 Av. Universidad, 30 1155 Leganes, Madrid 28911 1156 Spain 1158 Phone: +34 91624 6236 1159 Email: cjbc@it.uc3m.es 1160 URI: http://www.it.uc3m.es/cjbc/ 1161 Seil Jeon 1162 Instituto de Telecomunicacoes 1163 Campus Universitario de Santiago 1164 Aveiro 3810-193 1165 Portugal 1167 Email: seiljeon@av.it.pt 1168 URI: https://atnog.av.it.pt/~sjeon/ 1170 Younghan Kim 1171 Soongsil University 1172 Sangdo-dong, Dongjak-gu 1173 Seoul 511 1174 Republic of Korea 1176 Email: yhkim@dcn.ssu.ac.kr 1177 URI: http://dcnlab.ssu.ac.kr/