idnits 2.17.1 draft-ietf-multimob-pmipv6-source-04.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 (July 13, 2013) is 3939 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2710' is defined on line 929, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 970, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-08) exists of draft-ietf-multimob-pmipv6-ropt-07 Summary: 2 errors (**), 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: Standards Track S. Gao 5 Expires: January 14, 2014 H. Zhang 6 Beijing Jiaotong University 7 M. Waehlisch 8 link-lab & FU Berlin 9 July 13, 2013 11 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains 12 draft-ietf-multimob-pmipv6-source-04 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 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 January 14, 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 . . . . . . . 7 74 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . 8 75 3.2.5. Efficiency of the Distribution System . . . . . . . . 9 76 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . 10 77 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 10 78 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . . . . . 12 82 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 12 83 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . 13 84 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . 14 85 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . 14 86 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . 15 87 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . 15 88 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 16 89 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . 16 90 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 16 91 5. Extended MLD Proxy Function for Optimized Source Mobility in 92 PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 5.1. Peering Function for MLD Proxies . . . . . . . . . . . . 17 94 5.1.1. Operations at the Multicast Sender . . . . . . . . . 18 95 5.1.2. Operations at the Multicast Listener . . . . . . . . 18 96 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 97 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 9.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Appendix A. Multiple Upstream Interface Proxy . . . . . . . . . 21 103 A.1. Operations for Local Multicast Sources . . . . . . . . . 22 104 A.2. Operations for Local Multicast Subscribers . . . . . . . 22 105 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 108 1. Introduction 110 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 111 [RFC6275] by network-based management functions that enable IP 112 mobility for a host without requiring its participation in any 113 mobility-related signaling. Additional network entities called the 114 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 115 responsible for managing IP mobility on behalf of the mobile node 116 (MN). An MN connected to a PMIPv6 domain, which only operates 117 according to the base specifications of [RFC5213], cannot participate 118 in multicast communication, as MAGs will discard group packets. 120 Multicast support for mobile listeners can be enabled within a PMIPv6 121 domain by deploying MLD Proxy functions at Mobile Access Gateways, 122 and multicast routing functions at Local Mobility Anchors [RFC6224]. 123 This base deployment option is the simplest way to PMIPv6 multicast 124 extensions in the sense that it follows the common PMIPv6 traffic 125 model and neither requires new protocol operations nor additional 126 infrastructure entities. Standard software functions need to be 127 activated on PMIPv6 entities, only, at the price of possibly non- 128 optimal multicast routing. 130 Alternate solutions leverage performance optimization by providing 131 multicast routing at the access gateways directly, or by selective 132 route optimization schemes. Such approaches (partially) follow the 133 business model of providing multicast data services in parallel to 134 PMIPv6 unicast routing. 136 Multicast listener support satisfies the needs of receptive use cases 137 such as IPTV or server-centric gaming on mobiles. However, current 138 trends in the Internet enfold towards user-centric, highly 139 interactive group applications like user generated streaming, 140 conferencing, collective mobile sensing, etc. Many of these popular 141 applications create group content at end systems and can largely 142 profit from a direct data transmission to a multicast-enabled 143 network. 145 This document describes the support of mobile multicast senders in 146 Proxy Mobile IPv6 domains subsequently for the base deployment 147 scenario [RFC6224], for direct traffic distribution within an ISP's 148 access network, as well as for selective route optimization schemes. 149 The contribution of this work reflects the source mobility problem as 150 discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic 151 of multicast mobility operations. 153 2. Terminology 155 This document uses the terminology as defined for the mobility 156 protocols [RFC6275], [RFC5213] and [RFC5844], as well as the 157 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 159 3. Base Solution for Source Mobility and PMIPv6 Routing 161 3.1. Overview 163 The reference scenario for multicast deployment in Proxy Mobile IPv6 164 domains is illustrated in Figure 1. MAGs play the role of first-hop 165 access routers that serve multiple MNs on the downstream while 166 running an MLD/IGMP proxy instance for every LMA upstream tunnel. 168 +-------------+ 169 | Multicast | 170 | Listeners | 171 +-------------+ 172 | 173 *** *** *** *** 174 * ** ** ** * 175 * * 176 * Fixed Internet * 177 * * 178 * ** ** ** * 179 *** *** *** *** 180 / \ 181 +----+ +----+ 182 |LMA1| |LMA2| Multicast Anchor 183 +----+ +----+ 184 LMAA1 | | LMAA2 185 | | 186 \\ //\\ 187 \\ // \\ 188 \\ // \\ Unicast Tunnel 189 \\ // \\ 190 \\ // \\ 191 \\ // \\ 192 Proxy-CoA1 || || Proxy-CoA2 193 +----+ +----+ 194 |MAG1| |MAG2| MLD Proxy 195 +----+ +----+ 196 | | | 197 MN-HNP1 | | MN-HNP2 | MN-HNP3 198 | | | 199 MN1 MN2 MN3 201 Multicast Sender + Listener(s) 203 Figure 1: Reference Network for Multicast Deployment in PMIPv6 with 204 Source Mobility 206 An MN in a PMIPv6 domain will decide on multicast data transmission 207 completely independent of its current mobility conditions. It will 208 send packets as initiated by applications, using its source address 209 with Home Network Prefix (HNP) and a multicast destination address 210 chosen by application needs. Multicast packets will arrive at the 211 currently active MAG via one of its downstream local (wireless) 212 links. A multicast unaware MAG would simply discard these packets in 213 the absence of a multicast routing information base (MRIB). 215 An MN can successfully distribute multicast data in PMIPv6, if MLD 216 proxy functions are deployed at the MAG as described in [RFC6224]. 217 In this set-up, the MLD proxy instance serving a mobile multicast 218 source has configured its upstream interface at the tunnel towards 219 MN's corresponding LMA. For each LMA, there will be a separate 220 instance of an MLD proxy. 222 According to the specifications given in [RFC4605], multicast data 223 arriving from a downstream interface of an MLD proxy will be 224 forwarded to the upstream interface and to all but the incoming 225 downstream interfaces that have appropriate forwarding states for 226 this group. Thus multicast streams originating from an MN will 227 arrive at the corresponding LMA and directly at all mobile receivers 228 co-located at the same MAG and MLD Proxy instance. Serving as the 229 designated multicast router or an additional MLD proxy, the LMA 230 forwards data to the fixed Internet, whenever forwarding states are 231 maintained by multicast routing. If the LMA is acting as another MLD 232 proxy, it will forward the multicast data to its upstream interface, 233 and to downstream interfaces with matching subscriptions, 234 accordingly. 236 In case of a handover, the MN (unaware of IP mobility) can continue 237 to send multicast packets as soon as network connectivity is 238 reconfigured. At this time, the MAG has determined the corresponding 239 LMA, and IPv6 unicast address configuration (including PMIPv6 240 bindings) has been completed. Still multicast packets arriving at 241 the MAG are discarded (if not buffered) until the MAG has completed 242 the following steps. 244 1. The MAG has determined that the MN is admissible to multicast 245 services. 247 2. The MAG has added the new downstream link to the MLD proxy 248 instance with up-link to the corresponding LMA. 250 As soon as the MN's uplink is associated with the corresponding MLD 251 proxy instance, multicast packets are forwarded again to the LMA and 252 eventually to receivers within the PMIP domain (see the call flow in 253 Figure 2). In this way, multicast source mobility is transparently 254 enabled in PMIPv6 domains that deploy the base scenario for 255 multicast. 257 MN1 MAG1 MN2 MAG2 LMA 258 | | | | | 259 | | Mcast Data | | | 260 | |<---------------+ | | 261 | | Mcast Data | | | 262 | Join(G) +================================================>| 263 +--------------> | | | | 264 | Mcast Data | | | | 265 |<---------------+ | | | 266 | | | | | 267 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 268 | | | | | 269 | | |--- Rtr Sol -->| | 270 | | |<-- Rtr Adv ---| | 271 | | | | | 272 | | | < MLD Proxy Configuration > | 273 | | | | | 274 | | | (MLD Query) | | 275 | | |<--------------+ | 276 | | | Mcast Data | | 277 | | +-------------->| | 278 | | | | Mcast Data | 279 | | | +===============>| 280 | | | | | 281 | | Mcast Data | | | 282 | |<================================================+ 283 | Mcast Data | | | | 284 |<---------------+ | | | 285 | | | | | 287 Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP 288 These multicast deployment considerations likewise apply for mobile 289 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 290 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 291 IPv4 multicast is handled by an IGMP proxy function at the MAG in an 292 analogous way. 294 Following these deployment steps, multicast traffic distribution 295 transparently inter-operates with PMIPv6. It is worth noting that an 296 MN - while being attached to the same MAG as the mobile source, but 297 associated with a different LMA - cannot receive multicast traffic on 298 a shortest path. Instead, multicast streams flow up to the LMA of 299 the mobile source, are transferred to the LMA of the mobile listener 300 and tunneled downwards to the MAG again (see Section 5 for further 301 optimizations). 303 3.2. Base Solution for Source Mobility: Details 305 A support of multicast source mobility in PMIPv6 requires to deploy 306 general multicast functions at PMIPv6 routers and to define their 307 interaction with the PMIPv6 protocol in the following way. 309 3.2.1. Operations of the Mobile Node 311 A Mobile Node willing to send multicast data will proceed as if 312 attached to the fixed Internet. No specific mobility or other 313 multicast related functionalities are required at the MN. 315 3.2.2. Operations of the Mobile Access Gateway 317 A Mobile Access Gateway is required to have MLD proxy instances 318 deployed, one for each tunnel to an LMA, which serves as its unique 319 upstream link (cf., [RFC6224]). On the arrival of an MN, the MAG 320 decides on the mapping of downstream links to a proxy instance and 321 the upstream link to the LMA based on the regular Binding Update List 322 as maintained by PMIPv6 standard operations. When multicast data is 323 received from the MN, the MAG MUST identify the corresponding proxy 324 instance from the incoming interface and forwards multicast data 325 upstream according to [RFC4605]. 327 The MAG MAY apply special admission control to enable multicast data 328 transition from an MN. It is advisable to take special care that MLD 329 proxy implementations do not redistribute multicast data to 330 downstream interfaces without appropriate subscriptions in place. 332 3.2.3. Operations of the Local Mobility Anchor 334 For any MN, the Local Mobility Anchor acts as the persistent Home 335 Agent and at the same time as the default multicast upstream for the 336 corresponding MAG. It will manage and maintain a multicast 337 forwarding information base for all group traffic arriving from its 338 mobile sources. It SHOULD participate in multicast routing functions 339 that enable traffic redistribution to all adjacent LMAs within the 340 PMIPv6 domain and thereby ensure a continuous receptivity while the 341 source is in motion. 343 3.2.3.1. Local Mobility Anchors Operating PIM 345 Local Mobility Anchors that operate the PIM-SM routing protocol 346 [RFC4601] will require sources to be directly connected for sending 347 PIM registers to the RP. This does not hold in a PMIPv6 domain, as 348 MAGs are routers intermediate to MN and the LMA. In this sense, MNs 349 are multicast sources external to the PIM-SM domain. 351 To mitigate this incompatibility common to all subsidiary MLD proxy 352 domains, the LMA MUST act as a PIM Border Router and activate the 353 Border-bit. In this case, the DirectlyConnected(S) is treated as 354 being TRUE for mobile sources and the PIM-SM forwarding rule "iif == 355 RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 356 interface from MAG to LMA is considered as not part of the PIM-SM 357 component of the LMA (see A.1 of [RFC4601] ). 359 In addition, an LMA serving as PIM Designated Router is connected to 360 MLD proxies via individual IP-tunnel interfaces and will experience 361 changing PIM source states on handover. As the incoming interface 362 connects to a point-to-point link, PIM Assert contention is not 363 active, and incoming interface validation is only performed by RPF 364 checks. Consequently, a PIM DR SHOULD update incoming source states, 365 as soon as RPF inspection succeeds, i.e., after PMIPv6 forwarding 366 state update. Consequently, PIM routers SHOULD be able to manage 367 these state changes, but some implementations are expected to 368 incorrectly refuse packets until the previous state has timed out. 370 Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with 371 respect to source location and does not require special 372 configurations or state management for sources. 374 3.2.4. IPv4 Support 376 An MN in a PMIPv6 domain may use an IPv4 address transparently for 377 communication as specified in [RFC5844]. For this purpose, an LMA 378 can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can 379 provide IPv4 support in its access network. Correspondingly, 380 multicast membership management will be performed by the MN using 381 IGMP. For multicast support on the network side, an IGMP proxy 382 function needs to be deployed at MAGs in exactly the same way as for 383 IPv6. [RFC4605] defines IGMP proxy behaviour in full agreement with 384 IPv6/MLD. Thus IPv4 support can be transparently provided following 385 the obvious deployment analogy. 387 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 388 SHOULD choose multicast signaling according to address configurations 389 on the link, but MAY submit IGMP and MLD queries in parallel, if 390 needed. It should further be noted that the infrastructure cannot 391 identify two data streams as identical when distributed via an IPv4 392 and IPv6 multicast group. Thus duplicate data may be forwarded on a 393 heterogeneous network layer. 395 A particular note is worth giving the scenario of [RFC5845] in which 396 overlapping private address spaces of different operators can be 397 hosted in a PMIP domain by using GRE encapsulation with key 398 identification. This scenario implies that unicast communication in 399 the MAG-LMA tunnel can be individually identified per MN by the GRE 400 keys. This scenario still does not impose any special treatment of 401 multicast communication for the following reasons. 403 Multicast streams from and to MNs arrive at a MAG on point-to-point 404 links (identical to unicast). Multicast data transmission from the 405 MAG to the corresponding LMA is link-local between the routers and 406 routing/forwarding remains independent of any individual MN. So the 407 MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain 408 GRE encapsulation in multicast communication (including MLD queries 409 and reports). Multicast traffic is transmitted as router-to-router 410 forwarding via the MAG-to-LMA tunnels and according to the multicast 411 routing information base (MRIB) of the MAG or the LMA. It remains 412 independent of MN's unicast addresses, while the MAG proxy instance 413 re-distributes multicast data down the point-to-point links 414 (interfaces) according to its local subscription states, independent 415 of IP addresses of the MN. 417 3.2.5. Efficiency of the Distribution System 419 The distribution system of the base solution directly follows PMIPv6 420 routing rules, and organizes multicast domains with respect to LMAs. 421 Thus, no coordination between address spaces or services is required 422 between the different instances, provided their associated LMAs 423 belong to disjoint multicast domains. Routing is optimal for 424 communication between MNs of the same domain, or stationary 425 subscribers. 427 In the following, efficiency-related issues remain. 429 Multicast reception at LMA In the current deployment scenario, the 430 LMA will receive all multicast traffic originating from its 431 associated MNs. There is no mechanism to suppress upstream 432 forwarding in the absence of receivers. 434 MNs on the same MAG using different LMAs For a mobile receiver and a 435 source that use different LMAs, the traffic has to go up to one 436 LMA, cross over to the other LMA, and then be tunneled back to the 437 same MAG, causing redundant flows in the access network and at the 438 MAG. 440 4. Direct Multicast Routing 442 There are deployment scenarios, where multicast services are 443 available throughout the access network independent of the PMIPv6 444 routing system [I-D.ietf-multimob-pmipv6-ropt]. In these cases, the 445 visited networks grant a local content distribution service (in 446 contrast to LMA-based home subscription) with locally optimized 447 traffic flows. It is also possible to deploy a mixed service model 448 of local and LMA-based subscriptions, provided a unique way of 449 service selection is implemented. For example, access routers (MAGs) 450 could decide on service access based on the multicast address G or 451 the SSM channel (S,G) under request (see Appendix A for further 452 discussions). 454 4.1. Overview 456 Direct multicast access can be supported by 458 o native multicast routing provided by one multicast router that is 459 neighboring MLD proxies deployed at MAGs within a flat access 460 network, or via tunnel uplinks, 462 o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM 463 [RFC5015] deployed at the MAGs. 465 *** *** *** *** 466 * ** ** ** * 467 * * 468 * Multicast * 469 +----+ * Infrastructure * +----+ 470 |LMA | * ** ** ** * |LMA | 471 +----+ *** *** *** *** +----+ 472 | // \\ | 473 \\ // \\ PMIP (unicast) | 474 PMIP \\ // \\ // \\ ** *** *** ** // 475 (unicast) \\ // \\ // \\ * ** ** ** // 476 \\ // \\ // \\* Multicast *// 477 || || || || * || Routing || * 478 +----+ +----+ * +----+ +----+ * 479 MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| * 480 +----+ +----+ *+----+ ** ** +----+* 481 | | | | |*** *** ***| 482 | | | | | | 483 MN1 MN2 MN3 MN1 MN2 MN3 485 (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG 487 Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast 488 Access and (b) Dynamic Multicast Routing at MAGs 490 Figure 3 displays the corresponding deployment scenarios, which 491 separate multicast from PMIPv6 unicast routing. It is assumed 492 throughout these scenarios that all MAGs (MLD proxies) are linked to 493 a single multicast routing domain. Notably, this scenario requires 494 coordination of multicast address utilization and service bindings. 496 Multicast traffic distribution can be simplified in these scenarios. 497 A single proxy instance at MAGs with up-link into the multicast 498 domain will serve as a first hop multicast gateway and avoid traffic 499 duplication or detour routing. Multicast routing functions at MAGs 500 will seamlessly embed access gateways within a multicast cloud. 501 However, mobility of the multicast source in this scenario will 502 require some multicast routing protocols to rebuild distribution 503 trees. This can cause significant service disruptions or delays (see 504 [RFC5757] for further aspects). Deployment details are specific to 505 the multicast routing protocol in use, in the following described for 506 common protocols. 508 4.2. MLD Proxies at MAGs 510 In a PMIPv6 domain, single MLD proxy instances can be deployed at 511 each MAG that enable multicast service at the access via an uplink to 512 a multicast service infrastructure (see Figure 3 (a) ). To avoid 513 service disruptions on handovers, the uplinks of all proxies SHOULD 514 be adjacent to the same next-hop multicast router. This can either 515 be achieved by arranging proxies within a flat access network, or by 516 upstream tunnels that terminate at a common multicast router. 518 Multicast data submitted by a mobile source will reach the MLD proxy 519 at the MAG that subsequently forwards flows to the upstream, and all 520 downstream interfaces with appropriate subscriptions. Traversing the 521 upstream will lead traffic into the multicast infrastructure (e.g., 522 to a PIM Designated Router) which will route packets to all local 523 MAGs that have joined the group, as well as further upstream 524 according to protocol procedures and forwarding states. 526 On handover, a mobile source will reattach to a new MAG and can 527 continue to send multicast packets as soon as PMIPv6 unicast 528 configurations have completed. Like at the previous MAG, the new MLD 529 proxy will forward data upstream and downstream to subscribers. 530 Listeners local to the previous MAG will continue to receive group 531 traffic via the local multicast distribution infrastructure following 532 aggregated listener reports of the previous proxy. In general, 533 traffic from the mobile source continues to be transmitted via the 534 same next-hop router using the same source address and thus remains 535 unchanged when seen from the wider multicast infrastructure. 537 4.2.1. Considerations for PIM-SM on the Upstream 539 A mobile source that transmits data via an MLD proxy will not be 540 directly connected to a PIM Designated Router as discussed in 541 Section 3.2.3.1. Countermeasures apply correspondingly. 543 A PIM Designated Router that is connected to MLD proxies via 544 individual IP-tunnel interfaces will experience invalid PIM source 545 states on handover. In some implementations of PIM-SM this could 546 lead to an interim packet loss (see Section Section 3.2.3.1). This 547 problem can be mitigated by aggregating proxies on a lower layer. 549 4.2.2. SSM Considerations 551 Source-specific subscriptions invalidate with routes, whenever the 552 source moves from or to the MAG/proxy of a subscriber. Multicast 553 forwarding states will rebuild with unicast route changes. However, 554 this may lead to noticeable service disruptions for locally 555 subscribed nodes. 557 4.3. PIM-SM at MAGs 559 The full-featured multicast routing protocol PIM-SM MAY be deployed 560 in the access network for providing multicast services in parallel to 561 unicast routes. Throughout this section, it is assumed that the 562 PMIPv6 mobility domain is part of a single PIM-SM multicast routing 563 domain with PIM-SM routing functions present at all MAGs and all 564 LMAs. The PIM routing instance at a MAG SHALL then serve as the 565 Designated Router (DR) for all directly attached Mobile Nodes. For 566 expediting handover operations, it is advisable to position PIM 567 Rendezvous Points (RPs) in the core of the PMIPv6 network domain. 568 However, regular IP routing tables need not be present in a PMIPv6 569 deployment, and additional effort is required to establish reverse 570 path forwarding rules as required by PIM-SM. 572 4.3.1. Routing Information Base for PIM-SM 573 In this scenario, PIM-SM will rely on a Multicast Routing Information 574 Base (MRIB) that is generated independently of the policy-based 575 routing rules of PMIPv6. The granularity of mobility-related routing 576 locators required in PIM depends on the complexity (phases) of its 577 deployment. 579 The following information is needed for all phases of PIM. 581 o All routes to networks and nodes (including RPs) that are not 582 mobile members of the PMIPv6 domain MUST be defined consistently 583 among PIM routers and MUST remain uneffected by node mobility. 584 The setup of these general routes is expected to follow the 585 topology of the operator network and is beyond the scope of this 586 document. 588 The following route entries are required at a PIM-operating MAG when 589 phases two or three of PIM, or PIM-SSM are in operation. 591 o Local routes to the Home Network Prefixes (HNPs) of all MNs 592 associated with their corresponding point-to-point attachments 593 that MUST be included in the local MRIB. 595 o All routes to MNs that are attached to distant MAGs of the PMIPv6 596 domain point towards their corresponding LMAs. These routes MUST 597 be made available in the MRIB of all PIM routers (except for the 598 local MAG of attachment), but MAY be eventually expressed by an 599 appropriate default entry. 601 4.3.2. Operations of PIM in Phase One 603 A new mobile source S will transmit multicast data of group G towards 604 its MAG of attachment. Acting as a PIM DR, the access gateway will 605 unicast-encapsulate the multicast packets and forward the data to the 606 Virtual Interface (VI) with encapsulation target RP(G), a process 607 known as PIM source registering. The RP will decapsulate and 608 natively forward the packets down the RP-based distribution tree 609 towards (mobile and stationary) subscribers. 611 On handover, the point-to-point link connecting the mobile source to 612 the old MAG will go down and all (S,*) flows terminate. In response, 613 the previous DR (MAG) deactivates the data encapsulation channels for 614 the transient source (i.e., all DownstreamJPState(S,*,VI) are set to 615 NoInfo state). After reattaching and completing unicast handover 616 negotiations, the mobile source can continue to transmit multicast 617 packets, while being treated as a new source at its new DR (MAG). 618 Source register encapsulation will be immediately initiated, and 619 (S,G) data continue to flow natively down the (*,G) RP-based tree. 621 Source handover management in PIM phase one admits low complexity and 622 remains transparent to receivers. In addition, the source register 623 tunnel management of PIM is a fast protocol operation and little 624 overhead is induced thereof. In a PMIPv6 deployment, PIM RPs MAY be 625 configured to not initiated (S,G) shortest path tress for mobile 626 sources, and thus remain in phase one of the protocol. The price to 627 pay for such simplified deployment lies in possible routing detours 628 by an overall RP-based packet distribution. 630 4.3.3. Operations of PIM in Phase Two 632 After receiving source register packets, a PIM RP eventually will 633 initiate a source-specific Join for creating a shortest path tree to 634 the (mobile) source S, and issue a source register stop at the native 635 arrival of data from S. For initiating an (S,G) tree, the RP, as well 636 as all intermediate routers, require route entries for the HNP of the 637 MN that - unless the RP coincides with the MAG of S - point towards 638 the corresponding LMA of S. Consequently, the (S,G) tree will proceed 639 from the RP via the (stable) LMA, down the LMA-MAG tunnel to the 640 mobile source. This tree can be of lesser routing efficiency than 641 the PIM source register tunnel established in phase one, but provides 642 the advantage of immediate data delivery to receivers that share a 643 MAG with S. 645 On handover, the mobile source reattaches to a new MAG (DR), and 646 PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new 647 point of attachment. However, in the absence of a corresponding 648 multicast forwarding state, the new DR will treat S as a new source 649 and initiate a source registering of PIM phase one with the RP. In 650 response, the PIM RP will recognize the known source at a new 651 (tunnel) interface immediately responds with a register stop. As the 652 RP had joined the shortest path tree to receive from the source via 653 the LMA, it will see an RPF change when data arrives at a new 654 interface. Implementation-dependent, this can trigger an update of 655 the PIM MRIB and trigger a new PIM Join message. Otherwise, the tree 656 is periodically updated by Joins transmitted towards the new MAG on a 657 path via the LMA. In proceeding this way, a quick recovery of PIM 658 transition from phase one to two will be performed per handover. 660 4.3.4. Operations of PIM in Phase Three 662 In response to an exceeded threshold of packet transmission, DRs of 663 receivers eventually will initiated a source-specific Join for 664 creating a shortest path tree to the (mobile) source S, thereby 665 transitioning PIM into the final short-cut phase three. For all 666 receivers not sharing a MAG with S, this (S,G) tree will range from 667 the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the 668 mobile source. This tree is of higher routing efficiency than 669 established in the previous phase two, but need not outperform the 670 PIM source register tunnel established in phase one. It provides the 671 advantage of immediate data delivery to receivers that share a MAG 672 with S. 674 On handover, the mobile source reattaches to a new MAG (DR), and 675 PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new 676 point of attachment. However, in the absence of a corresponding 677 multicast forwarding state, the new DR will treat S as a new source 678 and initiate a source registering of PIM phase one. A PIM 679 implementation compliant with this change can recover phase three 680 states in the following way. First, the RP recovers to phase two as 681 described in the previous section, and will not forward data arriving 682 via the source register tunnel. Tree mainenance eventually triggered 683 by the RPF change (see Section 4.3.3) will generate proper states for 684 a native forwarding from the new MAG via the LMA. Thereafter, 685 packets arriving at the LMA without source register encapsulation are 686 forwarded natively along the shortest path tree towards receivers. 688 In consequence, the PIM transition from phase one to two and three 689 will be quickly recovered per handover, but still leads to an 690 enhanced signaling load and intermediate packet loss. 692 4.3.5. PIM-SSM Considerations 694 Source-specific Joins of receivers will guide PIM to operate in SSM 695 mode and lead to an immediate establishment of source-specific 696 shortest path trees. Such (S,G) trees will equal the distribution 697 system of PIM's final phase three (see Section 4.3.4). However, on 698 handover and in the absence of RP-based data distribution, SSM data 699 delivery cannot be resumed via source registering as in PIM phase 700 one. Consequently, data packets transmitted after a handover will be 701 discarded at the MAG until regular tree maintenance has re- 702 established the (S,G) forwarding state at the new MAG. 704 4.3.6. Handover Optimizations for PIM 706 Source-specific shortest path trees are constructed in PIM-SM (phase 707 two and three), and in PIM-SSM that follow LMA-MAG tunnels towards a 708 source. As PIM remains unaware of source mobility management, these 709 trees invalidate under handovers with each tunnel re-establishment at 710 a new MAG. Regular tree maintenance of PIM will recover the states, 711 but remains unsynchronized and too slow to seamlessly preserve PIM 712 data dissemination. 714 A method to quickly recover PIM (S,G) trees under handover SHOULD 715 synchronize multicast state maintenance with unicast handover 716 operations and MAY proceed as follows. On handover, an LMA reads all 717 (S,G) Join states from its corresponding tunnel interface and 718 identifies those source addresses S_i that match moving HNPs. After 719 re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join 720 states with the new tunnel endpoint and immediately trigger a state 721 maintenance (PIM Join) message. In proceeding this way, the source- 722 specific PIM states are transferred to the new tunnel end point and 723 propagated to the new MAG in synchrony with unicast handover 724 procedures. 726 4.4. BIDIR-PIM 728 BIDIR-PIM MAY be deployed in the access network for providing 729 multicast services in parallel to unicast routes. Throughout this 730 section, it is assumed that the PMIPv6 mobility domain is part of a 731 single BIDIR-PIM multicast routing domain with BIDIR-PIM routing 732 functions present at all MAGs and all LMAs. The PIM routing instance 733 at a MAG SHALL then serve as the Designated Forwarder (DF) for all 734 directly attached Mobile Nodes. For expediting handover operations, 735 it is advisable to position BIDIR-PIM Rendezvous Point Addresses 736 (RPAs) in the core of the PMIPv6 network domain. As regular IP 737 routing tables need not be present in a PMIPv6 deployment, reverse 738 path forwarding rules as required by BIDIR-PIM need to be 739 established. 741 4.4.1. Routing Information Base for BIDIR-PIM 743 In this scenario, BIDIR-PIM will rely on a Multicast Routing 744 Information Base (MRIB) that is generated independently of the 745 policy-based routing rules of PMIPv6. The following information is 746 needed. 748 o All routes to networks and nodes (including RPAs) that are not 749 mobile members of the PMIPv6 domain MUST be defined consistently 750 among BIDIR-PIM routers and remain uneffected by node mobility. 751 The setup of these general routes is expected to follow the 752 topology of the operator network and is beyond the scope of this 753 document. 755 4.4.2. Operations of BIDIR-PIM 757 BIDIR-PIM will establish spanning trees across its network domain in 758 conformance to its preconfigured RPAs and the routing information 759 provided. Multicast data transmitted by a mobile source will 760 immediately be forwarded by its DF (MAG) onto the spanning group tree 761 without further protocol operations. 763 On handover, the mobile source re-attaches to a new MAG (DF), which 764 completes unicast network configurations. Thereafter, the source can 765 immediately proceed with multicast packet transmission onto the pre- 766 established distribution tree. BIDIR-PIM does neither require 767 protocol signaling nor additional reconfiguration delays to adapt to 768 source mobility and can be considered the protocol of choice for 769 mobile multicast operations in the access. As multicast streams 770 always flow up to the Rendezvous Point Link, some care should be 771 taken to configure RPAs compliant with network capacities. 773 5. Extended MLD Proxy Function for Optimized Source Mobility in PMIPv6 775 A deployment of MLD Proxies (see [RFC4605]) at MAGs has proven a 776 useful and appropriate approach to multicast in PMIPv6, see 777 [RFC6224], [I-D.ietf-multimob-pmipv6-ropt]. However, deploying 778 unmodified standard proxies can go along with significant performance 779 degradation for mobile senders as discussed along the lines of this 780 document. To overcome these deficits, an optimized approach to 781 multicast source mobility based on extended peering functions among 782 proxies is introduced in this section. Prior to presenting the 783 solution, we will sketch the relevant requirements. 785 Solutions that extend MLD Proxies by additional uplinking functions 786 need to comply to the following requirements. 788 Prevention of Routing Loops In the absence of a full-featured 789 routing logic at an MLD Proxy, simple and locally decidable rules 790 need to prevent source traffic from traversing the network in 791 loops as potentially enabled by multiple uplinks. 793 Unique coverage of receivers Listener functions at Proxies require 794 simple, locally decidable rules to initiate a unique delivery of 795 multicast packets to all receivers. 797 Following different techniques, these requirements are met in the 798 following solutions. 800 5.1. Peering Function for MLD Proxies 802 In this section, we define a peering interface for MLD proxies that 803 allows for a direct data exchange of locally attached multicast 804 sources. Such peering interfaces can be configured - as a direct 805 link or a bidirectional tunnel - between any two proxy instances 806 (locally deployed as in [RFC6224] or remotely) and remain as silent 807 virtual links in regular proxy operations. Data on such link is 808 exchanged only in cases, where one peering proxy directly connects on 809 the downstream to a source of multicast traffic, which the other 810 peering proxy actively subscribes to. Operations are defined for ASM 811 and SSM, but provide superior performance in the presence of source- 812 specific signaling (IGMPv3/MLDv2). 814 5.1.1. Operations at the Multicast Sender 816 An MLD Proxy in the perspective of a sender will see peering 817 interfaces as restricted downstream interfaces. It will install and 818 maintain source filters at its peering links that will restrict data 819 transmission to those packets that originate from a locally attached 820 source at the downstream. In detail, a proxy will extract from its 821 configuration the network prefixes attached to its downstream 822 interfaces and MUST implement a source filter base at its peering 823 interfaces that restricts data transmission to IP source addresses 824 from its local prefixes. This filter base Must be updated, if and 825 only if the downstream configuration changes. In this way, a 826 multihop forwarding on peering links is prevented. Multicast packets 827 that arrive from the upstream interface of the proxy are thus only 828 forwarded to regular downstream interfaces with appropriate 829 subscription states. 831 Multicast traffic arriving from a locally attached source will be 832 forwarded to the regular upstream interface and all downstreams with 833 appropriate subscription states (i.e., regular Proxy operations). In 834 addition, local multicast packets are transferred to those peering 835 interfaces with appropriate subscription states. 837 5.1.2. Operations at the Multicast Listener 839 From the listener side, peering interfaces appear as preferred 840 upstream links. Thus an MLD proxy with peering interconnects will 841 offer several interfaces for pulling remote traffic: the regular 842 upstream and the peerings. Traffic arriving from any of the peering 843 links will be mutually disjoint, but normally also available from the 844 upstream. To prevent duplicate traffic from arriving at the listener 845 side, the proxy 847 o MAY delay aggregated reports to the upstream, and 849 o MUST apply appropriate filters to exclude duplicate streams. 851 In detail, it first issues listener reports (in parallel) to its 852 peering links, which only span one (virtual) hop. Whenever the 853 expected traffic (e.g., SSM channels) does not completely arrive from 854 the peerings after a waiting time (default: 10 ms), additional 855 (complementary, in the case of SSM) reports are sent to the standard 856 upstream interface. 858 After the arrival of traffic from peering links, an MLD proxy MUST 859 install source filters at the upstream in the following way. 861 ASM with IGMPv2/MLDv1 In the presence of Any Source Multicast using 862 IGMPv2/MLDv1, only, the proxy cannot signal source filtering to 863 its upstream. Correspondingly, it applies (S,*) ingress filters 864 at its upstream interface for all sources S seen in traffic of the 865 peering links. It is noteworthy that unwanted traffic is still 866 replicated to the proxy via the access network. 868 ASM with IGMPv3/MLDv2 In the presence of source-specific signaling 869 (IGMPv3/MLDv2), the upstream interface is set to (S,*) exclude 870 mode for all sources S seen in traffic of the peering links. The 871 corresponding source-specific signaling will prevent duplicate 872 traffic forwarding throughout the access network. 874 SSM In the presence of Source Specific Multicast, the proxy will 875 subscribe on its uplink interface to those (S,G) channels, only, 876 that do not arrive via the peering links. 878 In proceeding this way, multicast group data arrive from peering 879 interfaces first, while only peer-wise unavailable traffic is 880 retrieved from the regular upstream interface. 882 6. IANA Considerations 884 TODO. 886 Note to RFC Editor: this section may be removed on publication as an 887 RFC. 889 7. Security Considerations 891 TODO 893 Consequently, no new threats are introduced by this document in 894 addition to those identified as security concerns of [RFC3810], 895 [RFC4605], [RFC5213], and [RFC5844]. 897 However, particular attention should be paid to implications of 898 combining multicast and mobility management at network entities. As 899 this specification allows mobile nodes to initiate the creation of 900 multicast forwarding states at MAGs and LMAs while changing 901 attachments, threats of resource exhaustion at PMIP routers and 902 access networks arrive from rapid state changes, as well as from high 903 volume data streams routed into access networks of limited 904 capacities. In addition to proper authorization checks of MNs, rate 905 controls at replicators MAY be required to protect the agents and the 906 downstream networks. In particular, MLD proxy implementations at 907 MAGs SHOULD carefully procure for automatic multicast state 908 extinction on the departure of MNs, as mobile multicast listeners in 909 the PMIPv6 domain will not actively terminate group membership prior 910 to departure. 912 8. Acknowledgements 914 The authors would like to thank (in alphabetical order) Luis M. 915 Contreras, Muhamma Omer Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, 916 Jouni Korhonen, He-Wu Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian 917 Wu, Zhi-Wei Yan for advice, help and reviews of the document. 918 Funding by the German Federal Ministry of Education and Research 919 within the G-LAB Initiative (projects HAMcast, Mindstone and SAFEST) 920 is gratefully acknowledged. 922 9. References 924 9.1. Normative References 926 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, March 1997. 929 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 930 Listener Discovery (MLD) for IPv6", RFC 2710, October 931 1999. 933 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 934 Thyagarajan, "Internet Group Management Protocol, Version 935 3", RFC 3376, October 2002. 937 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 938 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 940 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 941 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 942 Protocol Specification (Revised)", RFC 4601, August 2006. 944 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 945 "Internet Group Management Protocol (IGMP) / Multicast 946 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 947 /MLD Proxying")", RFC 4605, August 2006. 949 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 950 "Bidirectional Protocol Independent Multicast (BIDIR- 951 PIM)", RFC 5015, October 2007. 953 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 954 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 956 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 957 Mobile IPv6", RFC 5844, May 2010. 959 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 960 in IPv6", RFC 6275, July 2011. 962 9.2. Informative References 964 [I-D.ietf-multimob-pmipv6-ropt] 965 Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. 966 Kim, "Multicast Mobility Routing Optimizations for Proxy 967 Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-07 (work in 968 progress), July 2013. 970 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 971 2", RFC 2236, November 1997. 973 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 974 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 975 and Brief Survey", RFC 5757, February 2010. 977 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 978 "Generic Routing Encapsulation (GRE) Key Option for Proxy 979 Mobile IPv6", RFC 5845, June 2010. 981 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 982 Deployment for Multicast Listener Support in Proxy Mobile 983 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 985 Appendix A. Multiple Upstream Interface Proxy 987 In this section, we document upstream extensions for an MLD proxy 988 that were originally developed during the work on this document. 989 Multiple proxy instances deployed at a single MAG (see Section 3) can 990 be avoided by adding multiple upstream interfaces to a single MLD 991 Proxy. In a typical PMIPv6 deployment, each upstream of a single 992 proxy instance can interconnect to one of the LMAs. With such 993 ambiguous upstream options, appropriate forwarding rules MUST be 994 supplied to 996 o unambiguously guide traffic forwarding from directly attached 997 mobile sources, and 999 o lead listener reports to initiating unique traffic subscriptions. 1001 This can be achieved by a complete set of source- and group-specific 1002 filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. 1003 These filters MAY be derived in parts from PMIPv6 routing policies, 1004 and can include a default behavior (e.g., (*,*)). 1006 A.1. Operations for Local Multicast Sources 1008 Packets from a locally attached multicast source will be forwarded to 1009 all downstream interfaces with appropriate subscriptions, as well as 1010 up the interface with the matching source-specific filter. 1012 Typically, the upstream interface for a mobile multicast source is 1013 chosen based on the policy routing (e.g., the MAG-LMA tunnel 1014 interface for LMA-based routing or the interface towards the 1015 multicast router for direct routing), but alternate configuriations 1016 MAY be applied. Packets from a locally attached multicast source 1017 will be forwarded to the corresponding upstream interface with the 1018 matching source-specific filter, as well as all the downstream 1019 interfaces with appropriate subscriptions. 1021 A.2. Operations for Local Multicast Subscribers 1023 Multicast listener reports are group-wise aggregated by the MLD 1024 proxy. The aggregated report is issued to the upstream interface 1025 with matching group/channel-specific filter. The choice of the 1026 corresponding upstream interface for aggregated group membership 1027 reports MAY be additionally based on some administrative scoping 1028 rules for scoped multicast group addresses. 1030 In detail, a Multiple Upstream Interface Proxy will provide and 1031 maintain a Multicast Subscription Filter Table that maps source- and 1032 group-specific filters to upstream interfaces. The forwarding 1033 decision for an aggregated MLD listener report is based on the first 1034 matching entry from this table, with the understanding that for 1035 IGMPv3/MLDv2 the MLD Proxy performs a state decomposition , if needed 1036 (i.e., a (*,G) subscription is split into (S,G) and (* \ S,G) in the 1037 presence of (*,G) after (S,G) interface entries), and that 1038 (S,*)-filters are always false in the absence of source-specific 1039 signaling, i.e. in IGMPv2/MLDv1 only domains. 1041 In typical deployment scenarios, specific group services (channels) 1042 could be either associated with selected uplinks to remote LMAs, 1043 while a (*,*) default subscription entry (in the last table line) is 1044 bound to a local routing interface, or selected groups are configured 1045 as local services first, while a (*,*) default entry (in the last 1046 table line) points to a remote uplink that provides the general 1047 multicast support. 1049 Appendix B. Change Log 1051 The following changes have been made from version draft-ietf- 1052 multimob-pmipv6-source-03: 1054 1. Fixed issues in Section Section 4.3 (PIM phase two and three 1055 transistion) according to WG feedback. 1057 2. Editorial improvements, resolved nits. 1059 3. Updated references. 1061 The following changes have been made from version draft-ietf- 1062 multimob-pmipv6-source-02: 1064 1. Added clarifications and details as requested by the working 1065 group, resolved nits. 1067 2. Moved Multiple Upstream MLD Proxy to Appendix in response to WG 1068 desire. 1070 3. Updated references. 1072 The following changes have been made from version draft-ietf- 1073 multimob-pmipv6-source-01: 1075 1. Added clarifications and details as requested by the working 1076 group, resolved nits. 1078 2. Detailed out operations of Multiple Upstream MLD Proxies. 1080 3. Clarified operations of MLD proxies with peering links. 1082 4. Many editorial improvements. 1084 5. Updated references. 1086 The following changes have been made from version draft-ietf- 1087 multimob-pmipv6-source-00: 1089 1. Direct routing with PIM-SM and PIM-SSM has been added. 1091 2. PMIP synchronization with PIM added for improved handover. 1093 3. Direct routing with BIDIR-PIM has been added. 1095 4. MLD Proxy extensions requirements added. 1097 5. Peering of MLD Proxies added. 1099 6. First sketch of multiple upstream proxy added. 1101 7. Editorial improvements. 1103 8. Updated references. 1105 Authors' Addresses 1107 Thomas C. Schmidt (editor) 1108 HAW Hamburg 1109 Berliner Tor 7 1110 Hamburg 20099 1111 Germany 1113 Email: schmidt@informatik.haw-hamburg.de 1114 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 1116 Shuai Gao 1117 Beijing Jiaotong University 1118 Beijing 1119 China 1121 Email: shgao@bjtu.edu.cn 1123 Hong-Ke Zhang 1124 Beijing Jiaotong University 1125 Beijing 1126 China 1128 Email: hkzhang@bjtu.edu.cn 1130 Matthias Waehlisch 1131 link-lab & FU Berlin 1132 Hoenower Str. 35 1133 Berlin 10318 1134 Germany 1136 Email: mw@link-lab.net