idnits 2.17.1 draft-ietf-multimob-pmipv6-ropt-08.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 == Line 979 has weird spacing: '... oo oo ...' == Line 980 has weird spacing: '... oo oo ...' == Line 1115 has weird spacing: '... oo db ...' == Line 1116 has weird spacing: '... db oo ...' -- The document date (August 16, 2013) is 3877 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 621 -- Looks like a reference, but probably isn't: '2' on line 625 == Missing Reference: 'N' is mentioned on line 633, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-mboned-auto-multicast-15 == Outdated reference: A later version (-09) exists of draft-ietf-multimob-pmipv6-source-04 == Outdated reference: A later version (-02) exists of draft-zhang-pim-muiimp-01 Summary: 0 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). 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: Experimental LM. Contreras 5 Expires: February 17, 2014 Telefonica I+D 6 CJ. Bernardos 7 UC3M 8 S. Jeon 9 Instituto de Telecomunicacoes 10 Y. Kim 11 Soongsil University 12 August 16, 2013 14 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 15 draft-ietf-multimob-pmipv6-ropt-08 17 Abstract 19 This document proposes some experimental enhancements to the base 20 solution to support IP multicasting in a PMIPv6 domain. These 21 enhancements include the use of a multicast tree mobility anchor as 22 the topological anchor point for multicast traffic, as well as a 23 direct routing option where the Mobile Access Gateway can provide 24 access to multicast content in the local network. The goal of these 25 enhancements is to provide benefits such as reducing multicast 26 traffic replication and supporting different PMIPv6 deployment 27 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 February 17, 2014. 46 Copyright Notice 48 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1. MTMA/Direct routing mode selection . . . . . . . . . . . . 5 67 3.2. Multicast Tree Mobility Anchor (subscription via MTMA) . . 5 68 3.3. Direct Routing (subscription via direct routing) . . . . . 7 69 4. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 9 70 4.1. Extensions to Binding Update List Data Structure . . . . . 9 71 4.2. MAG as MLD proxy . . . . . . . . . . . . . . . . . . . . . 9 72 4.2.1. MTMA mode (subscription via MTMA) . . . . . . . . . . 9 73 4.2.2. Direct Routing mode (subscription via direct 74 routing) . . . . . . . . . . . . . . . . . . . . . . . 11 75 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 14 76 5.1. Dynamic IP Multicast Selector Option . . . . . . . . . . . 14 77 5.1.1. Option application rules . . . . . . . . . . . . . . . 14 78 5.1.2. Option format . . . . . . . . . . . . . . . . . . . . 14 79 6. Multicast Tree Mobility Anchor Operation . . . . . . . . . . . 16 80 6.1. Conceptual Data Structures . . . . . . . . . . . . . . . . 17 81 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 17 82 8. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 84 10. Security Considerations . . . . . . . . . . . . . . . . . . . 18 85 11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 12.1. Normative References . . . . . . . . . . . . . . . . . . . 19 88 12.2. Informative References . . . . . . . . . . . . . . . . . . 20 89 Appendix A. MTMA Deployment Use Cases . . . . . . . . . . . . . . 21 90 A.1. PMIPv6 domain with ratio 1:1 . . . . . . . . . . . . . . . 22 91 A.2. PMIPv6 domain with ratio N:1 . . . . . . . . . . . . . . . 22 92 A.3. PMIPv6 domain with ratio 1:N . . . . . . . . . . . . . . . 24 93 A.4. PMIPv6 domain with H-LMA . . . . . . . . . . . . . . . . . 26 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 96 1. Introduction 98 Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving 99 the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the 100 Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the 101 network and performs the mobility management on behalf of the Mobile 102 Node (MN). The Local Mobility Anchor (LMA) is the home agent for the 103 MN and the topological anchor point. PMIPv6 was originally designed 104 for unicast traffic. However, a PMIPv6 domain may handle data from 105 both unicast and multicast sources. 107 The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by 108 IPv4 hosts to report their IP multicast group memberships to 109 neighboring multicast routers. Multicast Listener Discovery (MLDv2) 110 [RFC3810] is used in a similar way by IPv6 routers to discover the 111 presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4065] 112 specification allows an intermediate (i.e., edge) node to appear as a 113 multicast router to downstream hosts, and as a host to upstream 114 multicast routers. IGMP and MLD related protocols however were not 115 originally designed to address IP mobility of multicast listeners 116 (i.e., IGMP and MLD protocols were originally designed for fixed 117 networks). 119 A base solution to support both IPv4 and IPv6 multicast listener 120 mobility in a PMIPv6 domain is specified in [RFC6224], which 121 describes deployment options without modifying mobility and multicast 122 protocol standards. PMIPv6 allows a mobile access gateway to 123 establish multiple PMIPv6 tunnels with different local mobility 124 anchors, e.g., up to one per mobile node. In the presence of 125 multicast traffic, multiple instances of the same traffic can 126 converge to the same MAG. Hence, when IP multicasting is applied 127 into PMIPv6, it may lead to redundant traffic at a MAG. This is the 128 tunnel convergence problem. 130 In order to address this issue, this document proposes an 131 experimental solution, consisting of two complementary enhancements: 132 multicast anchor and direct routing. The first enhancement makes use 133 of a multicast tree mobility anchor (MTMA) as the topological anchor 134 point for remotely delivering multicast traffic, while the second 135 enhancement uses direct routing taking advantage of local multicast 136 source availability, allowing a mobile access gateway to connect 137 directly to a multicast router for simple access to local content. 138 Neither of the two schemes has any impact on the mobile node to 139 support IPv4 and IPv6 multicast listener mobility, nor on the wider 140 Internet, as they only affect the PMIPv6 domains where they are 141 deployed. Although references to "MLD proxy" are used in the 142 document, it should be understood to also include "IGMP/MLD proxy" 143 functionality (see Section 8 for details). The status of this 144 proposal is Experimental. The status of this proposal may be 145 reconsidered in the future, once more implementation feedback and 146 deployment experience is gathered, reporting on the performance of 147 the two proposed schemes as well as operational feedback on scheme 148 selection. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in RFC2119 [RFC2119]. 156 This document uses the terminology defined in [RFC5213], [RFC6275], 157 and [RFC3810]. Specifically, the definition of PMIPv6 domain is 158 reused from [RFC5213] and reproduced here for completeness. 160 Proxy Mobile IPv6 Domain (PMIPv6-Domain): Proxy Mobile IPv6 domain 161 refers to the network where the mobility management of a mobile 162 node is handled using the Proxy Mobile IPv6 protocol as defined in 163 [RFC5213]. The Proxy Mobile IPv6 domain includes local mobility 164 anchors and mobile access gateways between which security 165 associations can be set up and authorization for sending proxy 166 binding updates on behalf of the mobile nodes can be ensured. 168 In this document we refine the definition from the point of view of 169 the kind of traffic served to the MN in the following way: 171 PMIPv6 unicast domain: PMIPv6 unicast domain refers to the network 172 covered by one LMA for unicast service. This service supports 173 mobility as the MN moves from one MAG to another one, both 174 associated with the same LMA regarding the MN unicast traffic. 176 PMIPv6 multicast domain: PMIPv6 multicast domain refers to the 177 network covered by one network element named MTMA (defined below) 178 for multicast service in such a way that an MN using that service 179 is not aware of mobility as it moves from one MAG to another. 181 From the definitions above, it can be stated that a PMIPv6 domain can 182 have several PMIPv6 unicast domains and PMIPv6 multicast domains. 183 Additionally, some other definitions are introduced, as follows. 185 MTMA or multicast tree mobility anchor: An entity working as 186 topological anchor point for multicast traffic. It manages the 187 multicast groups subscribed by all (or a subset of) the MAGs in a 188 PMIPv6 multicast domain, on behalf of the MNs attached to them. 189 Hence, an MTMA performs the functions of either a designated 190 multicast router or an MLD proxy. 192 H-LMA or Hybrid-LMA: An entity dedicated to both unicast and 193 multicast services, that is able to work as both LMA and MTMA 194 simultaneously. 196 Direct routing: This scheme uses the native multicast infrastructure 197 for retrieving multicast data. For an operator having its own 198 local content, this technique also includes the case where the 199 content source is directly connected to the MAG. 201 Subscription via MTMA: Multicast subscription mode in which the 202 content is retrieved from the remote (or home) MTMA. 204 Subscription via direct routing: Multicast subscription mode in 205 which the content is retrieved using direct routing from the local 206 domain. 208 3. Overview 210 3.1. MTMA/Direct routing mode selection 212 This specification describes two complementary operational modes that 213 can be used to deliver multicast traffic in a PMIPv6 domain: 214 multicast tree mobility anchor and direct routing. There are 215 different approaches that can be followed to perform this operational 216 mode selection, depending on the operator's preferences and PMIPv6 217 deployment characteristics. For example, the mode can be manually 218 configured at the mobile access gateway, according to the multicast 219 tree deployment in the PMIPv6 domain, following operator's 220 configuration of the multicast distribution on it. Another option is 221 the use of dynamic policies, conveyed in the PBU (Proxy Binding 222 Update)/PBA (Proxy Binding Acknowledge) signaling using the Dynamic 223 IP Selector Option described in Section 5.1. Next, each of the two 224 operational modes is introduced. 226 3.2. Multicast Tree Mobility Anchor (subscription via MTMA) 228 A multicast tree mobility anchor is used to serve as the mobility 229 anchor for multicast traffic. The MTMA is either a designated 230 multicast router or an MLD proxy. Typically, the MTMA will be used 231 to get access to remote multicast content. 233 The multicast tree mobility anchor connects to the mobile access 234 gateway as described in [RFC6224] and it can reuse native PMIPv6 235 features such as tunnel establishment and security [RFC5213], 236 heartbeat [RFC5847], etc. Unicast traffic will go normally to the 237 local mobility anchors in the PMIPv6 domain as described in 238 [RFC5213]. A MAG connecting to the MTMA acts as an MLD proxy. 240 This section describes how the MTMA works in scenarios of MN 241 attachment and multicast mobility. It concentrates on the case of 242 both LMA and MTMA defining a unique PMIPv6 domain. Some other 243 different deployment scenarios are presented in Appendix A. 245 Figure 1 shows an example of a PMIPv6 domain supporting multicast 246 mobility. The local mobility anchor is dedicated to unicast traffic, 247 and the multicast tree mobility anchor is dedicated to multicast 248 traffic. The MTMA can be considered to be a form of upstream 249 multicast router with tunnel interfaces allowing subscription via 250 MTMA for the MNs. 252 As shown in Figure 1, MAG1 may connect to both unicast (LMAs) and 253 multicast (MTMAs) entities. Thus, a given MN may simultaneously 254 receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 255 receive unicast traffic, multicast traffic, or both, whereas MN3 256 receives multicast traffic only. 258 +--------------+ 259 |Content Source| 260 +--------------+ 261 | 262 | 263 *** *** *** *** *** *** *** *** 264 * ** ** ** * * ** ** ** * 265 * * * * 266 * Unicast Traffic * * Multicast Traffic * 267 * * * * 268 * ** ** ** * * ** ** ** * 269 *** *** *** ** *** *** *** *** 270 | | 271 | | 272 | | 273 +-----+ +------+ 274 Unicast | LMA | | MTMA | Multicast 275 Anchor +-----+ +------+ Anchor 276 \\ // || 277 \\ // || 278 \\ // || 279 \\ // || 280 \\ // || 281 \\ // || 282 \\ // || 283 \\ // || 284 \\ // || 285 +-----+ +-----+ 286 | MAG1| | MAG2| MLD Proxy 287 +-----+ +-----+ 288 | | | 289 | | | 290 {MN1} {MN2} {MN3} 292 Figure 1: Architecture of Multicast Tree Mobility Anchor (MTMA) 294 3.3. Direct Routing (subscription via direct routing) 296 Direct routing uses a native multicast infrastructure, allowing a 297 mobile access gateway to directly connect to a multicast router (as 298 next hop) in the PMIPv6 domain. A MAG acts as an MLD proxy. 300 The main purpose of direct routing is to provide optimal connectivity 301 for local content. As a consequence, it alleviates the MTMA of the 302 channel management and data delivery of locally available content. 303 Unicast traffic will go as normally to the LMAs in the PMIPv6 domain. 305 This section describes how the direct routing works in scenarios of 306 MN attachment and multicast mobility. 308 Multicast Tree 309 : 310 : || - PMIPv6 Tunnel 311 +----------+ +----------+ | - Multicast Data Path 312 | LMA | | MR | 313 +----------+ +----------+ 314 || \\ / | 315 || \\ / | 316 || \\ / | 317 || \\ / | 318 || \\ / | 319 || \\ / | 320 || \\ | 321 || /\\ | 322 || / \\ | 323 || / \\ | 324 || / \\ | 325 || / \\ | 326 +----------+ +----------+ 327 | P-MAG | | N-MAG | MLD Proxy 328 +----------+ +----------+ 329 : : 330 +------+ +------+ 331 | MN | -----> | MN | 332 +------+ +------+ 334 Figure 2: Architecture for direct routing based PMIPv6 multicasting 336 Figure 2 shows the architecture for the local routing case using 337 native multicasting infrastructure 338 [I-D.deng-multimob-pmip6-requirement]. 340 The local mobility anchor is dedicated to unicast traffic, and the 341 multicast traffic is obtained from an upstream multicast router 342 present in the PMIPv6 domain. Note that there can be multiple LMAs 343 for unicast traffic (not shown in Figure 1 for simplicity) in a given 344 PMIPv6 domain. 346 As shown in Figure 2, a mobile access gateway may connect to both 347 unicast (LMA) and multicast (MR) routers. Thus, a given mobile node 348 may simultaneously receive both unicast and multicast traffic. 350 As seen in Figure 2, each MAG has a direct connection (i.e., not 351 using the PMIPv6 tunnel interface) with a multicast router. 352 Depending on the multicast support on the visited network, different 353 schema can be used to provide this direct connection between the MAGs 354 and the multicast router(s), e.g., being connected to the same shared 355 link or using a tunneling approach, such as Generic Routing 356 Encapsulation (GRE) tunnels [RFC2784] or Automatic Multicast 357 Tunneling (AMT) [I-D.ietf-mboned-auto-multicast]. To facilitate 358 IGMP/MLD signaling and multicast traffic forwarding, an MLD proxy 359 function defined in [RFC4605] SHOULD be implemented in the MAG. 360 There SHOULD be direct connectivity between the MAG and the local 361 multicast router (or additional MLD proxy). 363 4. Mobile Access Gateway Operation 365 This section describes the operation of the mobile access gateway, 366 considering that the MAG incorporates MLD proxy functions as per 367 [RFC4605]. 369 4.1. Extensions to Binding Update List Data Structure 371 A binding update list (BUL) at the MAG, like the one specified in 372 [RFC5213], MUST be maintained to handle the relationship between the 373 serving entities (e.g., MTMA and LMA) and the mobile nodes for both 374 unicast and multicast traffic. 376 4.2. MAG as MLD proxy 378 4.2.1. MTMA mode (subscription via MTMA) 380 In case of subscription via MTMA, all MAGs that are connected to the 381 MTMA must support the MLD proxy function [RFC4605]. Specifically in 382 Figure 1, each of the MAG1-MTMA and MAG2-MTMA tunnel interfaces 383 define an MLD proxy domain. The mobile nodes are considered to be on 384 the downstream interface of the MLD proxy (of the MAG), and the MTMA 385 is considered to be on the upstream interface (of the MAG) as per 386 [RFC4605]. Note that the mobile access gateway could also be an IGMP 387 proxy. For brevity this document will refer primarily to MLD proxy, 388 but all references to "MLD proxy" should be understood to also 389 include "IGMP/MLD proxy" functionality. 391 Figure 3 shows the procedure when MN1 attaches to a MAG, and 392 establishes associations with the LMA (unicast) and the MTMA 393 (multicast). 395 MN1 MAG LMA MTMA 396 | (MLD Proxy) (Unicast) (Multicast) 397 MN attaches to MAG1 | | | 398 | | | | 399 |----Rtr Sol--------->| | | 400 | |--PBU---->| | 401 | | | | 402 | |<----PBA--| | 403 | | | | 404 | |=Unicast==| | 405 | | Tunnel | | 406 |<---------Rtr Adv----| | | 407 | | | | 408 |< ------ Unicast Traffic------->| | 409 | | | | 410 | |==Multicast Tunnel===| 411 | | | | 412 |<-------MLD Query----| | | 413 | | | | 414 MN requires | | | 415 multicast services | | | 416 | | | | 417 |----MLD Report (G)-->| | | 418 | | | | 419 | |----Aggregated------>| 420 | | MLD Report (G) | 421 | | | | 422 | | | | 423 |<-----------Multicast Traffic------------->| 424 | | | | 426 Figure 3: MN Attachment and Multicast Service Establishment for MTMA 428 In Figure 3, the MAG first establishes the PMIPv6 tunnel with LMA for 429 unicast traffic as defined in [RFC5213] after being triggered by the 430 Router Solicitation message from MN1. Unicast traffic will then flow 431 between MN1 and LMA. 433 For multicast traffic, a multicast tunnel may have been pre- 434 configured between MAG and MTMA, or may be dynamically established 435 when the first MN appears at the MAG. 437 MN1 sends the MLD report message (when required by its upper layer 438 applications) as defined in [RFC3810] in response to an MLD Query 439 from MAG (generated as defined by [RFC6224] upon handover). The MAG, 440 acting as an MLD Proxy defined in [RFC4605], will then send an 441 Aggregated MLD Report to the multicast anchor, MTMA (assuming that 442 this is a new multicast group that the MAG had not previously 443 subscribed to). Multicast traffic will then flow from the MTMA 444 towards MN1. The MTMA acts as an MLD Querier, so it will 445 periodically query each mobile access gateway about the subscriptions 446 it maintains (not shown in Figure 3). 448 We next consider a mobility scenario in which MN1 with an ongoing 449 multicast subscription moves from one MAG to another MAG. According 450 to the baseline solution signaling method described in [RFC6224], 451 after MN1 mobility, the new mobile access gateway acting in its role 452 of MLD proxy will send an MLD Query to the newly observed mobile node 453 on its downlink. Assuming that the subsequent MLD Report from MN1 454 requests membership for a new multicast group (from the new MAG's 455 point of view), this will then result in an Aggregated MLD Report 456 being sent to the MTMA from the new mobile access gateway. This 457 message will be sent through a multicast tunnel between the new MAG 458 and MTMA (pre-established or dynamically established). 460 When MN1 detaches, the old MAG may keep the multicast tunnel with the 461 multicast MTMA if there are still other MNs using the multicast 462 tunnel. Even if there are no mobile nodes currently on the multicast 463 tunnel, the old MAG may decide to keep the multicast tunnel 464 temporarily for potential future use. 466 As discussed above, existing MLD (and MLD proxy) signaling will 467 handle a large part of the multicast mobility management for the 468 mobile node. 470 4.2.2. Direct Routing mode (subscription via direct routing) 472 In this case, the MLD proxy instance is configured to obtain the 473 multicast traffic locally. Figure 4 shows an example of multicast 474 service establishment. The mobile access gateway first establishes 475 the PMIPv6 tunnel with the local mobility anchor for unicast traffic 476 as defined in [RFC5213] after being triggered by the Router 477 Solicitation message from the mobile node. Unicast traffic will then 478 flow between the MN and LMA. 480 For multicast traffic, it is assumed that the upstream interface of 481 the MLD proxy instance has been configured pointing to a multicast 482 router internal to the PMIPv6 domain (or towards an additional MLD 483 proxy node in the domain), for all the multicast channels (which, in 484 consequence, have to be local). There should be direct connectivity 485 between the MAG and the local multicast router (or additional MLD 486 proxy). 488 MN MAG LMA MR 489 | (MLD Proxy) (Unicast) (Multicast) 490 MN attaches to MAG1 | | | 491 | | | | 492 |----Rtr Sol--------->| | | 493 | |--PBU------->| | 494 | | | | 495 | |<-------PBA--| | 496 | | | | 497 | |===Unicast===| | 498 | | Tunnel | | 499 |<---------Rtr Adv----| | | 500 | | | | 501 |<--------Unicast Traffic---------->| | 502 | | | | 503 | | | | 504 |<-------MLD Query----|<-------------MLD Query----| 505 | | | | 506 MN requires | | | 507 multicast services | | | 508 | | | | 509 |--MLD Report (G)---->| | | 510 | | | | 511 | |----Aggregated------------>| 512 | | MLD Report (G) | 513 | | | | 514 | | | | 515 |<-------------Multicast Traffic----------------->| 516 | | | | 518 Figure 4: Multicast service establishment for direct routing 520 Upon detecting node attachment from an incoming interface, the MAG 521 adds each downstream interface to the MLD Proxy instance with 522 upstream link to an MR according to the standard MLD proxy operations 523 [RFC4605] and sends an MLD Query message towards the MN. The mobile 524 node sends the MLD report message (when required by its upper layer 525 applications) in response to an MLD Query from the MAG. Upon 526 receiving the MLD Report message from each incoming interface, the 527 MAG checks the MLD Proxy instance associated with the downstream 528 interface and then the MLD Report messages will be aggregated and 529 forwarded to the upstream link associated with the MR (assuming that 530 this is a new multicast group that the MAG had not previously 531 subscribed to). Multicast traffic will then flow from the local 532 multicast router towards the mobile node. 534 MN P-MAG N-MAG LMA MR 535 | | | | | 536 | | | | | 537 |<------------|<-- Multicast Data----------------| 538 | | . | | | 539 | | . | | | 540 | | . | | | 541 Link Handover | | | 542 Disconnected Detection | | | 543 | | | | | 544 | | | | | 545 | | MN Attachment | | 546 | | | | | 547 | | | | | 548 |----Rtr Sol------------->| | | 549 | | | | | 550 | | |--PBU----->| | 551 | | | | | 552 | | |<-----PBA--| | 553 | | | | | 554 |<-----------MLD Query----| | | 555 | | | | | 556 |----MLD Report---------->| | | 557 | | | | | 558 | | |----Aggregated------->| 559 | | | MLD Report | 560 | | | | | 561 |<------------------------|<---Multicast Data----| 562 | | | | | 564 Figure 5: Multicast mobility signaling for direct routing 566 Figure 5 shows the handover operation procedure for the direct 567 routing operation mode. When an MN hands off to the next MAG (N-MAG) 568 from the previous MAG (P-MAG), the N-MAG detects the newly arrived 569 attached MN and performs binding update procedure by exchanging PBU/ 570 PBA signaling messages with LMA. At the same time, an MLD Proxy 571 instance detecting the new MN transmits an MLD query message to the 572 MN. After receiving the MLD query message, the MN sends an MLD 573 report message that includes the multicast group information. The 574 N-MAG then sends an aggregated MLD report message to the upstream 575 link associated with the MR. An upstream interface of MLD Proxy 576 instance is chosen towards certain multicast router. The upstream 577 interface selection can be done according to dynamic policies 578 conveyed in the Dynamic IP Selector Option (as described in 579 Section 5.1) or, on manually configured policies. Note that in the 580 base solution defined in [RFC6224], the interface selection is 581 determined for each MN based on the Binding Update List. When the 582 N-MAG receives the multicast packets from the MR, it then simply 583 forwards them without tunnel encapsulation. The N-MAG updates the 584 MN's location information to the LMA by exchanging PBU/PBA signaling 585 messages. 587 5. Local Mobility Anchor Operation 589 This section includes a new mobility option to support dynamic 590 policies on subscription via MTMA/direct routing based on the local 591 mobility anchor conveying the required info to the mobile access 592 gateway in the proxy binding acknowledge message. 594 5.1. Dynamic IP Multicast Selector Option 596 5.1.1. Option application rules 598 A new TLV-encoded mobility option, "Dynamic IP Multicast Selector" 599 option is defined for use with the proxy binding acknowledge message 600 exchanged between an LMA and a MAG to convey dynamic policies on 601 subscription via MTMA/direct routing. This option is used for 602 exchanging the IP addresses of both the group subscribed to by the 603 MN, and the source(s) delivering it, as well as the applicable filter 604 mode. This information is carried by using directly the Multicast 605 Address Record format defined in [RFC3810]. There can be multiple 606 "Dynamic IP Multicast Selector" options present in the message, up to 607 one for each active subscription maintained by the MN. 609 5.1.2. Option format 611 The format of this new option is as follows: 613 0 1 2 3 614 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type | Length | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Protocol |M| Reserved |Nr of Mcast Address Records (N)| 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | | 621 + Multicast Address Record [1] + 622 | | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | | 625 + Multicast Address Record [2] + 626 | | 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 | . | 629 | . | 630 | . | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 | | 633 + Multicast Address Record [N] + 634 | | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Type: 639 To be defined by IANA. 641 Length: 643 8-bit unsigned integer indicating the length of the option in 644 octets, excluding the type and length fields. 646 Protocol: 648 Field used to identify the multicast membership protocol in use, 649 and the corresponding format of the next Multicast Address Record. 650 This field maps the type codification used in the original MLD 651 specifications for the Report message, namely for MLDv2 [RFC3810] 652 the Protocol value MUST be 143, whereas for MLDv1 [RFC2710] the 653 Protocol value MUST be 131. 655 Dynamic IP Multicast Selector Mode Flag (M-bit): 657 This field indicates the subscription via MTMA/direct routing 658 mode. If the (M) flag value is set to a value of (1), it is an 659 indication that the IP multicast traffic associated with the 660 multicast group(s) identified by the Multicast Address Record(s) 661 in this mobility option SHOULD be routed locally (subscription via 662 direct routing mode). If the (M) flag value is set to a value of 663 (0), it is an indication that IP multicast traffic associated with 664 the multicast group(s) identified by the Multicast Address Record 665 in this mobility option(s) SHOULD be routed to the home network, 666 via the MTMA (subscription via MTMA mode). The mobile access 667 gateway MAY also choose to use static pre-established policies 668 instead of following the indications provided by the local 669 mobility anchor. All other IP traffic associated with the mobile 670 node is managed according to a default policy configured at the 671 PMIPv6 multicast domain. 673 Reserved: 675 This field is unused for now. The value MUST be initialized to 0 676 by the sender and MUST be ignored by the receiver. 678 Nr of Mcast Address Records (N) 680 16-bit unsigned integer indicating the number of Mcast Address 681 Records (N) present in this option. 683 Multicast Address Record: 685 Multicast subscription information corresponding to a single 686 multicast address as defined in [RFC3810], or as defined in 687 [RFC2710] for MLDv1. 689 6. Multicast Tree Mobility Anchor Operation 691 The MTMA provides connectivity to the multicast infrastructure out of 692 the PMIPv6 domain. The MTMA itself could either act as an additional 693 MLD proxy (only in the case where all the connected mobile access 694 gateways act also as MLD proxies), reporting to a further node an 695 aggregated view of the subscriptions in a PMIPv6 multicast domain; or 696 it can act as a designated multicast router for all the MAGs in a 697 PMIPv6 multicast domain. The multicast tree mobility anchor will 698 then request the multicast content on behalf of the MAGs (and mobile 699 nodes behind them). In addition, the MTMA will create and maintain 700 the corresponding multicast forwarding states per each tunnel 701 interface towards the MAGs. Whatever the role played, when the MAGs 702 act as MLD proxy, the MTMA becomes the MLD querier of the MLD proxy 703 instance located in each MAG. 705 6.1. Conceptual Data Structures 707 The multicast tree mobility anchor does not directly interact with 708 the mobile nodes attached to any of the mobile access gateways. The 709 MTMA only manages the multicast groups subscribed per MAG on behalf 710 of the MNs attached to it. Having this in mind, the relevant 711 information to be stored in the MTMA should be the tunnel interface 712 identifier (tunnel-if-id) of the bi-directional tunnel for multicast 713 between the MTMA and every MAG (e.g., similar to what is stated in 714 [RFC5213] for the unicast case), the IP addresses of the multicast 715 group delivered per tunnel to each of the MAGs, and the IP addresses 716 of the sources injecting the multicast traffic per tunnel to the 717 multicast domain defined by the MTMA. 719 7. Mobile Node Operation 721 The mobile node operation is not impacted by the existence of an MTMA 722 as anchor for the multicast traffic being subscribed or the use of 723 direct routing. The MN will act according to the stated operations 724 in [RFC5213] and [RFC6224]. 726 This document considers that every mobile node requesting multicast- 727 only services is previously registered in a PMIPv6 unicast domain to 728 get a unicast IP address. The registration can also be required for 729 several purposes such as remote management, billing, multicast 730 configuration, etc. 732 A given mobile node's policy profile information must be updated to 733 be able to store the IPv6 addresses of both the local mobility anchor 734 and multicast tree mobility anchor, the later for the subscription 735 via MTMA case. 737 8. IPv4 support 739 This document does not introduce any IPv4-specific issue regarding 740 [RFC5844]. In order for the solution to support IPv4, all the 741 described network elements (i.e., MAG, MTMA and MR) must support 742 IGMP. In this case, the functionalities of the MAG and MTMA would be 743 as described in [RFC6224], with the MTMA replicating the requirements 744 described for the LMA. For the case of the MR, it must also be dual- 745 stack (i.e., IPv6/IPv4) enabled. 747 Although references to "MLD proxy" have been used in the document, it 748 should be understood to also include "IGMP/MLD proxy" functionality. 750 Regarding the Dynamic IP Multicast Selector Option format, it SHOULD 751 consider IPv4 compatibility in the following way: 753 Protocol field: 755 For IPv4, this field maps the type codification used in the 756 original IGMP specifications for the Report message, in the 757 following way: 759 It MUST be 0x12 in case of using IGMPv1. 761 It MUST be 0x16 in case of using IGMPv2. 763 It MUST be 0x22 in case of using IGMPv3. 765 Multicast Address Record field: 767 This field takes different formats depending on the IGMP version 768 being used by the MN, as follows: 770 * For IGMPv1 it takes the format given by the Group Address in 771 [RFC1112]. 773 * For IGMPv2 it takes the format given by the Group Address in 774 [RFC2236]. 776 * For IGMPv3 it takes the format given by the Group Record in 777 [RFC3376]. 779 9. IANA Considerations 781 This document defines a new mobility option, the Dynamic IP Multicast 782 Selector, which has been assigned the Type TBD by IANA. The Type 783 value for these options has been assigned from the same numbering 784 space as allocated for the other mobility options, as defined in 785 [RFC6275]: http://www.iana.org/assignments/mobility-parameters/ 786 mobility-parameters.xhtml. 788 10. Security Considerations 790 This document describes two complementary operational modes that can 791 be used to deliver multicast traffic in a PMIPv6 domain: multicast 792 anchor and direct routing. Different approaches are described in the 793 document to decide which operational mode is selected: i) the use of 794 pre-configured/pre-provisioned policies at the mobile access gateway, 795 or ii) the use of dynamic policies. Approach ii) could introduce a 796 potential security issue if the protocol signaling is not properly 797 secured. The use of the Dynamic IP Selector Option described in the 798 document requires message integrity protection and source 799 authentication. Hence, the IPsec security mechanism recommended by 800 Proxy Mobile IPv6 [RFC5213] MUST be used to secure the Dynamic IP 801 Selector Option conveyed in the PBA (Proxy Binding Acknowledge). 803 This document does not introduce any additional security threats 804 beyond the current security considerations of PMIPv6 [RFC5213], MLD 805 [RFC3810], IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605]. 807 11. Authors 809 Additional co-authors of this document are: 811 Akbar Rahman 813 InterDigital Communications, LLC 815 E-mail: akbar.rahman@interdigital.com 817 Ignacio Soto 819 Universidad Carlos III de Madrid 821 E-mail: isoto@it.uc3m.es 823 12. References 825 12.1. Normative References 827 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 828 RFC 1112, August 1989. 830 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 831 Requirement Levels", BCP 14, RFC 2119, March 1997. 833 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 834 2", RFC 2236, November 1997. 836 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 837 Listener Discovery (MLD) for IPv6", RFC 2710, 838 October 1999. 840 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 842 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 843 March 2000. 845 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 846 Thyagarajan, "Internet Group Management Protocol, Version 847 3", RFC 3376, October 2002. 849 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 850 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 852 [RFC4065] Kempf, J., "Instructions for Seamoby and Experimental 853 Mobility Protocol IANA Allocations", RFC 4065, July 2005. 855 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 856 "Internet Group Management Protocol (IGMP) / Multicast 857 Listener Discovery (MLD)-Based Multicast Forwarding 858 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 860 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 861 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 863 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 864 Mobile IPv6", RFC 5844, May 2010. 866 [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, 867 S., and J. Laganier, "Heartbeat Mechanism for Proxy Mobile 868 IPv6", RFC 5847, June 2010. 870 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 871 in IPv6", RFC 6275, July 2011. 873 12.2. Informative References 875 [I-D.asaeda-pim-mldproxy-multif] 876 Asaeda, H. and S. Jeon, "Multiple Upstream Interface 877 Support for IGMP/MLD Proxy", 878 draft-asaeda-pim-mldproxy-multif-01 (work in progress), 879 February 2013. 881 [I-D.contreras-multimob-multiple-upstreams] 882 Contreras, L., Bernardos, C., and J. Zuniga, "Extension of 883 the MLD proxy functionality to support multiple upstream 884 interfaces", 885 draft-contreras-multimob-multiple-upstreams-01 (work in 886 progress), February 2013. 888 [I-D.deng-multimob-pmip6-requirement] 889 Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang, 890 "Multicast Support Requirements for Proxy Mobile IPv6", 891 draft-deng-multimob-pmip6-requirement-02 (work in 892 progress), July 2009. 894 [I-D.ietf-mboned-auto-multicast] 895 Bumgardner, G., "Automatic Multicast Tunneling", 896 draft-ietf-mboned-auto-multicast-15 (work in progress), 897 July 2013. 899 [I-D.ietf-multimob-pmipv6-source] 900 Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile 901 Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) 902 Domains", draft-ietf-multimob-pmipv6-source-04 (work in 903 progress), July 2013. 905 [I-D.zhang-pim-muiimp] 906 Zhang, H. and T. Schmidt, "Multi-Upstream Interfaces IGMP/ 907 MLD Proxy", draft-zhang-pim-muiimp-01 (work in progress), 908 July 2013. 910 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 911 Deployment for Multicast Listener Support in Proxy Mobile 912 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 914 Appendix A. MTMA Deployment Use Cases 916 This informative appendix describes, from the network architecture 917 point of view, several deployment options considering the multicast 918 tree mobility anchor (MTMA). These options can be distinguished in 919 terms of the number of LMAs and MTMAs present in a PMIPv6 domain and 920 the service relationship that a set of MNs gets from them, in the 921 form of a "LMA : MTMA" ratio. According to that, it is possible to 922 differentiate the following approaches: 924 o A set of MNs is served in a PMIPv6 domain by two entities, one 925 MTMA for multicast service, and one LMA for unicast, in such a way 926 that the ratio is 1:1 (one common PMIPv6 unicast and multicast 927 domain). 929 o A set of MNs is served in a PMIPv6 domain by several entities, one 930 MTMA for multicast service, while the others (LMAs) for unicast, 931 in such a way that the ratio is N:1 (N PMIPv6 unicast domains 932 coexist with a unique multicast domain). 934 o A set of MNs is served in a PMIPv6 domain by several entities, one 935 LMA for unicast, while the others (MTMAs) are devoted to multicast 936 service, in such a way that the ratio is 1:N (one single PMIPv6 937 unicast domain coexists with multiple multicast domains). 939 Scenarios with an N:M ratio are considered to be a combination of the 940 previous ones. 942 A.1. PMIPv6 domain with ratio 1:1 944 This approach refers to the architecture presented in Figure 1. 945 Within this approach, a common set of MNs is served by a couple of 946 entities, one LMA for unicast and one MTMA for multicast. All the 947 MNs of the set are served by these two elements as they move in the 948 PMIPv6 domain. 950 A.2. PMIPv6 domain with ratio N:1 952 This approach refers to the situation where a common set of MNs is 953 served by a unique MTMA for multicast service, but simultaneously 954 there are subsets from that group of MNs that are served by distinct 955 LMAs for unicast service as they move in the PMIPv6 domain. Each 956 particular MN association with the LMAs (unicast) and MTMA 957 (multicast) remains always the same as it moves in the PMIPv6 domain. 959 Figure 6 shows the scenario here described. 961 +----------------+ +----------------+ 962 |Content Source A| |Content Source B| 963 +----------------+ +----------------+ 964 | | 965 | | 966 *** *** *** *** *** *** *** *** *** *** *** 967 * ** ** ** ** ** ** ** ** ** ** * 968 * * 969 * Fixed Internet * 970 * (Unicast & Multicast Traffic) * 971 * ** ** ** ** ** ** ** ** ** ** * 972 *** *** *** *** *** *** *** *** *** *** *** 973 | | | 974 | | | 975 | | | 976 +------+ +-----------------+ +------+ 977 | LMA1 | | MTMA2 | | LMA3 | 978 +------+ +-----------------+ +------+ 979 || \\ oo oo oo oo // || 980 || \\ oo oo oo oo // || 981 || \\ oo oo oo oo // || 982 || \\ oo oo oo oo // || 983 || \\oo oo oo oo // || 984 || \\ oo oo oo// || 985 || oo\\ oo oo // || 986 || oo \\ oo oo //oo || 987 || oo \\ oo oo // oo || 988 || oo \\ oo oo // oo || 989 +------+ +--------+ +--------+ +--------+ 990 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 991 +------+ +--------+ +--------+ +--------+ 992 | | | | | | | | 993 | | | | | | | | 994 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 996 Figure 6: PMIPv6 domain with ratio N:1 998 Figure 6 proposes an architecture where there are two entities acting 999 as LMAs, LMA1 and LMA3, while there is another one, named MTMA2, 1000 working as multicast tree mobility anchor. LMA1 and LMA3 constitute 1001 two distinct unicast domains, whereas MTMA2 forms a single multicast 1002 domain. The tunnels among MAGs and LMAs represented by lines ("||") 1003 indicate a tunnel transporting unicast traffic, while the tunnels 1004 among MAGs and MTMA2 depicted with circles ("o") show a tunnel 1005 transporting multicast traffic. 1007 In the figure it can be observed that all the MNs are served by MTMA2 1008 for the incoming multicast traffic from sources A or B. However, 1009 there are different subsets regarding unicast traffic, which maintain 1010 distinct associations within the PMIPv6 domain. For instance, the 1011 subset formed by MN10, MN11, MN20 and MN21 is served by LMA1 for 1012 unicast, and the rest of MNs are served by LMA3. For the scenario 1013 described above, the association between each MN and the 1014 corresponding LMA and MTMA is permanently maintained. 1016 A.3. PMIPv6 domain with ratio 1:N 1018 This approach is related to a scenario where a common group of MNs is 1019 served by a unique LMA for unicast service, but simultaneously there 1020 are subsets from that group of MNs which are served by distinct MTMAs 1021 for multicast service as they move in the PMIPv6 domain. Different 1022 MTMAs might be associated with serving different multicast groups. 1023 These associations remain the same even if the MNs move within the 1024 PMIPv6 domain. 1026 Figure 7 shows the scenario here described. 1028 +----------------+ +----------------+ 1029 |Content Source A| |Content Source B| 1030 +----------------+ +----------------+ 1031 | | 1032 | ******************** | 1033 ( ) * * ( ) 1034 ( ) * Fixed Internet * ( ) 1035 ( ) * (Unicast Traffic) * ( ) 1036 ( ) * * ( ) 1037 ( ) ******************** ( ) 1038 | | | 1039 | | | 1040 +------+ +--------------+ +------+ 1041 | MTMA1| | LMA2 | | MTMA3| 1042 +------+ +--------------+ +------+ 1043 oo oo // \\ ^^ ^^ 1044 oo oo // \\ ^^ ^^ 1045 oo oo // \\ ^^ ^^ 1046 oo oo // \\ ^^ ^^ 1047 oo oo/ ^^ ^^ 1048 oo //oo ^^ \\ ^^ 1049 oo // oo ^^ \\ ^^ 1050 oo // oo \\ ^^ 1051 oo // ^^ oo \\ ^^ 1052 oo // ^^ oo \^^ 1053 +-------------+ +-------------+ 1054 | \ / | | \ | | 1055 | ~o~~~~o~ | | ~o~~~~o~ | 1056 | ( MLD w ) | | ( MLD w ) | 1057 | ( multip ) | | ( multip ) | 1058 | ( i/f ) | | ( i/f ) | 1059 | ~~~~~~~~ | | ~~~~~~~~ | 1060 | | | | 1061 | MAG1 | | MAG2 | 1062 /+-------------+ +-------------+\ 1063 | | | | | | 1064 | | | | | | 1065 {MN10} {MN11} {MN12} {MN20} {MN21} {MN22} 1067 Figure 7: PMIPv6 domain with ratio 1:N 1069 Figure 7 proposes an architecture where the LMA2 is the unique LMA 1070 for a certain group of MNs, while there are two other entities, MTMA1 1071 and MTMA3, acting as MTMAs for different subsets of multicast 1072 content. MTMA1 and MTMA3 constitute two distinct multicast domains, 1073 whereas LMA2 forms a single unicast domain. Each MTMA could be 1074 devoted to carry on a different content (for instance, MTMA1 for 1075 source A and MTMA3 for source B). Looking at the figure, all MNs are 1076 served by LMA2 for unicast, while they might be simultaneously served 1077 by MTMA1 and MTMA3, depending on the multicast content. For the 1078 scenario described above, the association between multicast content 1079 and MTMA is permanently maintained. Note that this scenario would 1080 require support for MLD proxy with multiple interfaces 1081 [I-D.ietf-multimob-pmipv6-source], 1082 [I-D.contreras-multimob-multiple-upstreams], 1083 [I-D.asaeda-pim-mldproxy-multif], [I-D.zhang-pim-muiimp] at the MAGs. 1085 A.4. PMIPv6 domain with H-LMA 1087 The H-LMA is defined as an entity that simultaneously transports 1088 unicast and multicast service, that is, it simultaneously works as 1089 LMA and MTMA. In the context of the MTMA solution, an H-LMA can play 1090 the role of MTMA for an entire group of MNs in a PMIPv6 domain, while 1091 acting simultaneously as LMA for a subset of them. Figure 8 adapts 1092 the PMIPv6 domain with ratio N:1 scenario of Figure 7 to the case 1093 where MTMA2 is an H-LMA, which serves multicast traffic to all the 1094 MNs in the picture, and simultaneously, it is able to serve unicast 1095 traffic to the subset formed by MN30, MN40 and MN41. 1097 +----------------+ +----------------+ 1098 |Content Source A| |Content Source B| 1099 +----------------+ +----------------+ 1100 | | 1101 | | 1102 *** *** *** *** *** *** *** *** *** *** *** 1103 * ** ** ** ** ** ** ** ** ** ** * 1104 * * 1105 * Fixed Internet * 1106 * (Unicast & Multicast Traffic) * 1107 * ** ** ** ** ** ** ** ** ** ** * 1108 *** *** *** *** *** *** *** *** *** *** *** 1109 | | | 1110 | | | 1111 | | | 1112 +------+ +-----------------+ +------+ 1113 | LMA1 | | H-LMA | | LMA3 | 1114 +------+ +-----------------+ +------+ 1115 || \\ oo db db oo // || 1116 || \\ oo db db oo // || 1117 || \\ oo db db oo // || 1118 || \\ oo db db oo // || 1119 || \\oo db db oo // || 1120 || \\ db db oo// || 1121 || oo\\ db db // || 1122 || oo \\ db db //oo || 1123 || oo \\ db db // oo || 1124 || oo \\ db db // oo || 1125 +------+ +--------+ +--------+ +--------+ 1126 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 1127 +------+ +--------+ +--------+ +--------+ 1128 | | | | | | | | 1129 | | | | | | | | 1130 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 1132 Figure 8: PMIPv6 domain with H-LMA 1134 Figure 8 presents a PMIPv6 network where there are two pure unicast 1135 LMAs, LMA1 and LMA3, and a hybrid LMA, labeled as H-LMA in the 1136 figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4. 1137 The tunnels among MAGs and LMAs represented by lines ("||") indicate 1138 a tunnel transporting exclusively unicast traffic, the tunnels 1139 depicted with circles ("o") show a tunnel transporting exclusively 1140 multicast traffic, and the tunnels with mixed lines and circles 1141 ("db") describe a tunnel transporting both types of traffic 1142 simultaneously. 1144 All of the MNs in the figure receive the multicast traffic from H-LMA 1145 (one single multicast domain), but it is possible to distinguish 1146 three subsets from the unicast service perspective (that is, three 1147 unicast domains). The first subset is the one formed by MN10, MN11 1148 and MN20, which receives unicast traffic from LMA1. A second subset 1149 is the one formed by MN21 and MN30, which receives unicast traffic 1150 from H-LMA. And finally, a third subset is built on MN31, MN40 and 1151 MN41, which receives unicast traffic from LMA3. For the scenario 1152 described above, the association between each MN and the 1153 corresponding LMA and H-LMA is permanently maintained. 1155 Authors' Addresses 1157 Juan Carlos Zuniga 1158 InterDigital Communications, LLC 1159 1000 Sherbrooke Street West, 10th floor 1160 Montreal, Quebec H3A 3G4 1161 Canada 1163 Email: JuanCarlos.Zuniga@InterDigital.com 1164 URI: http://www.InterDigital.com/ 1166 Luis M. Contreras 1167 Telefonica I+D 1168 Don Ramon de la Cruz, 82-84 1169 Madrid 28006 1170 Spain 1172 Email: lmcm@tid.es 1174 Carlos J. Bernardos 1175 Universidad Carlos III de Madrid 1176 Av. Universidad, 30 1177 Leganes, Madrid 28911 1178 Spain 1180 Phone: +34 91624 6236 1181 Email: cjbc@it.uc3m.es 1182 URI: http://www.it.uc3m.es/cjbc/ 1183 Seil Jeon 1184 Instituto de Telecomunicacoes 1185 Campus Universitario de Santiago 1186 Aveiro 3810-193 1187 Portugal 1189 Email: seiljeon@av.it.pt 1190 URI: https://atnog.av.it.pt/~sjeon/ 1192 Younghan Kim 1193 Soongsil University 1194 Sangdo-dong, Dongjak-gu 1195 Seoul 511 1196 Republic of Korea 1198 Email: yhkim@dcn.ssu.ac.kr 1199 URI: http://dcnlab.ssu.ac.kr/