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