idnits 2.17.1 draft-ietf-multimob-pmipv6-source-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 9, 2012) is 4490 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC2710' is defined on line 605, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 646, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T C. Schmidt, Ed. 3 Internet-Draft HAW Hamburg 4 Intended status: Standards Track S. Gao 5 Expires: July 12, 2012 H. Zhang 6 Beijing Jiaotong University 7 M. Waehlisch 8 link-lab & FU Berlin 9 January 9, 2012 11 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains 12 draft-ietf-multimob-pmipv6-source-00 14 Abstract 16 Multicast communication can be enabled in Proxy Mobile IPv6 domains 17 via the Local Mobility Anchors by deploying MLD Proxy functions at 18 Mobile Access Gateways, via a direct traffic distribution within an 19 ISP's access network, or by selective route optimization schemes. 20 This document describes the support of mobile multicast senders in 21 Proxy Mobile IPv6 domains for all three scenarios. Mobile sources 22 always remain agnostic of multicast mobility operations. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on July 12, 2012. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 4 66 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.2. Base Solution for Source Mobility: Details . . . . . . . . 8 68 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 8 69 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 8 70 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8 71 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 9 72 3.2.5. Efficiency of the Distribution System . . . . . . . . 10 73 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 10 74 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 11 76 4.2.1. PIM-SM Considerations . . . . . . . . . . . . . . . . 12 77 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 12 78 4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 4.4. BIDIR PIM . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5. Extended Source Mobility Schemes in PMIPv6 . . . . . . . . . . 13 81 5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 13 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 84 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 85 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 87 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 88 Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 16 89 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 95 [RFC6275] by network-based management functions that enable IP 96 mobility for a host without requiring its participation in any 97 mobility-related signaling. Additional network entities called the 98 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 99 responsible for managing IP mobility on behalf of the mobile node 100 (MN). An MN connected to a PMIPv6 domain, which only operates 101 according to the base specifications of [RFC5213], cannot participate 102 in multicast communication, as MAGs will discard group packets. 104 Multicast support for mobile listeners can be enabled within a PMIPv6 105 domain by deploying MLD Proxy functions at Mobile Access Gateways, 106 and multicast routing functions at Local Mobility Anchors [RFC6224]. 107 This base deployment option is the simplest way to PMIPv6 multicast 108 extensions in the sense that it follows the common PMIPv6 traffic 109 model and neither requires new protocol operations nor additional 110 infrastructure entities. Standard software functions need to be 111 activated on PMIPv6 entities, only, at the price of possibly non- 112 optimal multicast routing. 114 Alternate solutions leverage performance optimization by providing 115 multicast routing at the access gateways directly, or by selective 116 route optimization schemes. Such approaches (partially) follow the 117 business model of providing multicast data services in parallel to 118 PMIPv6 unicast routing. 120 Multicast listener support satisfies the needs of receptive use cases 121 such as IPTV or sever-centric gaming on mobiles. However, current 122 trends in the Internet enfold towards user-centric, highly 123 interactive group applications like user generated streaming, 124 conferencing, collective mobile sensing, etc. Many of these popular 125 applications create group content at end systems and can largely 126 profit from a direct data transmission to a multicast-enabled 127 network. 129 This document describes the support of mobile multicast senders in 130 Proxy Mobile IPv6 domains subsequently for the base deployment 131 scenario [RFC6224], for direct traffic distribution within an ISP's 132 access network, as well as for selective route optimization schemes. 133 The contribution of this work reflects the source mobility problem as 134 discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic 135 of multicast mobility operations. 137 2. Terminology 139 This document uses the terminology as defined for the mobility 140 protocols [RFC6275], [RFC5213] and [RFC5844], as well as the 141 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 143 3. Base Solution for Source Mobility and PMIPv6 Routing 145 3.1. Overview 147 The reference scenario for multicast deployment in Proxy Mobile IPv6 148 domains is illustrated in Figure 1. MAGs play the role of first-hop 149 access routers that serve multiple MNs on the downstream while 150 running an MLD/IGMP proxy instance for every LMA upstream tunnel. 152 +-------------+ 153 | Multicast | 154 | Listeners | 155 +-------------+ 156 | 157 *** *** *** *** 158 * ** ** ** * 159 * * 160 * Fixed Internet * 161 * * 162 * ** ** ** * 163 *** *** *** *** 164 / \ 165 +----+ +----+ 166 |LMA1| |LMA2| Multicast Anchor 167 +----+ +----+ 168 LMAA1 | | LMAA2 169 | | 170 \\ //\\ 171 \\ // \\ 172 \\ // \\ Unicast Tunnel 173 \\ // \\ 174 \\ // \\ 175 \\ // \\ 176 Proxy-CoA1 || || Proxy-CoA2 177 +----+ +----+ 178 |MAG1| |MAG2| MLD Proxy 179 +----+ +----+ 180 | | | 181 MN-HNP1 | | MN-HNP2 | MN-HNP3 182 | | | 183 MN1 MN2 MN3 185 Multicast Sender + Listener(s) 187 Figure 1: Reference Network for Multicast Deployment in PMIPv6 with 188 Source Mobility 190 An MN in a PMIPv6 domain will decide on multicast data transmission 191 completely independent of its current mobility conditions. It will 192 send packets as initiated by applications, using its source address 193 with Home Network Prefix (HNP) and a multicast destination address 194 chosen by application needs. Multicast packets will arrive at the 195 currently active MAG via one of its downstream local (wireless) 196 links. A multicast unaware MAG would simply discard these packets in 197 the absence of a multicast routing information base (MRIB). 199 An MN can successfully distribute multicast data in PMIPv6, if MLD 200 proxy functions are deployed at the MAG as described in [RFC6224]. 201 In this set-up, the MLD proxy instance serving a mobile multicast 202 source has configured its upstream interface at the tunnel towards 203 MN's corresponding LMA. For each LMA, there will be a separate 204 instance of an MLD proxy. 206 According to the specifications given in [RFC4605], multicast data 207 arriving from a downstream interface of an MLD proxy will be 208 forwarded to the upstream interface and to all but the incoming 209 downstream interfaces that have appropriate forwarding states for 210 this group. Thus multicast streams originating from an MN will 211 arrive at the corresponding LMA and directly at all mobile receivers 212 co-located at the same MAG and MLD Proxy instance. Serving as the 213 designated multicast router or an additional MLD proxy, the LMA 214 forwards data to the fixed Internet, whenever forwarding states are 215 maintained by multicast routing. If the LMA is acting as another MLD 216 proxy, it will forward the multicast data to its upstream interface, 217 and to downstream interfaces with matching subscriptions, 218 accordingly. 220 In case of a handover, the MN (unaware of IP mobility) can continue 221 to send multicast packets as soon as network connectivity is 222 reconfigured. At this time, the MAG has determined the corresponding 223 LMA, and IPv6 unicast address configuration (including PMIPv6 224 bindings) has been performed . Still multicast packets arriving at 225 the MAG are discarded (if not buffered) until the MAG has completed 226 the following steps. 228 1. The MAG has determined that the MN is admissible to multicast 229 services. 231 2. The MAG has added the new downstream link to the MLD proxy 232 instance with up-link to the corresponding LMA. 234 As soon as the MN's uplink is associated with the corresponding MLD 235 proxy instance, multicast packets are forwarded again to the LMA and 236 eventually to receivers within the PMIP domain (see the call flow in 237 Figure 2). In this way, multicast source mobility is transparently 238 enabled in PMIPv6 domains that deploy the base scenario for 239 multicast. 241 MN1 MAG1 MN2 MAG2 LMA 242 | | | | | 243 | | Mcast Data | | | 244 | |<---------------+ | | 245 | | Mcast Data | | | 246 | Join(G) +================================================>| 247 +--------------> | | | | 248 | Mcast Data | | | | 249 |<---------------+ | | | 250 | | | | | 251 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 252 | | | | | 253 | | |--- Rtr Sol -->| | 254 | | |<-- Rtr Adv ---| | 255 | | | | | 256 | | | < MLD Proxy Configuration > | 257 | | | | | 258 | | | MLD Query | | 259 | | |<--------------+ | 260 | | | Mcast Data | | 261 | | +-------------->| | 262 | | | | Mcast Data | 263 | | | +===============>| 264 | | | | | 265 | | Mcast Data | | | 266 | |<================================================+ 267 | Mcast Data | | | | 268 |<---------------+ | | | 269 | | | | | 271 Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP 273 These multicast deployment considerations likewise apply for mobile 274 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 275 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 276 IPv4 multicast is handled by an IGMP proxy function at the MAG in an 277 analogous way. 279 Following these deployment steps, multicast traffic distribution 280 transparently inter-operates with PMIPv6. It is worth noting that an 281 MN - while being attached to the same MAG as the mobile source, but 282 associated with a different LMA - cannot receive multicast traffic on 283 a shortest path. Instead, multicast streams flow up to the LMA of 284 the mobile source, are transferred to the LMA of the mobile listener 285 and tunneled downwards to the MAG again (see Appendix A for further 286 considerations). 288 3.2. Base Solution for Source Mobility: Details 290 Incorporating multicast source mobility in PMIPv6 requires to deploy 291 general multicast functions at PMIPv6 routers and to define their 292 interaction with the PMIPv6 protocol in the following way. 294 3.2.1. Operations of the Mobile Node 296 A Mobile Node willing to send multicast data will proceed as if 297 attached to the fixed Internet. No specific mobility or other 298 multicast related functionalities are required at the MN. 300 3.2.2. Operations of the Mobile Access Gateway 302 A Mobile Access Gateway is required to have MLD proxy instances 303 deployed, one for each tunnel to an LMA, which serves as its unique 304 upstream link (cf., [RFC6224]). On the arrival of an MN, the MAG 305 decides on the mapping of downstream links to a proxy instance and 306 the upstream link to the LMA based on the regular Binding Update List 307 as maintained by PMIPv6 standard operations. When multicast data is 308 received from the MN, the MAG MUST identify the corresponding proxy 309 instance from the incoming interface and forwards multicast data 310 upstream according to [RFC4605]. 312 The MAG MAY apply special admission control to enable multicast data 313 transition from an MN. It is advisable to take special care that MLD 314 proxy implementations do not redistribute multicast data to 315 downstream interfaces without appropriate subscriptions in place. 317 3.2.3. Operations of the Local Mobility Anchor 319 For any MN, the Local Mobility Anchor acts as the persistent Home 320 Agent and at the same time as the default multicast upstream for the 321 corresponding MAG. It will manage and maintain a multicast 322 forwarding information base for all group traffic arriving from its 323 mobile sources. It SHOULD participate in multicast routing functions 324 that enable traffic redistribution to all adjacent LMAs within the 325 PMIPv6 domain and thereby ensure a continuous receptivity while the 326 source is in motion. 328 3.2.3.1. Local Mobility Anchors Operating PIM 330 Local Mobility Anchors that operate the PIM-SM routing protocol 331 [RFC4601] will require sources to be directly connected for sending 332 PIM registers to the RP. This does not hold in a PMIPv6 domain, as 333 MAGs are routers intermediate to MN and the LMA. In this sense, MNs 334 are multicast sources external to the PIM-SM domain. 336 To mitigate this incompatibility common to all subsidiary MLD proxy 337 domains, the LMA should act as a PIM Border Router and activate the 338 Border-bit. In this case, the DirectlyConnected(S) is treated as 339 being TRUE for mobile sources and the PIM-SM forwarding rule "iif == 340 RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 341 interface from MAG to LMA is considered as not part of the PIM-SM 342 component of the LMA (see A.1 of [RFC4601] ). 344 Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with 345 respect to source location and does not require a special 346 configuration. 348 3.2.4. IPv4 Support 350 An MN in a PMIPv6 domain may use an IPv4 address transparently for 351 communication as specified in [RFC5844]. For this purpose, an LMA 352 can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can 353 provide IPv4 support in its access network. Correspondingly, 354 multicast membership management will be performed by the MN using 355 IGMP. For multicast support on the network side, an IGMP proxy 356 function needs to be deployed at MAGs in exactly the same way as for 357 IPv6. [RFC4605] defines IGMP proxy behaviour in full agreement with 358 IPv6/MLD. Thus IPv4 support can be transparently provided following 359 the obvious deployment analogy. 361 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 362 SHOULD choose multicast signaling according to address configurations 363 on the link, but MAY submit IGMP and MLD queries in parallel, if 364 needed. It should further be noted that the infrastructure cannot 365 identify two data streams as identical when distributed via an IPv4 366 and IPv6 multicast group. Thus duplicate data may be forwarded on a 367 heterogeneous network layer. 369 A particular note is worth giving the scenario of [RFC5845] in which 370 overlapping private address spaces of different operators can be 371 hosted in a PMIP domain by using GRE encapsulation with key 372 identification. This scenario implies that unicast communication in 373 the MAG-LMA tunnel can be individually identified per MN by the GRE 374 keys. This scenario still does not impose any special treatment of 375 multicast communication for the following reasons. 377 Multicast streams from and to MNs arrive at a MAG on point-to-point 378 links (identical to unicast). Multicast data transmission from the 379 MAG to the corresponding LMA is link-local between the routers and 380 routing/forwarding remains independent of any individual MN. So the 381 MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain 382 GRE encapsulation in multicast communication (including MLD queries 383 and reports). Multicast traffic sent upstream and downstream of MAG- 384 to-LMA tunnels proceeds as router-to-router forwarding according to 385 the multicast routing information base (MRIB) of the MAG or LMA and 386 independent of MN's unicast addresses, while the MAG proxy instance 387 re-distributes multicast data down the point-to-point links 388 (interfaces) according to its own MRIB, independent of MN's IP 389 addresses. 391 3.2.5. Efficiency of the Distribution System 393 In the following efficiency-related issues are enumerated. 395 Multicast reception at LMA In the current deployment scenario, the 396 LMA will receive all multicast traffic originating from its 397 associated MNs. There is no mechanism to suppress upstream 398 forwarding in the absence of receivers. 400 MNs on the same MAG using different LMAs For a mobile receiver and a 401 source that use different LMAs, the traffic has to go up to one 402 LMA, cross over to the other LMA, and then be tunneled back to the 403 same MAG, causing redundant flows in the access network and at the 404 MAG. 406 4. Direct Multicast Routing 408 There are deployment scenarios, where multicast services are 409 available throughout the access network independent of the PMIPv6 410 routing system [I-D.zuniga-multimob-pmipv6-ropt]. In these cases, 411 the visited networks grant a local content distribution service (in 412 contrast to LMA-based home subscription) with locally optimized 413 traffic flows. It is also possible to deploy a mixed service model 414 of local and LMA-based subscriptions, provided a unique way of 415 service selection is implemented. For example, access routers (MAGs) 416 could decide on service access based on the multicast address G or 417 the SSM channel (S,G) under request (see Section 5 for a further 418 discussion). 420 4.1. Overview 422 Direct multicast access can be supported by 424 o native multicast routing provided by one multicast router that is 425 neighboring MLD proxies deployed at MAGs within a flat access 426 network, or via tunnel uplinks, 428 o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM 429 [RFC5015] deployed at the MAGs. 431 *** *** *** *** 432 * ** ** ** * 433 * * 434 * Multicast * 435 +----+ * Infrastructure * +----+ 436 |LMA | * ** ** ** * |LMA | 437 +----+ *** *** *** *** +----+ 438 | // \\ | 439 \\ // \\ PMIP (unicast) | 440 PMIP \\ // \\ // \\ ** *** *** ** // 441 (unicast) \\ // \\ // \\ * ** ** ** // 442 \\ // \\ // \\* Multicast *// 443 || || || || * || Routing || * 444 +----+ +----+ * +----+ +----+ * 445 MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| * 446 +----+ +----+ *+----+ ** ** +----+* 447 | | | | |*** *** ***| 448 | | | | | | 449 MN1 MN2 MN3 MN1 MN2 MN3 451 (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG 453 Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast 454 Access and (b) Dynamic Multicast Routing at MAGs 456 Figure 3 displays the corresponding deployment scenarios, which 457 separate multicast from PMIPv6 unicast routing. It is assumed 458 throughout these scenarios that all MAGs (MLD proxies) are linked to 459 a single multicast routing domain. 461 Multicast traffic distribution can be simplified in these scenarios. 462 A single proxy instance at MAGs with up-link into the multicast 463 domain will serve as a first hop multicast gateway and avoid traffic 464 duplication or detour routing. Multicast routing functions at MAGs 465 will seamlessly embed access gateways within a multicast cloud. 466 However, mobility of the multicast source in this scenario will 467 require some multicast routing protocols to rebuild distribution 468 trees. This can cause significant service disruptions or delays (see 469 [RFC5757] for further aspects). Deployment details are specific to 470 the multicast routing protocol in use, in the following described for 471 common protocols. 473 4.2. MLD Proxies at MAGs 475 In a PMIPv6 domain, single MLD proxy instances can be deployed at 476 each MAG to enable multicast service at the access (see Figure 3 (a) 477 ). To avoid service disruptions on handovers, the uplinks of all 478 proxies SHOULD be adjacent to the same next-hop multicast router. 480 This can either be achieved by arranging proxies within a flat access 481 network, or by upstream tunnels that terminate at a common multicast 482 router. 484 Multicast data submitted by a mobile source will reach the MLD proxy 485 at the MAG that subsequently forwards flows to the upstream and all 486 downstream interfaces with appropriate subscriptions. Traversing the 487 upstream will lead traffic into the multicast infrastructure (e.g., 488 to a PIM Designated Router) which will route packets to all local 489 MAGs that have joined the group, as well as further upstream 490 according to protocol procedures and forwarding states. 492 On handover, a mobile source will reattach at a new MAG and can 493 continue to send multicast packets as soon as PMIPv6 unicast 494 configurations have completed. Like at the previous MAG, the new MLD 495 proxy will forward data upstream and downstream to subscribers. 496 Listeners local to the previous MAG will continue to receive group 497 traffic via the local multicast distribution infrastructure following 498 aggregated listener reports of the previous proxy. In general, the 499 mobile source remains unchanged when seen from the wider multicast 500 infrastructure. 502 4.2.1. PIM-SM Considerations 504 A mobile source that transmits data via an MLD proxy will not be 505 directly connected to a PIM Designated Router as discussed in 506 Section 3.2.3.1. Countermeasures apply correspondingly. 508 A PIM Designated Router that is connected to MLD proxies via 509 individual IP-tunnel interfaces will experience invalid PIM source 510 states on handover. This problem can be mitigated by aggregating 511 proxies on a lower layer. 513 4.2.2. SSM Considerations 515 Source-specific subscriptions invalidate with routes, whenever the 516 source moves from or to the MAG/proxy of a subscriber. Multicast 517 forwarding states will rebuild with unicast route changes. However, 518 this may lead to noticeable service disruptions for locally 519 subscribed nodes. 521 4.3. PIM-SM 523 TODO 525 4.4. BIDIR PIM 527 TODO 529 5. Extended Source Mobility Schemes in PMIPv6 531 In this section, specific optimization approaches to multicast source 532 mobility are introduced. 534 5.1. Multiple Upstream Interface Proxy 536 Although multicast communication can be enabled in PMIPv6 domains by 537 deploying MLD Proxy functions at MAG, some disadvantages still exist. 538 Firstly, for a proxy device performing IGMP/MLD-based forwarding has 539 a single upstream interface and one or more downstream interfaces as 540 described in RFC4605, there should be many MLD Proxy functions 541 deployed at one MAG, which is complicated and then is difficult for 542 implementation and management. And then when the multicast packets 543 arrive at the MAG running multiple parallel MLD proxy functions, 544 there may be confusions for the data if there is no extra processing 545 or filtering scheme at the MAG. In addition, the route optimization 546 issue is still up in the air, that is, for a mobile receiver and a 547 source on the same MAG using different LMAs, the traffic has to go up 548 to one LMA, cross over to the other LMA, and then be tunneled back to 549 the same MAG, causing redundant flows in the access network and at 550 the MAG. Therefore, the MLD Proxy function should be extended to 551 accommodate the PMIPv6 protocol. As same as described in [RFC6224] 552 and this document (s. abobe), the MLD proxy functions are deployed at 553 the MAG, while only one MLD Proxy function is required to run at the 554 MAG and multiple upstream interfaces can be set for the MLD Proxy 555 instance, which is called Multi-Upstream Interfaces MLD Proxy 556 (MUIMP). 558 .... TODO details. 560 6. IANA Considerations 562 TODO. 564 Note to RFC Editor: this section may be removed on publication as an 565 RFC. 567 7. Security Considerations 569 TODO 570 Consequently, no new threats are introduced by this document in 571 addition to those identified as security concerns of [RFC3810], 572 [RFC4605], [RFC5213], and [RFC5844]. 574 However, particular attention should be paid to implications of 575 combining multicast and mobility management at network entities. As 576 this specification allows mobile nodes to initiate the creation of 577 multicast forwarding states at MAGs and LMAs while changing 578 attachments, threats of resource exhaustion at PMIP routers and 579 access networks arrive from rapid state changes, as well as from high 580 volume data streams routed into access networks of limited 581 capacities. In addition to proper authorization checks of MNs, rate 582 controls at replicators MAY be required to protect the agents and the 583 downstream networks. In particular, MLD proxy implementations at 584 MAGs SHOULD carefully procure for automatic multicast state 585 extinction on the departure of MNs, as mobile multicast listeners in 586 the PMIPv6 domain will not actively terminate group membership prior 587 to departure. 589 8. Acknowledgements 591 The authors would like to thank (in alphabetical order) Muhamma Omer 592 Farooq, Aaron Feng, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu 593 Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Wu, Zhi-Wei Yan for 594 advice, help and reviews of the document. Funding by the German 595 Federal Ministry of Education and Research within the G-LAB 596 Initiative (project HAMcast) is gratefully acknowledged. 598 9. References 600 9.1. Normative References 602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 603 Requirement Levels", BCP 14, RFC 2119, March 1997. 605 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 606 Listener Discovery (MLD) for IPv6", RFC 2710, 607 October 1999. 609 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 610 Thyagarajan, "Internet Group Management Protocol, Version 611 3", RFC 3376, October 2002. 613 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 614 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 616 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 617 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 618 Protocol Specification (Revised)", RFC 4601, August 2006. 620 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 621 "Internet Group Management Protocol (IGMP) / Multicast 622 Listener Discovery (MLD)-Based Multicast Forwarding 623 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 625 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 626 "Bidirectional Protocol Independent Multicast (BIDIR- 627 PIM)", RFC 5015, October 2007. 629 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 630 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 632 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 633 Mobile IPv6", RFC 5844, May 2010. 635 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 636 in IPv6", RFC 6275, July 2011. 638 9.2. Informative References 640 [I-D.zuniga-multimob-pmipv6-ropt] 641 Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. 642 Kim, "Multicast Mobility Routing Optimizations for Proxy 643 Mobile IPv6", draft-zuniga-multimob-pmipv6-ropt-01 (work 644 in progress), October 2011. 646 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 647 2", RFC 2236, November 1997. 649 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 650 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 651 and Brief Survey", RFC 5757, February 2010. 653 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 654 "Generic Routing Encapsulation (GRE) Key Option for Proxy 655 Mobile IPv6", RFC 5845, June 2010. 657 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 658 Deployment for Multicast Listener Support in Proxy Mobile 659 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 661 Appendix A. Evaluation of Traffic Flows 663 TODO 665 Appendix B. Change Log 667 The following changes have been made from version 668 draft-ietf-multimob-pmipv6-source-00: 670 Authors' Addresses 672 Thomas C. Schmidt 673 HAW Hamburg 674 Berliner Tor 7 675 Hamburg 20099 676 Germany 678 Email: schmidt@informatik.haw-hamburg.de 679 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 681 Shuai Gao 682 Beijing Jiaotong University 683 Beijing, 684 China 686 Phone: 687 Fax: 688 Email: shgao@bjtu.edu.cn 689 URI: 691 Hong-Ke Zhang 692 Beijing Jiaotong University 693 Beijing, 694 China 696 Phone: 697 Fax: 698 Email: hkzhang@bjtu.edu.cn 699 URI: 701 Matthias Waehlisch 702 link-lab & FU Berlin 703 Hoenower Str. 35 704 Berlin 10318 705 Germany 707 Email: mw@link-lab.net