idnits 2.17.00 (12 Aug 2021) /tmp/idnits63075/draft-zuniga-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 351 has weird spacing: '... oo oo ...' == Line 352 has weird spacing: '... oo oo ...' == Line 431 has weird spacing: '... oo oo...' == Line 432 has weird spacing: '... oo oo ...' == Line 433 has weird spacing: '... oo oo ...' == (3 more instances...) -- The document date (October 30, 2011) is 3849 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.gundavelli-netext-pmipv6-sipto-option' is defined on line 1158, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group J. C. Zuniga 3 INTERNET-DRAFT (InterDigital Communications, LLC) 4 Intended Status: Standards Track L. M. Contreras 5 Expires: May 2, 2012 (Telefonica I+D) 6 C. J. Bernardos 7 (Universidad Carlos III de Madrid) 8 S. Jeon 9 Y. Kim 10 (Soongsil University) 11 October 30, 2011 13 Multicast Mobility Routing Optimizations for Proxy Mobile IPv6 14 16 Abstract 18 The MULTIMOB group has specified a base solution to support IP 19 multicasting in a PMIPv6 domain [RFC6224]. In this document, some 20 enhancements are proposed to the base solution. These enhancements 21 include the use of a multicast tree mobility anchor as the 22 topological anchor point for multicast traffic, as well as a direct 23 routing option where the MAG can provide access to multicast content 24 in the local network. These enhancements provide benefits such as 25 reducing multicast traffic replication and supporting different 26 PMIPv6 deployments scenarios. 28 Status of this Memo 30 This Internet-Draft is submitted to IETF in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/1id-abstracts.html 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html 48 Copyright and License Notice 50 Copyright (c) 2011 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2 Conventions and Terminology . . . . . . . . . . . . . . . . . . 4 67 3 Multicast Tree Mobility Anchor (MTMA) . . . . . . . . . . . . . 5 68 3.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.2 Deployment Scenarios . . . . . . . . . . . . . . . . . . . 7 70 3.2.1 PMIPv6 domain with ratio 1:1 . . . . . . . . . . . . . 8 71 3.2.2 PMIPv6 domain with ratio N:1 . . . . . . . . . . . . . 8 72 3.2.3 PMIPv6 domain with ratio 1:N . . . . . . . . . . . . 10 73 3.2.4 PMIPv6 domain with H-LMA . . . . . . . . . . . . . . 11 74 3.3 Multicast Establishment . . . . . . . . . . . . . . . . . 14 75 3.4 Multicast Mobility . . . . . . . . . . . . . . . . . . . 15 76 3.5 PMIPv6 enhancements . . . . . . . . . . . . . . . . . . . 16 77 3.5.1 New Binding Update List in MAG . . . . . . . . . . . 16 78 3.5.2 Policy Profile Information with Multicast Parameters 17 79 3.5.3 MAG to MTMA attach requirements . . . . . . . . . . 17 80 3.5.4. Data structure stored by MTMA . . . . . . . . . . . 17 81 3.6 Advantages . . . . . . . . . . . . . . . . . . . . . . . 17 82 4 Direct routing . . . . . . . . . . . . . . . . . . . . . . . . 21 83 4.1 MAG as MLD proxy . . . . . . . . . . . . . . . . . . . . . 22 84 4.1.1 Local subscription when the MAG implements MLD proxy 85 functionality . . . . . . . . . . . . . . . . . . . 22 86 4.1.1.1 Local subscription architecture . . . . . . . . 22 87 4.1.1.2 Handover procedure for local routing . . . . . . 23 88 4.1.2 Remote subscription when the MAG implements MLD 89 proxy functionality . . . . . . . . . . . . . . . . . 24 90 4.2 MAG as multicast router . . . . . . . . . . . . . . . . . 25 91 4.2.1 Local subscription when the MAG implements a 92 multicast routing protocol . . . . . . . . . . . . . 25 93 4.2.2 Remote subscription when the MAG implements a 94 multicast routing protocol . . . . . . . . . . . . . 25 95 5 Dynamic selection of local versus remote multicast subscription 25 96 5.1 Any source multicast scenario . . . . . . . . . . . . . . 26 97 5.2 Source specific multicast scenario . . . . . . . . . . . . 26 98 6 Security Considerations . . . . . . . . . . . . . . . . . . . 27 99 7 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 100 8 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 102 9.1 Normative References . . . . . . . . . . . . . . . . . . 27 103 9.2 Informative References . . . . . . . . . . . . . . . . . 28 104 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 106 1 Introduction 108 Proxy Mobile IPv6 [RFC5213] is a network-based approach to solving 109 the IP mobility problem. In a Proxy Mobile IPv6 (PMIPv6) domain, the 110 Mobile Access Gateway (MAG) behaves as a proxy mobility agent in the 111 network and does the mobility management on behalf of the Mobile Node 112 (MN). The Local Mobility Anchor (LMA) is the home agent for the MN 113 and the topological anchor point. PMIPv6 was originally designed for 114 unicast traffic. 116 The Internet Group Management Protocol (IGMPv3) [RFC3376] is used by 117 IPv4 hosts to report their IP multicast group memberships to 118 neighboring multicast routers. Multicast Listener Discovery (MLDv2) 119 [RFC3810] is used in a similar way by IPv6 routers to discover the 120 presence of IPv6 multicast hosts. Also, the IGMP/MLD proxy [RFC4605] 121 allows an intermediate (edge) node to appear as a multicast router to 122 downstream hosts, and as a host to upstream multicast routers. IGMP 123 and MLD related protocols were not originally designed to address IP 124 mobility of multicast listeners (i.e. IGMP and MLD protocols were 125 originally designed for fixed networks). 127 The MULTIMOB group has specified a base solution to support IP 128 multicast listener mobility in a PMIPv6 domain [RFC6224], which 129 describes deployment options without modifying mobility and multicast 130 protocol standards. The PMIPv6 allows a MAG to establish a multiple 131 of PMIPv6 tunnels with LMAs. Hence, when IP multicasting is applied 132 into PMIPv6, it leads to redundant traffic at a MAG called "Tunnel 133 Convergence problem". To address this issue, two enhancements are 134 proposed in this document; multicast anchor and direct routing. The 135 former uses a multicast tree mobility anchor (MTMA) as the 136 topological anchor point for delivering multicast traffic, while the 137 latter uses direct routing, allowing a MAG to connect directly to a 138 multicast router for simple access to local content. Both schemes 139 have no impact on the MN to support multicast listener mobility. 141 The MTMA architecture and solution are described in section 3. 142 Section 4 describes the direct routing solution and the enhancements 143 details. Section 5 describes the details about the selection at the 144 MAG between direct routing (e.g. for local access) and MTMA (e.g. for 145 remote access). 147 2 Conventions and 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 RFC 2119 [RFC2119]. 153 This document uses the terminology defined in [RFC5213], [RFC3775], 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 158 domain refers to the network where the mobility management of a 159 mobile node is handled using the Proxy Mobile IPv6 protocol as 160 defined in [RFC5213]. The Proxy Mobile IPv6 domain includes local 161 mobility 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 169 network covered by one LMA for unicast service in such a way that 170 an MN using that service is not aware of mobility as it moves from 171 one MAG to another associated to that LMA regarding its unicast 172 traffic. 174 - PMIPv6 multicast domain: PMIPv6 multicast domain refers to the 175 network covered by one network element named MTMA (defined below) 176 for multicast service in such a way that an MN using that service 177 is not aware of mobility as it moves from one MAG to another. 179 - Direct routing: it uses native multicast infrastructure for 180 retrieving multicast data. For the operator having its own local 181 content, this technique also includes the case that content source 182 is directly connected to a MAG. 184 This means that a PMIPv6 domain can have several PMIPv6 unicast 185 domains and PMIPv6 multicast domains. 187 Additionally, some other definitions are introduced, as follows. 189 - MTMA or multicast tree mobility anchor: an entity working as 190 topological anchor point for multicast traffic exclusively. 192 - H-LMA or Hybrid-LMA: an entity dedicated to both unicast and 193 multicast services, that is, it is able to work as both LMA and 194 MTMA simultaneously. 196 3 Multicast Tree Mobility Anchor (MTMA) 198 A PMIPv6 domain may handle data from both unicast and multicast 199 sources. This document addresses optimizations to the base solution 200 specified for multicast support in PMIPv6 domains [RFC6224] by 201 firstly introducing a complementary network entity, named multicast 202 tree mobility anchor (MTMA), and defining the architecture and 203 protocol flows derived from it; and secondly by defining a direct 204 routing option where a MAG can directly receive packets from a 205 multicast router. 207 An MTMA can be used to serve as the mobility anchor for multicast 208 traffic. The MTMA connects to the MAG as described in [RFC6224] and 209 it can reuse native PMIPv6 features such as tunnel establishment and 210 security [RFC5213], heartbeat [RFC5847], etc. Unicast traffic will go 211 normally to the LMAs in the PMIPv6 domain. 213 This section describes how the MTMA works in scenarios of MN 214 attachment and multicast mobility. We first concentrate on the case 215 of both LMA and MTMA defining a unique PMIPv6 domain, and then 216 different deployment scenarios are presented. 218 3.1 Architecture 220 Figure 1 shows an example of a PMIPv6 domain supporting multicast 221 mobility. LMA1 is dedicated to unicast traffic, and MTMA1 is 222 dedicated to multicast traffic. The tree mobility anchor MTMA1 can be 223 considered to be a form of upstream multicast router with tunnel 224 interfaces allowing remote subscription for the MNs. Note that there 225 can be multiple LMAs for unicast traffic (not shown in Figure 1) in a 226 given PMIPv6 domain. Similarly, more than one MTMA can be deployed by 227 the operator (not shown in Figure 1). 229 Also in this architecture, all MAGs that are connected to the MTMA 230 must support the MLD proxy [RFC4605] function. Specifically in Figure 231 1, each of the MAG1-MTMA1 and MAG2-MTMA1 tunnel interfaces defines an 232 MLD proxy domain. The MNs are considered to be on the downstream 233 interface of the MLD proxy (in the MAG), and MTMA1 is considered to 234 be on the upstream interface (of the MAG) as per [RFC4605]. Note 235 that MAG could also be an IGMP proxy. For brevity this document will 236 refer primarily to MLD proxy, but all references to "MLD proxy" 237 should be understood to also include "IGMP/MLD proxy" functionality. 239 As shown in Figure 1, MAG1 may connect to both unicast (LMAs) and 240 multicast (MTMAs) entities. Thus, a given MN may simultaneously 241 receive both unicast and multicast traffic. In Figure 1, MN1 and MN2 242 receive unicast traffic, multicast traffic, or both, whereas MN3 243 receives multicast traffic only, despite of that, this draft 244 considers that every MN demanding multicast-only services is 245 previously registered in a PMIPv6 unicast domain to get a unicast IP 246 address. This registration can be required also for several purposes 247 such as remote management, billing, etc. 249 +--------------+ 250 |Content Source| 251 +--------------+ 252 | 253 | 254 *** *** *** *** *** *** *** *** 255 * ** ** ** * * ** ** ** * 256 * * * * 257 * Unicast Traffic * * Multicast Traffic * 258 * * * * 259 * ** ** ** * * ** ** ** * 260 *** *** *** *** *** *** *** *** 261 | | 262 | | 263 | | 264 +-----+ +------+ 265 Unicast | LMA1| | MTMA1| Multicast 266 Anchor +-----+ +------+ Anchor 267 \\ // || 268 \\ // || 269 \\ // || 270 \\ // || 271 \\ // || 272 \\ // || 273 \\ // || 274 \\ // || 275 \\ // || 276 +-----+ +-----+ 277 | MAG1| | MAG2| MLD Proxy 278 +-----+ +-----+ 279 | | | 280 | | | 281 {MN1} {MN2} {MN3} 283 Figure 1. Architecture of Multicast Tree Mobility Anchor (MTMA) 285 3.2 Deployment Scenarios 287 From the network architecture point of view, there are several 288 options when considering the multicast tree mobility anchor (MTMA) 289 approach. These options can be distinguished in terms of the number 290 of LMAs and MTMAs present in a PMIPv6 domain and the service 291 relationship that a set of MNs gets from them, in the form of a "LMA 292 : MTMA" ratio. According to that, it is possible to differentiate the 293 following approaches: 295 - A set of MNs is served in a PMIPv6 domain by two entities, one 296 MTMA for multicast service, and one LMA for unicast, in such a way 297 that the ratio is 1:1 (one common PMIPv6 unicast and multicast 298 domain). 300 - A set of MNs is served in a PMIPv6 domain by several entities, 301 one MTMA for multicast service, while the others (LMAs) for 302 unicast, in such a way that the ratio is N:1 (N PMIPv6 unicast 303 domains coexist with a unique multicast domain). 305 - A set of MNs is served in a PMIPv6 domain by several entities, 306 one LMA for unicast, while the others (MTMAs) are devoted to 307 multicast service, in such a way that the ratio is 1:N (one single 308 PMIPv6 unicast domain coexists with multiple multicast domains). 310 Scenarios with an N:M ratio are considered to be a combination of the 311 previous ones. 313 3.2.1 PMIPv6 domain with ratio 1:1 315 This approach basically refers to the architecture presented in 316 figure 1. Within this approach, a common set of MNs is served by a 317 couple of entities, one LMA for unicast and one MTMA for multicast. 318 All the MNs of the set are served by these two elements as they move 319 in the PMIPv6 domain. 321 3.2.2 PMIPv6 domain with ratio N:1 323 This approach basically refers to the situation where a common set of 324 MNs is served by a unique MTMA for multicast service, but 325 simultaneously there are subsets from that group of MNs which are 326 served by distinct LMAs for unicast service as they move in the 327 PMIPv6 domain. Each particular MN association with the LMAs (unicast) 328 and MTMA (multicast) remains always the same as it moves in the 329 PMIPv6 domain. 331 Figure 2 shows the scenario here described. 333 +----------------+ +----------------+ 334 |Content Source A| |Content Source B| 335 +----------------+ +----------------+ 336 | | 337 | | 338 *** *** *** *** *** *** *** *** *** *** *** 339 * ** ** ** ** ** ** ** ** ** ** * 340 * * 341 * Fixed Internet * 342 * (Unicast & Multicast Traffic) * 343 * ** ** ** ** ** ** ** ** ** ** * 344 *** *** *** *** *** *** *** *** *** *** *** 345 | | | 346 | | | 347 | | | 348 +-------+ +-----------------+ +-------+ 349 | LMA1 | | MTMA2 | | LMA3 | 350 +-------+ +-----------------+ +-------+ 351 || \\ oo oo oo oo // || 352 || \\ oo oo oo oo // || 353 || \\ oo oo oo oo // || 354 || \\ oo oo oo oo // || 355 || \\oo oo oo oo // || 356 || \\ oo oo oo// || 357 || oo\\ oo oo // || 358 || oo \\ oo oo //oo || 359 || oo \\ oo oo // oo || 360 || oo \\ oo oo // oo || 361 +------+ +--------+ +--------+ +--------+ 362 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 363 +------+ +--------+ +--------+ +--------+ 364 | | | | | | | | 365 | | | | | | | | 366 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 368 Figure 2. PMIPv6 domain with ratio N:1 370 The figure 2 proposes an architecture where there are two entities 371 acting as LMAs, LMA1 and LMA3, while there is another one, named 372 MTMA2, working as multicast tree mobility anchor. LMA1 and LMA3 373 constitute two distinct unicast domains, whereas MTMA2 forms a single 374 multicast domain. The tunnels among MAGs and LMAs represented by 375 lines ("||") indicate a tunnel transporting unicast traffic, while 376 the tunnels among MAGs and MTMA2 depicted with circles ("o") show a 377 tunnel transporting multicast traffic. 379 In the figure it can be observed that all the MNs are served by MTMA2 380 for the incoming multicast traffic from sources A or B. However, 381 there are different subsets regarding unicast traffic which maintain 382 distinct associations within the PMIPv6 domain. For instance, the 383 subset formed by MN10, MN11, MN20 and MN21 is served by LMA1 for 384 unicast, and the rest of MNs are being served by LMA3. For the 385 scenario described above, the association between each MN and the 386 corresponding LMA and MTMA is permanently maintained. 388 3.2.3 PMIPv6 domain with ratio 1:N 390 This approach is related to a scenario where a common group of MNs is 391 served by a unique LMA for unicast service, but simultaneously there 392 are subsets from that group of MNs which are served by distinct MTMAs 393 for multicast service as they move in the PMIPv6 domain. Each 394 particular MN association with the LMA and MTMAs (unicast and 395 multicast respectively) remains always the same as it moves in the 396 PMIPv6 domain. 398 Figure 3 shows the scenario here described. 400 The figure 3 proposes an architecture where the LMA2 is the unique 401 LMA for a certain group of MNs, while there are two others entities, 402 MTMA1 and MTMA3, acting as MTMAs for different subsets of MNs of the 403 same group. MTMA1 and MTMA3 constitute two distinct multicast 404 domains, whereas LMA2 forms a single unicast domain. Each MTMA could 405 be devoted to carry on a different content (for instance, MTMA1 for 406 source A and MTMA3 for source B) or not. Looking at the picture, the 407 subset formed by MN10, MN11, MN20 and MN21 is served by MTMA1 for 408 multicast. The rest of MNs are being served by MTMA3 also for 409 multicast. Finally, all of them are served by LMA2 for unicast. For 410 the scenario described above, the association between each MN and the 411 corresponding LMA and MTMA is permanently maintained. 413 +----------------+ +----------------+ 414 |Content Source A| |Content Source B| 415 +----------------+ +----------------+ 416 | | 417 | | 418 *** *** *** *** *** *** *** *** *** *** *** 419 * ** ** ** ** ** ** ** ** ** ** * 420 * * 421 * Fixed Internet * 422 * (Unicast & Multicast Traffic) * 423 * ** ** ** ** ** ** ** ** ** ** * 424 *** *** *** *** *** *** *** *** *** *** *** 425 | | | 426 | | | 427 | | | 428 +-------+ +-----------------+ +-------+ 429 | MTMA1 | | LMA2 | | MTMA3 | 430 +-------+ +-----------------+ +-------+ 431 oo oo // || || \\ oo oo 432 oo oo // || || \\ oo oo 433 oo oo // || || \\ oo oo 434 oo oo // || || \\ oo oo 435 oo oo// || || \\ oo oo 436 oo oo || || \\oo oo 437 oo //oo || || \\ oo 438 oo // oo || || oo\\ oo 439 oo // oo || || oo \\ oo 440 oo // oo || || oo \\ oo 441 +------+ +--------+ +--------+ +--------+ 442 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 443 +------+ +--------+ +--------+ +--------+ 444 | | | | | | | | 445 | | | | | | | | 446 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 448 Figure 3. PMIPv6 domain with ratio 1:N 450 3.2.4 PMIPv6 domain with H-LMA 452 The H-LMA is defined as an entity which simultaneously transports 453 unicast and multicast service, that is, it simultaneously works as 454 LMA and MTMA. In the context of the MTMA solution, an H-LMA can play 455 the role of MTMA for an entire group of MNs in a PMIPv6 domain, while 456 acting simultaneously as LMA for a subset of them. The figure 4 457 adapts the PMIPv6 domain with ratio N:1 scenario of figure 2 to the 458 case where MTMA2 is an H-LMA, which serves multicast traffic to all 459 the MNs in the picture, and simultaneously, it is able to serve 460 unicast traffic to the subset formed by MN30, MN40 and MN41. 462 Figure 4 presents a PMIPv6 network where there are two pure unicast 463 LMAs, LMA1 and LMA3, and a hybrid LMA, labeled as H-LMA in the 464 figure. The H-LMA is an MTMA from the perspective of MAG1 and MAG4. 465 The tunnels among MAGs and LMAs represented by lines ("||") indicate 466 a tunnel transporting exclusively unicast traffic, the tunnels 467 depicted with circles ("o") show a tunnel transporting exclusively 468 multicast traffic, and the tunnels with mixed lines and circles 469 ("db") describe a tunnel transporting both types of traffic 470 simultaneously. 472 All of the MNs in the figure receive the multicast traffic from H-LMA 473 (one single multicast domain), but it is possible to distinguish 474 three subsets from the unicast service perspective (that is, three 475 unicast domains). The first subset is the one formed by MN10, MN11 476 and MN 20, which receives unicast traffic from LMA1. A second subset 477 is the one formed by MN21 and MN30, which receives unicast traffic 478 from H-LMA. And finally, a third subset is built on MN31, MN40 and 479 MN41, which receives unicast traffic from LMA3. For the scenario 480 described above, the association between each MN and the 481 corresponding LMA and H-LMA is permanently maintained. 483 +----------------+ +----------------+ 484 |Content Source A| |Content Source B| 485 +----------------+ +----------------+ 486 | | 487 | | 488 *** *** *** *** *** *** *** *** *** *** *** 489 * ** ** ** ** ** ** ** ** ** ** * 490 * * 491 * Fixed Internet * 492 * (Unicast & Multicast Traffic) * 493 * ** ** ** ** ** ** ** ** ** ** * 494 *** *** *** *** *** *** *** *** *** *** *** 495 | | | 496 | | | 497 | | | 498 +-------+ +-----------------+ +-------+ 499 | LMA1 | | H-LMA | | LMA3 | 500 +-------+ +-----------------+ +-------+ 501 || \\ oo db db oo // || 502 || \\ oo db db oo // || 503 || \\ oo db db oo // || 504 || \\ oo db db oo // || 505 || \\oo db db oo // || 506 || \\ db db oo// || 507 || oo\\ db db // || 508 || oo \\ db db //oo || 509 || oo \\ db db // oo || 510 || oo \\ db db // oo || 511 +------+ +--------+ +--------+ +--------+ 512 | MAG1 | | MAG2 | | MAG3 | | MAG4 | 513 +------+ +--------+ +--------+ +--------+ 514 | | | | | | | | 515 | | | | | | | | 516 {MN10} {MN11} {MN20} {MN21} {MN30} {MN31} {MN40} {MN41} 518 Figure 4. PMIPv6 domain with H-LMA 520 3.3 Multicast Establishment 522 Figure 5 shows the procedure when MN1 attaches to MAG1, and 523 establishes associations with LMA (unicast) and MTMA (multicast). 525 MN1 MAG1 LMA MTMA 526 | (MLD Proxy) (Unicast) (Multicast) 527 MN attaches to MAG1 | | | 528 | | | | 529 |------Rtr Sol----- ->| | | 530 | |--PBU -- >| | 531 | | | | 532 | |<-- PBA --| | 533 | | | | 534 | |=Unicast= | | 535 | | Tunnel | | 536 |<-----Rtr Adv ------ | | | 537 | | | | 538 |< ------ Unicast Traffic------ >| | 539 | | | | 540 | |==Multicast Tunnel ==| 541 | | | | 542 |<--MLD Query --------| | | 543 | | | | 544 MN requires | | | 545 multicast services | | | 546 | | | | 547 |---MLD Report (G) -->| | | 548 | | | | 549 | |---- Aggregated ---> | 550 | | MLD Report (G) | 551 | | | | 552 | | | | 553 |< --------- Multicast Traffic ----------- >| 554 | | | | 556 Figure 5. MN Attachment and Multicast Service Establishment 558 In Figure 5, MAG1 first establishes the PMIPv6 tunnel with LMA for 559 unicast traffic as defined in [RFC5213] after being triggered by the 560 Router Solicitation message from MN1. Unicast traffic will then flow 561 between MN1 and LMA. 563 For multicast traffic, a multicast tunnel may have been pre- 564 configured between MAG1 and MTMA. Or the multicast tunnel may be 565 dynamically established when the first MN appears at the MAG. 567 MN1 sends the MLD report message (when required by its upper layer 568 applications) as defined in [RFC3810] in response to an MLD Query 569 from MAG1. MAG1 acting as a MLD Proxy as defined in [RFC4605] will 570 then send an Aggregated MLD Report to the multicast anchor, MTMA 571 (assuming that this is a new multicast group which MAG1 had not 572 previously subscribed to). Multicast traffic will then flow from 573 MTMA towards MN1. 575 3.4 Multicast Mobility 577 Figure 6 illustrates the mobility scenario for multicast traffic. 578 Specifically, MN2 with ongoing multicast subscription moves from MAG1 579 to MAG2. Note that, for simplicity, in this scenario we only 580 consider the tunnel of MAG2 with MTMA (for multicast traffic) and we 581 assume that MN2 does not receive unicast traffic. Of course, if it 582 was desired to support unicast traffic, this is served by a tunnel 583 between MAG2 and LMA to transfer unicast traffic. 585 According to baseline solution signaling method described in 586 [RFC6224], after MN2 mobility, MAG2 acting in its role of MLD proxy 587 will send an MLD Query to the newly observed MN on its downlink. 588 Assuming that the subsequent MLD Report from MN2 requests membership 589 of a new multicast group (from MAG2's point of view), this will then 590 result in an Aggregated MLD Report being sent to MTMA from MAG2. This 591 message will be sent through a pre-established (or dynamically 592 established) multicast tunnel between MAG2 and MTMA. 594 When MN2 detaches, MAG1 may keep the multicast tunnel with the 595 multicast MTMA if there are still other MNs using the multicast 596 tunnel. Even if there are no MNs currently on the multicast tunnel, 597 MAG1 may decide to keep the multicast tunnel for potential future 598 use. 600 As discussed above, existing MLD (and Proxy MLD) signaling will 601 handle a large part of the multicast mobility management for the MN. 603 MN2 MAG1 MAG2 LMA MTMA 604 | (MLD Proxy) (MLD Proxy) (Unicast)(Multicast) 605 | | | | | 606 MN Attached | | | | 607 To MAG1 | | | | 608 | | | | | 609 | |========= Multicast Tunnel ======= | 610 | | | | | 611 MN Detaches | | | | 612 From MAG1 | | | | 613 | | | | | 614 | | | | | 615 MN Attaches | | | | 616 To MAG2 | | | | 617 | | | | | 618 | | |==Multicast Tunnel === | 619 | | | | | 620 |---------Rtr Sol------ >| | | 621 | | |--- PBU --->| | 622 | | | | | 623 | | |<-- PBA ----| | 624 |<-----Rtr Adv --------- | | | 625 | | | | | 626 | | | | | 627 |<---------MLD Query---- | | | 628 | | | | | 629 |---MLD Report (G) ----> | | | 630 | | | | | 631 | | |---- Aggregated -----> | 632 | | | MLD Report (G) | 633 | | | | | 634 |< --------- Multicast Traffic ---------------- >| 635 | | | | | 636 | | | | | 638 Figure 6. Multicast Mobility Signaling 640 3.5 PMIPv6 enhancements 642 This section describes the enhancements to the Proxy Mobile IPv6 643 [RFC5213] protocol required to support the MTMA architecture. 645 3.5.1 New Binding Update List in MAG 647 The Binding Update List in the MAG must be updated to be able to 648 handle the fact that more than one entity (i.e. LMA and MTMA) may be 649 serving the mobile node. 651 3.5.2 Policy Profile Information with Multicast Parameters 653 A given mobile node's policy profile information must be updated to 654 be able to store the IPv6 addresses of both the LMA and MTMA. 656 3.5.3 MAG to MTMA attach requirements 658 The MAG procedures must be updated to be able to handle simultaneous 659 attach for a given mobile node to both the LMA and MTMA. For example, 660 packets coming from a given mobile node must be screened to determine 661 if it should be sent to the LMA or to the MTMA. 663 3.5.4. Data structure stored by MTMA 665 The MTMA does not directly interact with the MNs attached to any of 666 the MAGs. The MTMA only manages the multicast groups subscribed per 667 MAG on behalf of the MNs attached to it. Having this in mind, the 668 relevant information to be stored in the MTMA should be the tunnel 669 interface identifier (tunnel-if-id) of the bi-directional tunnel for 670 multicast between the MTMA and every MAG (as stated in [RFC5213] for 671 the unicast case), the IP addresses of the multicast group delivered 672 per tunnel to each of the MAGs, and the IP addresses of the sources 673 injecting the multicast traffic per tunnel to the multicast domain 674 defined by the MTMA. 676 3.6 Advantages 678 An advantage of the proposed MTMA architecture is that it allows a 679 PMIPv6 domain to closely follow a simple multicast tree topology for 680 Proxy MLD forwarding (cf., sections 1.1 and 1.2 of [RFC4605]). In 681 contrast, the combined unicast/multicast LMA as proposed in [RFC6224] 682 will be a more complex set of trees. 684 Another advantage of the proposed dedicated multicast solution is 685 that it allows a gradual network upgrade of a PMIPv6 domain to 686 support multicast functionality. This is because the operator does 687 not have to upgrade all the LMAs in the network to support multicast 688 functionality. Only certain nodes (MTMAs), dedicated to multicast 689 support, will have to be upgraded to support the new multicast 690 functionality. Also, multiple deployment scenarios are supported as 691 required by the operator for expected traffic distributions. 693 A final advantage is that a specific multicast elements minimize the 694 replication of multicast packets (the Tunnel Convergence problem), in 695 certain scenarios, compared to [RFC6224]. Figures 7 and 8 illustrate 696 this point visually. For this simple scenario, it can be observed 697 that the multicast MTMA topology (Figure 7) generates 6 packets for 698 one input multicast packet. In comparison, the combined 699 unicast/multicast LMA topology (Figure 8) generates 8 packets for one 700 input multicast packet. 702 In general, it can be seen that the extra multiplication of packets 703 in the combined unicast/multicast LMA topology will be proportional 704 to the number of LMAs, and the number of MNs (in a given MAG) 705 associated to different LMAs, for a given multicast group. The 706 packet multiplication problem aggravates as more MNs associated to 707 different LMAs receive the same multicast traffic when attached to 708 the same MAG. Hence, the MTMA architecture significantly decreases 709 the network capacity requirements in this scenario. 711 (Note that in Figure 7, it is assumed that MN1 and MN2 are associated 712 with MAG1-LMA1, and MN3 is associated with MAG2-MTMA2 for multicast 713 traffic. In Figure 8, it is assumed that MN1 is associated with 714 MAG1-LMA1, MN2 is associated with MAG1-LMA2, and MN3 is associated 715 with MAG2-LMA2 for multicast traffic. In both Figures 7 and 8, it is 716 assumed that the packets are transmitted point to point on the last 717 hop wireless link.) 719 Additional results can be found in [ERCIM], where both solutions are 720 compared by simulation under realistic traffic conditions. It can be 721 shown that, for multicast traffic, the number of channels that a node 722 (LMA in the base solution, MTMA in the proposed multicast 723 architecture) has to serve does not decrease linearly with the 724 reduction of the number of MNs associated to that node. The key 725 factor is the set of channels subscribed by the MNs. In fact, as the 726 number of MNs increases in the PMIPv6 domain, we have less advantage 727 for having several nodes serving multicast, as each of them will 728 probably manage all the multicast channels (or at least the popular 729 ones) anyway. 731 +--------------+ 732 |Content Source| 733 +--------------+ 734 | 735 | 736 +---+ Packet destined 737 | 1 | for Multicast group "G" 738 +---+ 739 | 740 *** *** *** *** *** *** *** *** 741 * ** ** ** * * ** ** ** * 742 * * * * 743 * Unicast Traffic * * Multicast Traffic * 744 * * * * 745 * ** ** ** * * ** ** ** * 746 *** *** *** *** *** *** *** *** 747 | | 748 | +---+ 749 | | 2 | 750 | +---+ 751 | | 752 +-----+ +------+ 753 Unicast | LMA1| | MTMA2| Multicast 754 Anchor +-----+ +------+ Anchor 755 \\ //|| 756 \\ // || 757 \\ // || 758 \\ // || 759 \\ +---+ +---+ 760 \\ | 3 | | 4 | 761 \\ +---+ +---+ 762 \\ // || 763 \\ // || 764 \\ // || 765 \\ // || 766 +-----+ +-----+ 767 | MAG1| | MAG2| MLD Proxy 768 +-----+ +-----+ 769 | | | 770 +---+ +---+ +---+ 771 | 5 | | 6 | | 7 | 772 +---+ +---+ +---+ 773 | | | All MNs in same 774 | | | multicast group "G" 775 {MN1} {MN2} {MN3} 777 Figure 7. Packet Flow in the MTMA architecture 778 +--------------+ 779 |Content Source| 780 +--------------+ 781 | 782 | 783 +---+ Packet destined 784 | 1 | for Multicast group "G" 785 +---+ 786 | 787 *** *** *** *** *** *** *** *** *** 788 * ** ** ** ** ** ** ** ** * 789 * * 790 * Fixed Internet * 791 * (Unicast & Multicast Traffic) * 792 * ** ** ** ** ** ** ** ** * 793 *** *** *** *** *** *** *** *** 794 | | 795 +---+ +---+ 796 | 2 | | 3 | 797 +---+ +---+ 798 | | 799 +-----+ +------+ 800 | LMA1| | LMA2 | Combined 801 +-----+ +------+ Unicast/Multicast 802 \\ // || Anchor 803 \\ // || 804 \\ // || 805 \\ // || 806 +---+ +---+ +---+ 807 | 4 | | 5 | | 6 | 808 +---+ +---+ +---+ 809 \\ // || 810 \\ // || 811 \\ // || 812 \\ // || 813 +-----+ +-----+ 814 | MAG1| | MAG2| MLD Proxy 815 +-----+ +-----+ 816 | | | 817 +---+ +---+ +---+ 818 | 7 | | 8 | | 9 | 819 +---+ +---+ +---+ 820 | | | All MNs in same 821 | | | multicast group "G" 822 {MN1} {MN2} {MN3} 824 Figure 8. Packet Flow in a Combined Unicast/Multicast LMA 826 4 Direct routing 828 Direct routing uses native multicast infrastructure, allowing a MAG 829 to connect a multicast router directly. A MAG can act as a MLD proxy 830 or multicast router for redirecting multicast packets. The key idea 831 of direct routing is to provide optimal routing for local content. As 832 a consequence, it does not give the LMA processing burden for channel 833 management and data delivery of locally available content. Direct 834 routing is simple and easy to deploy. 836 When thinking on the MAG reception of the multicast flow being 837 forwarded to the attached MNs, two models for the MAG subscription to 838 the multicast flow (on behalf of the MNs) can be considered: 840 - Local subscription, which refers to the situation where the 841 multicast channel is forwarded to the MAG by a multicast router 842 within the PMIPv6 domain 844 - Remote subscription, which refers to the situation where the 845 multicast channel is forwarded to the MAG through the tunnel 846 interface from the home network 848 In the architecture described in [RFC6224], if MLD proxy is installed 849 on a MAG, all MAGs that participate in the multicast traffic 850 distribution in a PMIPv6 domain are considered to act as MLD proxies. 851 An important consequence derived from such characterization is that 852 every MLD proxy instance defined in the MAG has a unique upstream 853 interface, and thus, an MLD proxy instance cannot dynamically choose 854 among local or remote multicast subscription. For instance, one 855 possible scenario pushing for local source deployment, and 856 consequently local subscription, could be the one where there is an 857 extremely high number of multicast channels, all of them with active 858 subscriptions in all the MAGs along the PMIPv6 domain, resulting in 859 the MTMA replicating the totally of the multicast flows to all the 860 MAGs (leading to the known as "avalanche problem"). 862 Once a decision is taken (at configuration time) about what kind of 863 subscription, either local or remote, is applicable for a certain 864 instance regarding all the multicast channels for all the attached 865 MNs, this cannot be changed without resetting and reconfiguring the 866 whole MLD instance. 868 In order to have such kind of flexibility, the MAG needs to act as a 869 multicast router, that is, it must implement some multicast routing 870 protocol able to choose between local or remote subscription, for one 871 or all the subscribed multicast channels, by using some routing 872 criteria leveraged by the network routing information or by the 873 network management systems. The most commonly deployed multicast 874 routing protocol nowadays is PIM [RFC4601]. 876 So it is possible to distinguish among two situations depending on 877 the MAG functionality. The following sub-sections describe the 878 applying constraints. 880 4.1 MAG as MLD proxy 882 In case of the MAG only incorporates MLD proxy functionality, for 883 every one of the MLD proxy instances invoked in the MAG it is 884 necessary to define at configuration time the upstream interface from 885 where the multicast traffic will be received. This decision actually 886 requires to define whether the multicast subscription by an MLD proxy 887 instance for all the multicast channels will be local (if the 888 upstream interface points to a multicast router internal to the 889 PMIPv6 domain) or remote (in case of the upstream interface is the 890 bi-directional tunnel towards the LMA, for the architecture in 891 [RFC6224], or the MTMA, for the multicast listener optimization 892 described in this document). 894 4.1.1 Local subscription when the MAG implements MLD proxy functionality 896 If the MAG has MLD proxy functionality only, once this MLD proxy 897 instance is configured to obtain the multicast traffic locally, the 898 system behavior when operating with local subscription remains 899 static. 901 4.1.1.1 Local subscription architecture 903 Figure 9 shows the proposed local routing architecture using native 904 multicasting infrastructure [I-D.deng-multimob-pmip6-requirement]. To 905 forward IGMP/MLD signaling and multicast packets, a MLD proxy 906 function defined in [RFC4605], SHOULD be placed on a MAG. This 907 solution is much simpler than the base solution and easy to deploy 908 because multicasting functions are totally separated from mobility 909 anchor by using a native multicasting infrastructure. 911 Multicast Tree 912 : 913 : || - PMIPv6 Tunnel 914 +----------+ +----------+ | - Multicast Data Path 915 | LMA | | MR | 916 +----------+ +----------+ 917 ||\\ /| 918 || \\ / | 919 || \\ / | 920 || \\ / | 921 || \\/ | 922 || / \\ | 923 || / \\ | 924 || / \\ | 925 +----------+ +----------+ 926 | P-MAG | | N-MAG | 927 |(M-Proxy) | |(M-Proxy) | 928 +----------+ +----------+ 929 : : 930 +------+ +------+ 931 | MN | -----> | MN | 932 +------+ +------+ 934 Figure 9. Direct routing solution for PMIPv6 Multicasting 936 4.1.1.2 Handover procedure for local routing 938 Figure 10 shows the handover operation in local routing architecture. 939 When an MN hands off to the next MAG (N-MAG) from the previous MAG 940 (P-MAG), the N-MAG detects the newly arrived MN and transmits an MLD 941 query message to the MN. After receiving the MLD query message, the 942 MN sends an MLD report message that includes the multicast group 943 information. The N-MAG then sends an aggregated MLD report message to 944 the MR. When the N-MAG receives the multicast packets from the MR, it 945 then simply forwards them without tunnel encapsulation. The N-MAG 946 updates the MN's location information to the LMA by exchanging 947 PBU/PBA signaling messages. 949 MN P-MAG N-MAG LMA MR Tree 950 | | | | | | 951 | | | | | | 952 |<----------|<-- Multicast Data--------------|<-------| 953 | | . | | | | 954 | | . | | | | 955 | | . | | | | 956 Link->| Handover | | | | 957 Disconnected Detection | | | | 958 | | | | | | 959 | | | | | | 960 | | MN Attachment | | | 961 | | | | | | 962 | | | | | | 963 |------ Rtr. Sol. ----->| | | | 964 | | | | | | 965 |<----- MLD Query ------| | | | 966 | | | | | | 967 |------ MLD Report ---->| | | | 968 | | | Aggregated | | 969 | | |--- MLD Report ---->| | 970 | | | | | | 971 | | | | | | 972 |<----------------------|<-- Multicast Data--|<-------| 973 | | | | | | 974 | | | | | | 975 | | | Proxy | | | 976 | | |--Binding->| | | 977 | | | Update | | | 978 | | | | | | 979 | | | Proxy | | | 980 | | |<-Binding--| | | 981 | | | Ack. | | | 982 | | | | | | 984 Figure 10. Handover procedure in direct routing architecture 986 4.1.2 Remote subscription when the MAG implements MLD proxy 987 functionality 989 If the MAG has only MLD proxy functionality, the system behavior when 990 operating with remote subscription is as described in chapter 3. Once 991 the MLD proxy instance is configured to obtain the multicast traffic 992 remotely, this remains static. 994 4.2 MAG as multicast router 996 If the MAG behaves as a multicast router, the MAG then implements a 997 multicast routing protocol. This allows the MAG to make decisions 998 about from where to receive the traffic of any multicast channel, 999 based in routing information and/or network management criteria. The 1000 selected incoming interface for receiving multicast traffic will be 1001 then the one matching such criteria, and it could drive to either a 1002 local or remote subscription. Some situations are introduced in the 1003 next section. 1005 4.2.1 Local subscription when the MAG implements a multicast routing 1006 protocol 1008 If the MAG is a multicast router, the system behavior when operating 1009 with local subscription is as before, but extending the role of the 1010 MAG to be a multicast router, and running a multicast routing 1011 protocol among the MAG and local multicast router serving the 1012 multicast traffic. Once the MAG decides to obtain the multicast 1013 traffic locally based in routing information and/or network 1014 management criteria, this can be dynamically changed if such criteria 1015 change. 1017 4.2.2 Remote subscription when the MAG implements a multicast routing 1018 protocol 1020 If the MAG is a multicast router, the system behavior when operating 1021 with remote subscription is as described in chapter 3, considering 1022 that a multicast routing protocol is running among the MAG and the 1023 MTMA on the tunnel interface. Once the MAG decides to obtain the 1024 multicast traffic remotely based in routing information and/or 1025 network management criteria, this can be dynamically changed if such 1026 criteria change. 1028 5 Dynamic selection of local versus remote multicast subscription 1030 As mentioned above, the MAG as multicast router provides some 1031 flexibility for choosing local versus remote multicast subscription. 1032 Considering PIM as the multicast routing protocol running on the MAG, 1033 it is possible to find out two situations where such dynamic 1034 selection can occur, according to the PIM flavor on place. For all 1035 the scenarios below we consider a certain multicast flow being 1036 injected by two different sources, one local to the PMIPv6 domain and 1037 one remote through the home network, by using an MTMA. 1039 5.1 Any source multicast scenario 1041 This situation applies for both PIM-SM and BIDIR PIM variants. In 1042 this case, once the MAG receives the MLD report from the MN 1043 requesting the multicast channel in the form (*,G), the MAG could 1044 decide what multicast flow subscribes to (the local or the remote 1045 one). 1047 The subscription can be statically pre-configured or dynamically 1048 configured based on some rule. For instance, static configuration can 1049 be made per MN (user), such as "multicast traffic from user X should 1050 always go through the home (i.e., via the tunnel with the MTMA/LMA- 1051 as-per-RFC6224), while traffic from user Y should go via local 1052 subscription". Also, configuration profiles can also be more complex 1053 and include considerations on types of traffic or IP flows, such as 1054 "traffic of type A from user X should always go through the home, 1055 traffic of type B from user X should be subscribed locally" using 1056 routing information and/or network management criteria. Similarly, 1057 routing information can be received dynamically, for example, at 1058 user's registration time PBU/PBA signaling can be used to carry the 1059 profile information similar to what is described in [I-D.gundavelli- 1060 netext-pmipv6-sipto-option]. Also, routing information can be 1061 exchanged dynamically when the multicast group subscription is made. 1063 When focusing on PIM-SM, another scenario is possible. PIM-SM allows 1064 for switching from a multicast shared-tree to a source-specific tree 1065 to optimize the path for traffic delivery. The location of the 1066 rendezvous point and the multicast source can be either in the PMIPv6 1067 domain or the home network, so the optimization could be from local 1068 subscription to remote subscription or vice versa. The possibility of 1069 switching to a source-based tree, and the time for doing is 1070 implementation-dependent, and it could be triggered immediately 1071 (after reception of the first multicast packet) or last to some time, 1072 or even not switching never. 1074 5.2 Source specific multicast scenario 1076 This situation applies for PIM-SSM. Then, in a source-specific 1077 multicast scenario [RFC4607], the MAG would send the PIM request to 1078 the corresponding interface based on the multicast source address 1079 indicated on the (S,G) subscription requested by the MN in the MLD 1080 Report, using the routing information. 1082 6 Security Considerations 1084 This draft discusses the operations of existing protocols without 1085 modifications. It does not introduce new security threats beyond the 1086 current security considerations of PMIPv6 [RFC5213], MLD [RFC3810], 1087 IGMP [RFC3376] and IGMP/MLD Proxying [RFC4605]. 1089 7 IANA Considerations 1091 This document makes no request of IANA. 1093 8 Contributors 1095 The following people have considerably contributed to this draft: 1097 Akbar Rahman 1098 InterDigital Communications, LLC 1099 Email: Akbar.Rahman@InterDigital.com 1101 Ignacio Soto 1102 Universidad Politecnica de Madrid 1103 Email: isoto@dit.upm.es 1105 9 References 1107 9.1 Normative References 1109 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1110 Requirement Levels", BCP 14, RFC 2119, March 1997. 1112 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, 1113 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 1114 2008. 1116 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1117 in Ipv6", RFC 3775, June 2004. 1119 [RFC3810] Vida, R. and L.Costa, "Multicast Listener Discovery 1120 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1122 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1123 Thyagarajan, "Internet Group Management Protocol, Version 1124 3", RFC 3376, October 2002. 1126 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1127 "Internet Group Management Protocol (IGMP)/ Multicast 1128 Listener Discovery (MLD)-Based Multicast Forwarding 1129 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1131 [RFC5847] Devarapalli, V., Koodli, R., Lim, H., Kant, N., Krishnan, 1132 S., Laganier, J., "Heartbeat Mechanism for Proxy Mobile 1133 IPv6", RFC 5847, June 2010. 1135 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1136 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1137 Protocol Specification (Revised)", RFC 4601, August 2006. 1139 [RFC4607] Holbrook, H., and B. Cain, "Source-Specific Multicast for 1140 IP", RFC 4607, August 2006. 1142 9.2 Informative References 1144 [RFC6224] Schmidt, T.C., Waehlisch, M., and S.Krishnan, "Base 1145 Deployment for Multicast Listener Support in PMIPv6 1146 Domains", RFC 6224, April 2011. 1148 [ERCIM] L.M. Contreras, C.J. Bernardos, I. Soto, "On the 1149 efficiency of a dedicated LMA for multicast traffic 1150 distribution in PMIPv6 domains", 5th ERCIM Workshop in 1151 eMobility, Vilanova i la Geltru, Spain, June 2011. 1153 [I-D.deng-multimob-pmip6-requirement] H. Deng, T. Schmidt, P. Seite, 1154 and P. Yang, "Multicast Support Requirements for Proxy 1155 Mobile IPv6", draft-deng-multimob-pmip6-requirement- 1156 02.txt (work in progress), July 2009. 1158 [I-D.gundavelli-netext-pmipv6-sipto-option] S. Gundavelli, X. Zhou, 1159 J. Korhonen, G. Feige, R. Koodli, "IP Traffic Offload 1160 Selector Option for Proxy Mobile IPv6", draft-gundavelli- 1161 netext-pmipv6-sipto-option-01.txt (work in progress), 1162 July 2011. 1164 Author's Addresses 1166 Juan Carlos Zuniga 1167 InterDigital Communications, LLC 1168 EMail: JuanCarlos.Zuniga@InterDigital.com 1170 Luis M. Contreras 1171 Telefonica I+D 1172 EMail: lmcm@tid.es 1174 Carlos J. Bernardos 1175 Universidad Carlos III de Madrid 1176 EMail: cjbc@it.uc3m.es 1178 Seil Jeon 1179 Soongsil University 1180 Email: sijeon@dcn.ssu.ac.kr 1182 Younghan Kim 1183 Soongsil University 1184 Email: yhkim@dcn.ssu.ac.kr