idnits 2.17.1 draft-ietf-multimob-pmipv6-source-07.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 5, 2014) is 3763 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: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'RFC2236' is defined on line 1047, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-10) exists of draft-ietf-multimob-fmipv6-pfmipv6-multicast-01 == Outdated reference: A later version (-07) exists of draft-ietf-multimob-handover-optimization-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T. Schmidt, Ed. 3 Internet-Draft HAW Hamburg 4 Intended status: Experimental S. Gao 5 Expires: July 9, 2014 H. Zhang 6 Beijing Jiaotong University 7 M. Waehlisch 8 link-lab & FU Berlin 9 January 5, 2014 11 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains 12 draft-ietf-multimob-pmipv6-source-07 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 a base solution and an experimental protocol 21 to support of mobile multicast senders in Proxy Mobile IPv6 domains 22 for all three scenarios. Protocol optimizations for synchronizing 23 PMIPv6 with PIM, as well as a peering function for MLD Proxies are 24 defined. Mobile sources always remain agnostic of multicast mobility 25 operations. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on July 9, 2014. 50 Copyright Notice 52 Copyright (c) 2014 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . 4 70 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Base Solution for Source Mobility: Details . . . . . . . 8 72 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 8 73 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 8 74 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 8 75 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 9 76 3.2.5. Efficiency of the Distribution System . . . . . . . . 10 77 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 11 78 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 79 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12 80 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13 81 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . 13 82 4.3. PIM-SM at MAGs . . . . . . . . . . . . . . . . . . . . . 13 83 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 13 84 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 14 85 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 15 86 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 15 87 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 16 88 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 16 89 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 90 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 17 91 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17 92 5. MLD Proxy Peering Function for Optimized Source Mobility in 93 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 94 5.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 18 95 5.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 18 96 5.3. Operations in Support of Multicast Senders . . . . . . . 19 97 5.4. Operations in Support of Multicast Listeners . . . . . . 19 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 103 9.1. Normative References . . . . . . . . . . . . . . . . . . 22 104 9.2. Informative References . . . . . . . . . . . . . . . . . 23 105 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 23 106 A.1. Operations for Local Multicast Sources . . . . . . . . . 24 107 A.2. Operations for Local Multicast Subscribers . . . . . . . 24 108 Appendix B. Implementation . . . . . . . . . . . . . . . . . . . 25 109 Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 112 1. Introduction 114 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 115 [RFC6275] by network-based management functions that enable IP 116 mobility for a host without requiring its participation in any 117 mobility-related signaling. Additional network entities called the 118 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 119 responsible for managing IP mobility on behalf of the mobile node 120 (MN). An MN connected to a PMIPv6 domain, which only operates 121 according to the base specifications of [RFC5213], cannot participate 122 in multicast communication, as MAGs will discard group packets. 124 Multicast support for mobile listeners can be enabled within a PMIPv6 125 domain by deploying MLD proxy functions at Mobile Access Gateways, 126 and multicast routing functions at Local Mobility Anchors [RFC6224]. 127 This base deployment option is the simplest way to PMIPv6 multicast 128 extensions in the sense that it follows the common PMIPv6 traffic 129 model and neither requires new protocol operations nor additional 130 infrastructure entities. Standard software functions need to be 131 activated on PMIPv6 entities, only, at the price of possibly non- 132 optimal multicast routing. 134 Alternate solutions leverage performance optimization by providing 135 multicast routing at the access gateways directly 136 [I-D.ietf-multimob-fmipv6-pfmipv6-multicast], or by selective route 137 optimization schemes [RFC7028]. Such approaches (partially) follow 138 the business model of providing multicast data services in parallel 139 to PMIPv6 unicast routing [I-D.ietf-multimob-handover-optimization]. 141 Multicast listener support satisfies the needs of receptive use cases 142 such as IPTV or server-centric gaming on mobiles. However, current 143 trends in the Internet develop towards user-centric, highly 144 interactive group applications like user generated streaming, 145 conferencing, collective mobile sensing, etc. Many of these popular 146 applications create group content at end systems and can largely 147 profit from a direct data transmission to a multicast-enabled 148 network. 150 This document describes the support of mobile multicast senders in 151 Proxy Mobile IPv6 domains subsequently for the base deployment 152 scenario [RFC6224], for direct traffic distribution within an ISP's 153 access network, as well as for selective route optimization schemes. 154 The contribution of this work reflects the source mobility problem as 155 discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic 156 of multicast mobility operations. 158 2. Terminology 160 This document uses the terminology as defined for the mobility 161 protocols [RFC6275], [RFC5213] and [RFC5844], as well as the 162 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 164 3. Base Solution for Source Mobility and PMIPv6 Routing 166 3.1. Overview 168 The reference scenario for multicast deployment in Proxy Mobile IPv6 169 domains is illustrated in Figure 1. It displays the general setting 170 for source mobility - Mobile Nodes (MNs) with Home Network Prefixes 171 (HNPs) that receive services via tunnels, which are spanned between a 172 Local Mobility Anchor Address (LMAA) and a Proxy Care-of-Address 173 (Proxy-CoA) at a Mobility Access Gateway (MAG). MAGs play the role 174 of first-hop access routers that serve multiple MNs on the downstream 175 while running an MLD/IGMP proxy instance for every LMA upstream 176 tunnel. 178 +-------------+ 179 | Multicast | 180 | Listeners | 181 +-------------+ 182 | 183 *** *** *** *** 184 * ** ** ** * 185 * * 186 * Fixed Internet * 187 * * 188 * ** ** ** * 189 *** *** *** *** 190 / \ 191 +----+ +----+ 192 |LMA1| |LMA2| Multicast Anchor 193 +----+ +----+ 194 LMAA1 | | LMAA2 195 | | 196 \\ //\\ 197 \\ // \\ 198 \\ // \\ Unicast Tunnel 199 \\ // \\ 200 \\ // \\ 201 \\ // \\ 202 Proxy-CoA1 || || Proxy-CoA2 203 +----+ +----+ 204 |MAG1| |MAG2| MLD Proxy 205 +----+ +----+ 206 | | | 207 MN-HNP1 | | MN-HNP2 | MN-HNP3 208 | | | 209 MN1 MN2 MN3 211 Multicast Sender + Listener(s) 213 Figure 1: Reference Network for Multicast Deployment in PMIPv6 215 An MN in a PMIPv6 domain will decide on multicast data transmission 216 completely independent of its current mobility conditions. It will 217 send packets as initiated by applications, using its source address 218 with Home Network Prefix (HNP) and a multicast destination address 219 chosen by application needs. Multicast packets will arrive at the 220 currently active MAG via one of its downstream local (wireless) 221 links. A multicast unaware MAG would simply discard these packets in 222 the absence of instructions for packet processing, i.e., a multicast 223 routing information base (MRIB). 225 An MN can successfully distribute multicast data in PMIPv6, if MLD 226 proxy functions are deployed at the MAG as described in [RFC6224]. 227 In this set-up, the MLD proxy instance serving a mobile multicast 228 source has configured its upstream interface at the tunnel towards 229 MN's corresponding LMA. For each LMA, there will be a separate 230 instance of an MLD proxy. 232 According to the specifications given in [RFC4605], multicast data 233 arriving from a downstream interface of an MLD proxy will be 234 forwarded to the upstream interface and to all but the incoming 235 downstream interfaces that have appropriate forwarding states for 236 this group. Thus multicast streams originating from an MN will 237 arrive at the corresponding LMA and directly at all mobile receivers 238 co-located at the same MAG and MLD proxy instance. Serving as the 239 designated multicast router or an additional MLD proxy, the LMA 240 forwards data to the fixed Internet, whenever forwarding states are 241 maintained by multicast routing. If the LMA is acting as another MLD 242 proxy, it will forward the multicast data to its upstream interface, 243 and to downstream interfaces with matching subscriptions, 244 accordingly. 246 In case of a handover, the MN (being unaware of IP mobility) can 247 continue to send multicast packets as soon as network connectivity is 248 re-established. At this time, the MAG has determined the 249 corresponding LMA, and IPv6 unicast address configuration (including 250 PMIPv6 bindings) has been completed. Still multicast packets 251 arriving at the MAG are discarded (if not buffered) until the MAG has 252 completed the following steps. 254 1. The MAG has determined that the MN is admissible to multicast 255 services. 257 2. The MAG has added the new downstream link to the MLD proxy 258 instance with up-link to the corresponding LMA. 260 As soon as the MN's uplink is associated with the corresponding MLD 261 proxy instance, multicast packets are forwarded again to the LMA and 262 eventually to receivers within the PMIP domain (see the call flow in 263 Figure 2). In this way, multicast source mobility is transparently 264 enabled in PMIPv6 domains that deploy the base scenario for 265 multicast. 267 MN1 MAG1 MN2 MAG2 LMA 268 | | | | | 269 | | Mcast Data | | | 270 | |<---------------+ | | 271 | | Mcast Data | | | 272 | Join(G) +================================================>| 273 +--------------> | | | | 274 | Mcast Data | | | | 275 |<---------------+ | | | 276 | | | | | 277 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 278 | | | | | 279 | | |--- Rtr Sol -->| | 280 | | |<-- Rtr Adv ---| | 281 | | | | | 282 | | | < MLD Proxy Configuration > | 283 | | | | | 284 | | | (MLD Query) | | 285 | | |<--------------+ | 286 | | | Mcast Data | | 287 | | +-------------->| | 288 | | | | Mcast Data | 289 | | | +===============>| 290 | | | | | 291 | | Mcast Data | | | 292 | |<================================================+ 293 | Mcast Data | | | | 294 |<---------------+ | | | 295 | | | | | 297 Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP 299 These multicast deployment considerations likewise apply for mobile 300 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 301 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 302 IPv4 multicast is handled by an IGMP proxy function at the MAG in an 303 analogous way. 305 Following these deployment steps, multicast traffic distribution 306 transparently inter-operates with PMIPv6. It is worth noting that an 307 MN - while being attached to the same MAG as the mobile source, but 308 associated with a different LMA - cannot receive multicast traffic on 309 a shortest path. Instead, multicast streams flow up to the LMA of 310 the mobile source, are transferred to the LMA of the mobile listener 311 and tunneled downwards to the MAG again (see Section 5 for further 312 optimizations). 314 3.2. Base Solution for Source Mobility: Details 316 A support of multicast source mobility in PMIPv6 requires to deploy 317 general multicast functions at PMIPv6 routers and to define their 318 interaction with the PMIPv6 protocol in the following way. 320 3.2.1. Operations of the Mobile Node 322 A Mobile Node willing to send multicast data will proceed as if 323 attached to the fixed Internet. No specific mobility or other 324 multicast related functionalities are required at the MN. 326 3.2.2. Operations of the Mobile Access Gateway 328 A Mobile Access Gateway is required to have MLD proxy instances 329 deployed, one for each tunnel to an LMA, which serves as its unique 330 upstream link (cf., [RFC6224]). On the arrival of an MN, the MAG 331 decides on the mapping of downstream links to a proxy instance and 332 the upstream link to the LMA based on the regular Binding Update List 333 as maintained by PMIPv6 standard operations. When multicast data is 334 received from the MN, the MAG MUST identify the corresponding proxy 335 instance from the incoming interface and forwards multicast data 336 upstream according to [RFC4605]. 338 The MAG MAY apply special admission control to enable multicast data 339 transmission from an MN. It is advisable to take special care that 340 MLD proxy implementations do not redistribute multicast data to 341 downstream interfaces without appropriate subscriptions in place. 343 3.2.3. Operations of the Local Mobility Anchor 345 For any MN, the Local Mobility Anchor acts as the persistent Home 346 Agent and at the same time as the default multicast upstream for the 347 corresponding MAG. It will manage and maintain a multicast 348 forwarding information base for all group traffic arriving from its 349 mobile sources. It SHOULD participate in multicast routing functions 350 that enable traffic redistribution to all adjacent LMAs within the 351 PMIPv6 domain and thereby ensure a continuous receptivity while the 352 source is in motion. 354 3.2.3.1. Local Mobility Anchors Operating PIM 356 Local Mobility Anchors that operate the PIM-SM routing protocol 357 [RFC4601] will require sources to be directly connected for sending 358 PIM registers to the RP. This does not hold in a PMIPv6 domain, as 359 MAGs are routers intermediate to MN and the LMA. In this sense, MNs 360 are multicast sources external to the PIM-SM domain. 362 To mitigate this incompatibility common to all subsidiary MLD proxy 363 domains, the LMA MUST act as a PIM Border Router and activate the 364 Border-bit. In this case, the DirectlyConnected(S) is treated as 365 being TRUE for mobile sources and the PIM-SM forwarding rule "iif == 366 RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 367 interface from MAG to LMA is considered as not part of the PIM-SM 368 component of the LMA (see A.1 of [RFC4601] ). 370 In addition, an LMA serving as PIM Designated Router (DR) is 371 connected to MLD proxies via individual IP-tunnel interfaces and will 372 experience changing PIM source states on handover. As the incoming 373 interface connects to a point-to-point link, PIM Assert contention is 374 not active, and incoming interface validation is only performed by 375 Reverse Path Forwarding (RPF) checks. Consequently, a PIM DR SHOULD 376 update incoming source states, as soon as RPF inspection succeeds, 377 i.e., after PMIPv6 forwarding state update. Consequently, PIM 378 routers SHOULD be able to manage these state changes, but some 379 implementations are expected to incorrectly refuse packets until the 380 previous state has timed out. 382 Notably, running BIDIR-PIM [RFC5015] on LMAs remains robust with 383 respect to source location and does not require special 384 configurations or state management for sources. 386 3.2.4. IPv4 Support 388 An MN in a PMIPv6 domain may use an IPv4 address transparently for 389 communication as specified in [RFC5844]. For this purpose, an LMA 390 can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can 391 provide IPv4 support in its access network. Correspondingly, 392 multicast membership management will be performed by the MN using 393 IGMP. For multicast support on the network side, an IGMP proxy 394 function needs to be deployed at MAGs in exactly the same way as for 395 IPv6. [RFC4605] defines IGMP proxy behaviour in full agreement with 396 IPv6/MLD. Thus IPv4 support can be transparently provided following 397 the obvious deployment analogy. 399 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 400 SHOULD choose multicast signaling according to address configurations 401 on the link, but MAY submit IGMP and MLD queries in parallel, if 402 needed. It should further be noted that the infrastructure cannot 403 identify two data streams as identical when distributed via an IPv4 404 and IPv6 multicast group. Thus duplicate data may be forwarded on a 405 heterogeneous network layer. 407 A particular note is worth giving the scenario of [RFC5845] in which 408 overlapping private address spaces of different operators can be 409 hosted in a PMIP domain by using GRE encapsulation with key 410 identification. This scenario implies that unicast communication in 411 the MAG-LMA tunnel can be individually identified per MN by the GRE 412 keys. This scenario still does not impose any special treatment of 413 multicast communication for the following reasons. 415 Multicast streams from and to MNs arrive at a MAG on point-to-point 416 links (identical to unicast). Multicast data transmission from the 417 MAG to the corresponding LMA is link-local between the routers and 418 routing/forwarding remains independent of any individual MN. So the 419 MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain 420 GRE encapsulation in multicast communication (including MLD queries 421 and reports). Multicast traffic is transmitted as router-to-router 422 forwarding via the MAG-to-LMA tunnels and according to the multicast 423 routing information base (MRIB) of the MAG or the LMA. It remains 424 independent of MN's unicast addresses, while the MAG proxy instance 425 redistributes multicast data down the point-to-point links 426 (interfaces) according to its local subscription states, independent 427 of IP addresses of the MN. 429 3.2.5. Efficiency of the Distribution System 431 The distribution system of the base solution directly follows PMIPv6 432 routing rules, and organizes multicast domains with respect to LMAs. 433 Thus, no coordination between address spaces or services is required 434 between the different instances, provided their associated LMAs 435 belong to disjoint multicast domains. Routing is optimal for 436 communication between MNs of the same domain, or stationary 437 subscribers. 439 In the following, efficiency-related issues remain. 441 Multicast reception at LMA In the current deployment scenario, the 442 LMA will receive all multicast traffic originating from its 443 associated MNs. There is no mechanism to suppress upstream 444 forwarding in the absence of receivers. 446 MNs on the same MAG using different LMAs For a mobile receiver and a 447 source that use different LMAs, the traffic has to go up to one 448 LMA, cross over to the other LMA, and then be tunneled back to the 449 same MAG, causing redundant flows in the access network and at the 450 MAG. 452 These remaining deficits in routing efficiency can be resolved by 453 adding peering functions to MLD proxies as described in Section 5. 455 4. Direct Multicast Routing 457 There are deployment scenarios, where multicast services are 458 available throughout the access network independent of the PMIPv6 459 routing system [RFC7028]. In these cases, the visited networks grant 460 a local content distribution service (in contrast to LMA-based home 461 subscription) with locally optimized traffic flows. It is also 462 possible to deploy a mixed service model of local and LMA-based 463 subscriptions, provided a unique way of service selection is 464 implemented. For example, access routers (MAGs) could decide on 465 service access based on the multicast address G or the SSM channel 466 (S,G) under request (see Appendix A for further discussions). 468 4.1. Overview 470 Direct multicast access can be supported by 472 o native multicast routing provided by one multicast router that is 473 neighboring MLD proxies deployed at MAGs within a flat access 474 network, or via tunnel uplinks, 476 o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM 477 [RFC5015] deployed at the MAGs. 479 *** *** *** *** 480 * ** ** ** * 481 * * 482 * Multicast * 483 +----+ * Infrastructure * +----+ 484 |LMA | * ** ** ** * |LMA | 485 +----+ *** *** *** *** +----+ 486 | // \\ | 487 \\ // \\ PMIP (unicast) | 488 PMIP \\ // \\ // \\ ** *** *** ** // 489 (unicast) \\ // \\ // \\ * ** ** ** // 490 \\ // \\ // \\* Multicast *// 491 || || || || * || Routing || * 492 +----+ +----+ * +----+ +----+ * 493 MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| * 494 +----+ +----+ *+----+ ** ** +----+* 495 | | | | |*** *** ***| 496 | | | | | | 497 MN1 MN2 MN3 MN1 MN2 MN3 499 (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG 501 Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast 502 Access and (b) Dynamic Multicast Routing at MAGs 504 Figure 3 displays the corresponding deployment scenarios, which 505 separate multicast from PMIPv6 unicast routing. It is assumed 506 throughout these scenarios that all MAGs (MLD proxies) are linked to 507 a single multicast routing domain. Notably, this scenario requires 508 coordination of multicast address utilization and service bindings. 510 Multicast traffic distribution can be simplified in these scenarios. 511 A single proxy instance at MAGs with up-link into the multicast 512 domain will serve as a first hop multicast gateway and avoid traffic 513 duplication or detour routing. Multicast routing functions at MAGs 514 will seamlessly embed access gateways within a multicast cloud. 515 However, mobility of the multicast source in this scenario will 516 require some multicast routing protocols to rebuild distribution 517 trees. This can cause significant service disruptions or delays (see 518 [RFC5757] for further aspects). Deployment details are specific to 519 the multicast routing protocol in use, in the following described for 520 common protocols. 522 4.2. MLD Proxies at MAGs 524 In a PMIPv6 domain, single MLD proxy instances can be deployed at 525 each MAG that enable multicast service at the access via an uplink to 526 a multicast service infrastructure (see Figure 3 (a) ). To avoid 527 service disruptions on handovers, the uplinks of all proxies SHOULD 528 be adjacent to the same next-hop multicast router. This can either 529 be achieved by arranging proxies within a flat access network, or by 530 upstream tunnels that terminate at a common multicast router. 532 Multicast data submitted by a mobile source will reach the MLD proxy 533 at the MAG that subsequently forwards flows to the upstream, and all 534 downstream interfaces with appropriate subscriptions. Traversing the 535 upstream will transfer traffic into the multicast infrastructure 536 (e.g., to a PIM Designated Router) which will route packets to all 537 local MAGs that have joined the group, as well as further upstream 538 according to protocol procedures and forwarding states. 540 On handover, a mobile source will reattach to a new MAG and can 541 continue to send multicast packets as soon as PMIPv6 unicast 542 configurations have been completed. Like at the previous MAG, the 543 new MLD proxy will forward data upstream and downstream to 544 subscribers. Listeners local to the previous MAG will continue to 545 receive group traffic via the local multicast distribution 546 infrastructure following aggregated listener reports of the previous 547 proxy. In general, traffic from the mobile source continues to be 548 transmitted via the same next-hop multicast router using the same 549 source address and thus remains unchanged when seen from the wider 550 multicast infrastructure. 552 4.2.1. Considerations for PIM-SM on the Upstream 554 A mobile source that transmits data via an MLD proxy will not be 555 directly connected to a PIM Designated Router as discussed in 556 Section 3.2.3.1. Countermeasures apply correspondingly. 558 A PIM Designated Router that is connected to MLD proxies via 559 individual IP-tunnel interfaces will experience invalid PIM source 560 states on handover. In some implementations of PIM-SM this could 561 lead to an interim packet loss (see Section 3.2.3.1). This problem 562 can be mitigated by aggregating proxies on a lower layer. 564 4.2.2. SSM Considerations 566 Source-specific subscriptions invalidate with routes, whenever the 567 source moves from or to the MAG/proxy of a subscriber. Multicast 568 forwarding states will rebuild with unicast route changes. However, 569 this may lead to noticeable service disruptions for locally 570 subscribed nodes. 572 4.3. PIM-SM at MAGs 574 The full-featured multicast routing protocol PIM-SM MAY be deployed 575 in the access network for providing multicast services in parallel to 576 unicast routes (see Figure 3 b). Throughout this section, it is 577 assumed that the PMIPv6 mobility domain is part of a single PIM-SM 578 multicast routing domain with PIM-SM routing functions present at all 579 MAGs and all LMAs. The PIM routing instance at a MAG SHALL then 580 serve as the Designated Router (DR) for all directly attached Mobile 581 Nodes. For expediting handover operations, it is advisable to 582 position PIM Rendezvous Points (RPs) in the core of the PMIPv6 583 network domain. However, regular IP routing tables need not be 584 present in a PMIPv6 deployment, and additional effort is required to 585 establish reverse path forwarding rules as required by PIM-SM. 587 4.3.1. Routing Information Base for PIM-SM 589 In this scenario, PIM-SM will rely on a Multicast Routing Information 590 Base (MRIB) that is generated independently of the policy-based 591 routing rules of PMIPv6. The granularity of mobility-related routing 592 locators required in PIM depends on the complexity (phases) of its 593 deployment. 595 The following information is needed for all three phases of PIM as 596 defined in [RFC4601]. 598 o All routes to networks and nodes (including RPs) that are not 599 mobile members of the PMIPv6 domain MUST be defined consistently 600 among PIM routers and MUST remain unaffected by node mobility. 601 The setup of these general routes is expected to follow the 602 topology of the operator network and is beyond the scope of this 603 document. 605 The following route entries are required at a PIM-operating MAG when 606 phases two or three of PIM, or PIM-SSM are in operation. 608 o Local routes to the Home Network Prefixes (HNPs) of all MNs 609 associated with their corresponding point-to-point attachments 610 that MUST be included in the local MRIB. 612 o All routes to MNs that are attached to distant MAGs of the PMIPv6 613 domain point towards their corresponding LMAs. These routes MUST 614 be made available in the MRIB of all PIM routers (except for the 615 local MAG of attachment), but MAY be eventually expressed by an 616 appropriate default entry. 618 4.3.2. Operations of PIM in Phase One 620 A new mobile source S will transmit multicast data of group G towards 621 its MAG of attachment. Acting as a PIM DR, the access gateway will 622 unicast-encapsulate the multicast packets and forward the data to the 623 Virtual Interface (VI) with encapsulation target RP(G), a process 624 known as PIM source registering. The RP will decapsulate and 625 natively forward the packets down the RP-based distribution tree 626 towards (mobile and stationary) subscribers. 628 On handover, the point-to-point link connecting the mobile source to 629 the old MAG will go down and all (S,*) flows terminate. In response, 630 the previous DR (MAG) deactivates the data encapsulation channels for 631 the transient source (i.e., all DownstreamJPState(S,*,VI) are set to 632 NoInfo state). After reattaching and completing unicast handover 633 negotiations, the mobile source can continue to transmit multicast 634 packets, while being treated as a new source at its new DR (MAG). 635 Source register encapsulation will be immediately initiated, and 636 (S,G) data continue to flow natively down the (*,G) RP-based tree. 638 Source handover management in PIM phase one admits low complexity and 639 remains transparent to receivers. In addition, the source register 640 tunnel management of PIM is a fast protocol operation and little 641 overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be 642 configured to not initiated (S,G) shortest path trees for mobile 643 sources, and thus remain in phase one of the protocol. The price to 644 pay for such simplified deployment lies in possible routing detours 645 by an overall RP-based packet distribution. 647 4.3.3. Operations of PIM in Phase Two 649 After receiving source register packets, a PIM RP eventually will 650 initiate a source-specific Join for creating a shortest path tree to 651 the (mobile) source S, and issue a source register stop at the native 652 arrival of data from S. For initiating an (S,G) tree, the RP, as well 653 as all intermediate routers, require route entries for the HNP of the 654 MN that - unless the RP coincides with the MAG of S - point towards 655 the corresponding LMA of S. Consequently, the (S,G) tree will proceed 656 from the RP via the (stable) LMA, down the LMA-MAG tunnel to the 657 mobile source. This tree can be of lower routing efficiency than the 658 PIM source register tunnel established in phase one. 660 On handover, the mobile source reattaches to a new MAG (DR), and 661 PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new 662 point of attachment. However, in the absence of a corresponding 663 multicast forwarding state, the new DR will treat S as a new source 664 and initiate a source registering of PIM phase one with the RP. In 665 response, the PIM RP will recognize the known source at a new 666 (tunnel) interface and immediately responds with a register stop. As 667 the RP had previously joined the shortest path tree towards the 668 source via the LMA, it will see an RPF change when data arrives at a 669 new interface. Implementation-dependent, this can trigger an update 670 of the PIM MRIB and trigger a new PIM Join message that will install 671 the multicast forwarding state missing at the new MAG. Otherwise, 672 the tree is periodically updated by Joins transmitted towards the new 673 MAG on a path via the LMA. In proceeding this way, a quick recovery 674 of PIM transition from phase one to two will be performed per 675 handover. 677 4.3.4. Operations of PIM in Phase Three 679 In response to an exceeded threshold of packet transmission, DRs of 680 receivers eventually will initiate a source-specific Join for 681 creating a shortest path tree to the (mobile) source S, thereby 682 transitioning PIM into the final short-cut phase three. For all 683 receivers not sharing a MAG with S, this (S,G) tree will range from 684 the receiving DR via the (stable) LMA, the LMA-MAG tunnel, and the 685 serving MAG to the mobile source. This tree is of higher routing 686 efficiency than that established in the previous phase two, but need 687 not outperform the PIM source register tunnel established in phase 688 one. It provides the advantage of immediate data delivery to 689 receivers that share a MAG with S. 691 On handover, the mobile source reattaches to a new MAG (DR), and 692 PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new 693 point of attachment. However, in the absence of a corresponding 694 multicast forwarding state, the new DR will treat S as a new source 695 and initiate a source registering of PIM phase one. A PIM 696 implementation compliant with this change can recover phase three 697 states in the following way. First, the RP recovers to phase two as 698 described in the previous section, and will not forward data arriving 699 via the source register tunnel. Tree maintenance eventually 700 triggered by the RPF change (see Section 4.3.3) will generate proper 701 states for a native forwarding from the new MAG via the LMA. 702 Thereafter, packets arriving at the LMA without source register 703 encapsulation are forwarded natively along the shortest path tree 704 towards receivers. 706 In consequence, the PIM transitions from phase one to two and to 707 three will be quickly recovered per handover, but still lead to an 708 enhanced signaling load and intermediate packet loss. 710 4.3.5. PIM-SSM Considerations 712 Source-specific Joins of receivers will guide PIM to operate in SSM 713 mode and lead to an immediate establishment of source-specific 714 shortest path trees. Such (S,G) trees will equal the distribution 715 system of PIM's final phase three (see Section 4.3.4). However, on 716 handover and in the absence of RP-based data distribution, SSM data 717 delivery cannot be resumed via source registering as in PIM phase 718 one. Consequently, data packets transmitted after a handover will be 719 discarded at the MAG until regular tree maintenance has reestablished 720 the (S,G) forwarding state at the new MAG. 722 4.3.6. Handover Optimizations for PIM 724 Source-specific shortest path trees are constructed in PIM-SM (phase 725 two and three), and in PIM-SSM that follow LMA-MAG tunnels towards a 726 source. As PIM remains unaware of source mobility management, these 727 trees invalidate under handovers with each tunnel re-establishment at 728 a new MAG. Regular tree maintenance of PIM will recover the states, 729 but remains unsynchronized and too slow to seamlessly preserve PIM 730 data distribution services. 732 A method to quickly recover PIM (S,G) trees under handover SHOULD 733 synchronize multicast state maintenance with unicast handover 734 operations and can proceed as follows. On handover, an LMA reads all 735 (S,G) Join states from its corresponding tunnel interface and 736 identifies those source addresses S_i that match moving HNPs. After 737 re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join 738 states with the new tunnel endpoint and immediately trigger a state 739 maintenance (PIM Join) message. In proceeding this way, the source- 740 specific PIM states are transferred to the new tunnel end point and 741 propagated to the new MAG in synchrony with unicast handover 742 procedures. 744 4.4. BIDIR-PIM 746 BIDIR-PIM MAY be deployed in the access network for providing 747 multicast services in parallel to unicast routes. Throughout this 748 section, it is assumed that the PMIPv6 mobility domain is part of a 749 single BIDIR-PIM multicast routing domain with BIDIR-PIM routing 750 functions present at all MAGs and all LMAs. The PIM routing instance 751 at a MAG SHALL then serve as the Designated Forwarder (DF) for all 752 directly attached Mobile Nodes. For expediting handover operations, 753 it is advisable to position BIDIR-PIM Rendezvous Point Addresses 754 (RPAs) in the core of the PMIPv6 network domain. As regular IP 755 routing tables need not be present in a PMIPv6 deployment, reverse 756 path forwarding rules as required by BIDIR-PIM need to be 757 established. 759 4.4.1. Routing Information Base for BIDIR-PIM 761 In this scenario, BIDIR-PIM will rely on a Multicast Routing 762 Information Base (MRIB) that is generated independently of the 763 policy-based routing rules of PMIPv6. The following information is 764 needed. 766 o All routes to networks and nodes (including RPAs) that are not 767 mobile members of the PMIPv6 domain MUST be defined consistently 768 among BIDIR-PIM routers and remain unaffected by node mobility. 769 The setup of these general routes is expected to follow the 770 topology of the operator network and is beyond the scope of this 771 document. 773 4.4.2. Operations of BIDIR-PIM 775 BIDIR-PIM will establish spanning trees across its network domain in 776 conformance to its pre-configured RPAs and the routing information 777 provided. Multicast data transmitted by a mobile source will 778 immediately be forwarded by its DF (MAG) onto the spanning tree for 779 the multicast group without further protocol operations. 781 On handover, the mobile source reattaches to a new MAG (DF), which 782 completes unicast network configurations. Thereafter, the source can 783 immediately proceed with multicast packet transmission onto the pre- 784 established distribution tree. BIDIR-PIM does neither require 785 protocol signaling nor additional reconfiguration delays to adapt to 786 source mobility and can be considered the protocol of choice for 787 mobile multicast operations in the access. As multicast streams 788 always flow up to the Rendezvous Point Link, some care should be 789 taken to configure RPAs compliant with network capacities. 791 5. MLD Proxy Peering Function for Optimized Source Mobility in PMIPv6 793 A deployment of MLD Proxies (see [RFC4605]) at MAGs has proven a 794 useful and appropriate approach to multicast in PMIPv6, see 795 [RFC6224], [RFC7028]. However, deploying unmodified standard proxies 796 can go along with significant performance degradation for mobile 797 senders as discussed along the lines of this document. To overcome 798 these deficits, an optimized approach to multicast source mobility 799 based on extended peering functions among proxies is defined in this 800 section. Based on such direct data exchange between proxy instances 801 at MAGs, triangular routing is avoided and multicast streams can be 802 disseminated directly within a PMIPv6 access network, and in 803 particular within MAG routing machines. Prior to presenting the 804 solution, we will summarize the relevant requirements. 806 5.1. Requirements 808 Solutions that extend MLD Proxies by additional uplinking functions 809 need to comply to the following requirements. 811 Prevention of Routing Loops In the absence of a full-featured 812 routing logic at an MLD Proxy, simple and locally decidable rules 813 need to prevent source traffic from traversing the network in 814 loops as potentially enabled by multiple uplinks. 816 Unique coverage of receivers Listener functions at Proxies require 817 simple, locally decidable rules to initiate a unique delivery of 818 multicast packets to all receivers. 820 Following local filter techniques, these requirements are met in the 821 following solution. 823 5.2. Overview 825 A peering interface for MLD proxies allows for a direct data exchange 826 of locally attached multicast sources. Such peering interfaces can 827 be configured - as a direct link or a bidirectional tunnel - between 828 any two proxy instances (locally deployed as in [RFC6224] or 829 remotely). Peerings remain as silent virtual links in regular proxy 830 operations. Data is exchanged on such links only in cases, where one 831 peering proxy on its downstream directly connects to a source of 832 multicast traffic, which the other peering proxy actively subscribes 833 to. In such cases, the proxy connected to the source will receive a 834 listener report on its peering interface and forwards traffic from 835 its local source accordingly. It is worth noting that multicast 836 traffic distribution on peering links does not follow reverse unicast 837 paths to sources. In the following, operations are defined for ASM 838 and SSM, but provide superior performance in the presence of source- 839 specific signaling (IGMPv3/MLDv2) [RFC4604]. 841 5.3. Operations in Support of Multicast Senders 843 An MLD proxy in the perspective of a sender will see peering 844 interfaces as restricted downstream interfaces. It will install and 845 maintain source filters at its peering links that will restrict data 846 transmission to those packets that originate from a source that is 847 locally attached at one of its downstream interfaces. 849 In detail, a proxy will extract from its configuration the network 850 prefixes attached to its downstream interfaces and MUST implement a 851 source filter base at its peering interfaces that restricts data 852 transmission to IP source addresses from its local prefixes. This 853 filter base MUST be updated, if and only if the downstream 854 configuration changes (e.g., due to mobility). Multicast packets 855 that arrive from the upstream interface of the proxy are thus 856 prevented from traversing any peering link, but are only forwarded to 857 regular downstream interfaces with appropriate subscription states. 858 In this way, a multihop forwarding on peering links is prevented. 860 Multicast traffic arriving from a locally attached source will be 861 forwarded to the regular upstream interface and all downstreams with 862 appropriate subscription states (i.e., regular proxy operations). In 863 addition, multicast packets of local origin are transferred to those 864 peering interfaces with appropriate subscription states. 866 5.4. Operations in Support of Multicast Listeners 868 At the listener side, peering interfaces appear as preferred upstream 869 links. The multicast proxy will attempt to receive multicast 870 services on peering links for as many groups (channels) as possible. 871 The general upstream interface configured according to [RFC4605] will 872 be used only for retrieving those groups (channels) that remain 873 unavailable from peerings. From this extension of [RFC4605], an MLD 874 proxy with peering interconnects will exhibit several interfaces for 875 pulling remote traffic: the regular upstream and the peerings. 876 Traffic available from any of the peering links will be mutually 877 disjoint, but normally also available from the upstream. To prevent 878 duplicate traffic from arriving at the listener side, the proxy 880 o MAY delay aggregated reports to the upstream, and 882 o MUST apply appropriate filters to exclude duplicate streams. 884 In detail, an MLD proxy instance at a MAG first issues listener 885 reports (in parallel) to all of its peering links. These links span 886 at most one (virtual) hop. Whenever certain group traffic (SSM 887 channels) does not arrive from the peerings after a waiting time 888 (default: 10 ms (node-local) and 25 ms (remote)), additional 889 (complementary, in the case of SSM) reports are sent to the standard 890 upstream interface. 892 Whenever traffic from a peering link arrives, an MLD proxy MUST 893 install source filters at its RFC 4605 upstream in the following way. 895 ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using 896 IGMPv2/MLDv1, only, the proxy cannot signal source filtering to 897 its upstream. Correspondingly, it applies (S,*) ingress filters 898 at its upstream interface for all sources S seen in traffic on the 899 peering links. It is noteworthy that unwanted traffic is still 900 replicated to the proxy via the (wired) provider backbone, but it 901 is not forwarded into the wireless access network. 903 ASM with IGMPv3/MLDv2 In the presence of source-specific signaling 904 (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude 905 mode for all sources S seen in traffic of the peering links. The 906 corresponding source-specific signaling will prevent forwarding of 907 duplicate traffic throughout the access network. 909 SSM In the presence of Source Specific Multicast, the proxy will 910 subscribe on its uplink interface to those (S,G) channels, only, 911 that do not arrive via the peering links. 913 MLD proxies will install data-driven timers (source-timeout) for each 914 source but common to all peering interfaces to detect interruptions 915 of data services from individual sources at proxy peers. Termination 916 of source-specific flows may be application-specific, but also due to 917 a source handover, or transmission failures. After a handover, a 918 mobile source may reattach at another MLD proxy with peering relation 919 to the listener, or at a proxy that does not peer. While in the 920 first case, traffic reappears on another peering link, in the second 921 case data can only be retrieved via the regular upstream. To account 922 for the latter, the MLD proxy revokes the source-specific filter(s) 923 at its upstream interface, after the source-timeout fires (default: 924 50 ms). Corresponding traffic will then be pulled from the regular 925 upstream. Source-specific filters MUST be reinstalled, whenever 926 traffic of this source arrives at any peering interface. 928 There is a noteworthy trade-off between traffic minimization and 929 available traffic at the upstream that is locally filtered at the 930 proxy. Implementors can use this relation to optimize for service- 931 specific requirements. 933 In proceeding this way, multicast group data will arrive from peering 934 interfaces first, while only peer-wise unavailable traffic is 935 retrieved from the regular upstream interface. 937 6. IANA Considerations 939 This document makes no request to IANA.. 941 Note to RFC Editor: this section may be removed on publication as an 942 RFC. 944 7. Security Considerations 946 This document defines multicast sender mobility based on PMIPv6 and 947 common multicast routing protocols. Consequently, threats identified 948 as security concerns of [RFC2710] [RFC3810], [RFC4605], [RFC5213], 949 and [RFC5844] are inherited by this document. 951 In addition, particular attention should be paid to implications of 952 combining multicast and mobility management at network entities. As 953 this specification allows mobile nodes to initiate the creation of 954 multicast forwarding states at MAGs and LMAs while changing 955 attachments, threats of resource exhaustion at PMIP routers and 956 access networks arrive from rapid state changes, as well as from high 957 volume data streams routed into access networks of limited 958 capacities. In cases of PIM-SM deployment, handover operations of 959 the MNs include re-registering sources at the Rendezvous Points at 960 possibly high frequency. In addition to proper authorization checks 961 of MNs, rate controls at routing agents and replicators MAY be 962 required to protect the agents and the downstream networks. In 963 particular, MLD proxy implementations at MAGs SHOULD carefully 964 procure for automatic multicast state extinction on the departure of 965 MNs, as mobile multicast listeners in the PMIPv6 domain will in 966 general not actively terminate group membership prior to departure. 968 The deployment of IGMP/MLD proxies for multicast routing requires 969 particular care, as routing loops on the upstream are not 970 automatically detected. Peering functions between proxies extend 971 this threat in the following way. Routing loops among peering and 972 upstream interfaces are prevented by filters on local sources. Such 973 filtering can fail, whenever prefix configurations for downstream 974 interfaces at a proxy are incorrect or inconsistent. Consequently, 975 implementations of peering-enabled proxies SHOULD take particular 976 care on maintaining (varying) IP configurations at the downstream in 977 a reliable and timely manner (see [RFC6224] for requirements on 978 PMIPv6-compliant implementations of MLD proxies). 980 8. Acknowledgements 982 The authors would like to thank (in alphabetical order) Luis M. 983 Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, 984 Jouni Korhonen, He-Wu Li, Cong Liu, Akbar Rahman, Behcet Sarikaya, 985 Stig Venaas, Li-Li Wang, Sebastian Woelke, Qian Wu, Zhi-Wei Yan for 986 advice, help and reviews of the document. Funding by the German 987 Federal Ministry of Education and Research within the G-LAB 988 Initiative (projects HAMcast, Mindstone and SAFEST) is gratefully 989 acknowledged. 991 9. References 993 9.1. Normative References 995 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 996 Requirement Levels", BCP 14, RFC 2119, March 1997. 998 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 999 Listener Discovery (MLD) for IPv6", RFC 2710, October 1000 1999. 1002 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1003 Thyagarajan, "Internet Group Management Protocol, Version 1004 3", RFC 3376, October 2002. 1006 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1007 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1009 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1010 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1011 Protocol Specification (Revised)", RFC 4601, August 2006. 1013 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1014 "Internet Group Management Protocol (IGMP) / Multicast 1015 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 1016 /MLD Proxying")", RFC 4605, August 2006. 1018 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1019 "Bidirectional Protocol Independent Multicast (BIDIR- 1020 PIM)", RFC 5015, October 2007. 1022 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1023 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1025 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1026 Mobile IPv6", RFC 5844, May 2010. 1028 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1029 in IPv6", RFC 6275, July 2011. 1031 9.2. Informative References 1033 [I-D.ietf-multimob-fmipv6-pfmipv6-multicast] 1034 Schmidt, T., Waehlisch, M., Koodli, R., Fairhurst, G., and 1035 D. Liu, "Multicast Listener Extensions for MIPv6 and 1036 PMIPv6 Fast Handovers", draft-ietf-multimob- 1037 fmipv6-pfmipv6-multicast-01 (work in progress), February 1038 2013. 1040 [I-D.ietf-multimob-handover-optimization] 1041 Contreras, L., Bernardos, C., and I. Soto, "PMIPv6 1042 multicast handover optimization by the Subscription 1043 Information Acquisition through the LMA (SIAL)", draft- 1044 ietf-multimob-handover-optimization-06 (work in progress), 1045 November 2013. 1047 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1048 2", RFC 2236, November 1997. 1050 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 1051 Group Management Protocol Version 3 (IGMPv3) and Multicast 1052 Listener Discovery Protocol Version 2 (MLDv2) for Source- 1053 Specific Multicast", RFC 4604, August 2006. 1055 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 1056 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 1057 and Brief Survey", RFC 5757, February 2010. 1059 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 1060 "Generic Routing Encapsulation (GRE) Key Option for Proxy 1061 Mobile IPv6", RFC 5845, June 2010. 1063 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1064 Deployment for Multicast Listener Support in Proxy Mobile 1065 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1067 [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and 1068 Y. Kim, "Multicast Mobility Routing Optimizations for 1069 Proxy Mobile IPv6", RFC 7028, September 2013. 1071 Appendix A. Multiple Upstream Interface Proxy 1073 In this section, we document upstream extensions for an MLD proxy 1074 that were originally developed during the work on this document. 1075 Multiple proxy instances deployed at a single MAG (see Section 3) can 1076 be avoided by adding multiple upstream interfaces to a single MLD 1077 Proxy. In a typical PMIPv6 deployment, each upstream of a single 1078 proxy instance can interconnect to one of the LMAs. With such 1079 ambiguous upstream options, appropriate forwarding rules MUST be 1080 supplied to 1082 o unambiguously guide traffic forwarding from directly attached 1083 mobile sources, and 1085 o lead listener reports to initiating unique traffic subscriptions. 1087 This can be achieved by a complete set of source- and group-specific 1088 filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. 1089 These filters MAY be derived in parts from PMIPv6 routing policies, 1090 and can include a default behavior (e.g., (*,*)). 1092 A.1. Operations for Local Multicast Sources 1094 Packets from a locally attached multicast source will be forwarded to 1095 all downstream interfaces with appropriate subscriptions, as well as 1096 up the interface with the matching source-specific filter. 1098 Typically, the upstream interface for a mobile multicast source is 1099 chosen based on the policy routing (e.g., the MAG-LMA tunnel 1100 interface for LMA-based routing or the interface towards the 1101 multicast router for direct routing), but alternate configurations 1102 MAY be applied. Packets from a locally attached multicast source 1103 will be forwarded to the corresponding upstream interface with the 1104 matching source-specific filter, as well as all the downstream 1105 interfaces with appropriate subscriptions. 1107 A.2. Operations for Local Multicast Subscribers 1109 Multicast listener reports are group-wise aggregated by the MLD 1110 proxy. The aggregated report is issued to the upstream interface 1111 with matching group/channel-specific filter. The choice of the 1112 corresponding upstream interface for aggregated group membership 1113 reports MAY be additionally based on some administrative scoping 1114 rules for scoped multicast group addresses. 1116 In detail, a Multiple Upstream Interface proxy will provide and 1117 maintain a Multicast Subscription Filter Table that maps source- and 1118 group-specific filters to upstream interfaces. The forwarding 1119 decision for an aggregated MLD listener report is based on the first 1120 matching entry from this table, with the understanding that for 1121 IGMPv3/MLDv2 the MLD proxy performs a state decomposition, if needed 1122 (i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the 1123 presence of (*,G) after (S,G) interface entries), and that 1124 (S,*)-filters are always false in the absence of source-specific 1125 signaling, i.e. in IGMPv2/MLDv1 only domains. 1127 In typical deployment scenarios, specific group services (channels) 1128 could be either associated with selected uplinks to remote LMAs, 1129 while a (*,*) default subscription entry (in the last table line) is 1130 bound to a local routing interface, or selected groups are configured 1131 as local services first, while a (*,*) default entry (in the last 1132 table line) points to a remote uplink that provides the general 1133 multicast support. 1135 Appendix B. Implementation 1137 An implementation of the extended IGMP/MLD proxy has been provided 1138 within the MCPROXY project http://mcproxy.realmv6.org/. This open 1139 source software is written in C++ and uses forwarding capabilities of 1140 the Linux kernel. It supports all regular operations according to 1141 [RFC4605], allows for multiple proxy instances on one node, 1142 dynamically changing downstream links, as well as proxy-to-proxy 1143 peerings and multiple upstream links with individual configurations. 1144 The software can be downloaded from Github at https://github.com/ 1145 mcproxy/mcproxy. 1147 Appendix C. Change Log 1149 The following changes have been made from version draft-ietf- 1150 multimob-pmipv6-source-06: 1152 1. Editorial improvements in response to WG Last Call. 1154 2. Clarified mobile source handover treatment for peering proxies in 1155 response to WG Last Call. 1157 3. Updated and extended references. 1159 4. Added pointer to available implementation in Appendix. 1161 The following changes have been made from version draft-ietf- 1162 multimob-pmipv6-source-05: 1164 1. Editorial improvements in response to WG feedback. 1166 2. Updated and extended references. 1168 The following changes have been made from version draft-ietf- 1169 multimob-pmipv6-source-04: 1171 1. Cleaned structure in Section Section 5. 1173 2. Clarified operations of the proxy peering function. 1175 3. Completed Section on Security Considerations. 1177 4. Editorial improvements in response to WG feedback. 1179 5. Updated and extended references. 1181 The following changes have been made from version draft-ietf- 1182 multimob-pmipv6-source-03: 1184 1. Fixed issues in Section Section 4.3 (PIM phase two and three 1185 transition) according to WG feedback. 1187 2. Editorial improvements, resolved nits. 1189 3. Updated references. 1191 The following changes have been made from version draft-ietf- 1192 multimob-pmipv6-source-02: 1194 1. Added clarifications and details as requested by the working 1195 group, resolved nits. 1197 2. Moved Multiple Upstream MLD proxy to Appendix in response to WG 1198 desire. 1200 3. Updated references. 1202 The following changes have been made from version draft-ietf- 1203 multimob-pmipv6-source-01: 1205 1. Added clarifications and details as requested by the working 1206 group, resolved nits. 1208 2. Detailed out operations of Multiple Upstream MLD Proxies. 1210 3. Clarified operations of MLD proxies with peering links. 1212 4. Many editorial improvements. 1214 5. Updated references. 1216 The following changes have been made from version draft-ietf- 1217 multimob-pmipv6-source-00: 1219 1. Direct routing with PIM-SM and PIM-SSM has been added. 1221 2. PMIP synchronization with PIM added for improved handover. 1223 3. Direct routing with BIDIR-PIM has been added. 1225 4. MLD proxy extensions requirements added. 1227 5. Peering of MLD Proxies added. 1229 6. First sketch of multiple upstream proxy added. 1231 7. Editorial improvements. 1233 8. Updated references. 1235 Authors' Addresses 1237 Thomas C. Schmidt (editor) 1238 HAW Hamburg 1239 Berliner Tor 7 1240 Hamburg 20099 1241 Germany 1243 Email: schmidt@informatik.haw-hamburg.de 1244 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 1246 Shuai Gao 1247 Beijing Jiaotong University 1248 Beijing 1249 China 1251 Email: shgao@bjtu.edu.cn 1253 Hong-Ke Zhang 1254 Beijing Jiaotong University 1255 Beijing 1256 China 1258 Email: hkzhang@bjtu.edu.cn 1259 Matthias Waehlisch 1260 link-lab & FU Berlin 1261 Hoenower Str. 35 1262 Berlin 10318 1263 Germany 1265 Email: mw@link-lab.net