idnits 2.17.1 draft-ietf-multimob-pmipv6-source-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 16, 2012) is 4295 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 922, but no explicit reference was found in the text == Unused Reference: 'RFC2236' is defined on line 963, 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-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group T C. Schmidt, Ed. 3 Internet-Draft HAW Hamburg 4 Intended status: Standards Track S. Gao 5 Expires: January 17, 2013 H. Zhang 6 Beijing Jiaotong University 7 M. Waehlisch 8 link-lab & FU Berlin 9 July 16, 2012 11 Mobile Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) Domains 12 draft-ietf-multimob-pmipv6-source-01 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 extended 23 MLD Proxy functions are presented. 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 17, 2013. 49 Copyright Notice 51 Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. Base Solution for Source Mobility and PMIPv6 Routing . . . . . 5 69 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.2. Base Solution for Source Mobility: Details . . . . . . . . 9 71 3.2.1. Operations of the Mobile Node . . . . . . . . . . . . 9 72 3.2.2. Operations of the Mobile Access Gateway . . . . . . . 9 73 3.2.3. Operations of the Local Mobility Anchor . . . . . . . 9 74 3.2.4. IPv4 Support . . . . . . . . . . . . . . . . . . . . . 10 75 3.2.5. Efficiency of the Distribution System . . . . . . . . 11 76 4. Direct Multicast Routing . . . . . . . . . . . . . . . . . . . 11 77 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.2. MLD Proxies at MAGs . . . . . . . . . . . . . . . . . . . 12 79 4.2.1. Considerations for PIM-SM on the Upstream . . . . . . 13 80 4.2.2. SSM Considerations . . . . . . . . . . . . . . . . . . 13 81 4.3. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4.3.1. Routing Information Base for PIM-SM . . . . . . . . . 14 83 4.3.2. Operations of PIM in Phase One . . . . . . . . . . . . 14 84 4.3.3. Operations of PIM in Phase Two . . . . . . . . . . . . 15 85 4.3.4. Operations of PIM in Phase Three . . . . . . . . . . . 16 86 4.3.5. PIM-SSM Considerations . . . . . . . . . . . . . . . . 16 87 4.3.6. Handover Optimizations for PIM . . . . . . . . . . . . 16 88 4.4. BIDIR-PIM . . . . . . . . . . . . . . . . . . . . . . . . 17 89 4.4.1. Routing Information Base for BIDIR-PIM . . . . . . . . 17 90 4.4.2. Operations of BIDIR-PIM . . . . . . . . . . . . . . . 17 91 5. Extended MLD Proxy Functions for Optimized Source Mobility 92 in PMIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 5.1. Multiple Upstream Interface Proxy . . . . . . . . . . . . 18 94 5.1.1. Operations for Local Multicast Sources . . . . . . . . 19 95 5.1.2. Operations for Local Multicast Subscribers . . . . . . 19 96 5.2. Peering Function for MLD Proxies . . . . . . . . . . . . . 19 97 5.2.1. Operations at the Multicast Sender . . . . . . . . . . 19 98 5.2.2. Operations at the Multicast Listener . . . . . . . . . 20 99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 101 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 102 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 103 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 104 9.2. Informative References . . . . . . . . . . . . . . . . . . 22 105 Appendix A. Evaluation of Traffic Flows . . . . . . . . . . . . . 23 106 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 109 1. Introduction 111 Proxy Mobile IPv6 (PMIPv6) [RFC5213] extends Mobile IPv6 (MIPv6) 112 [RFC6275] by network-based management functions that enable IP 113 mobility for a host without requiring its participation in any 114 mobility-related signaling. Additional network entities called the 115 Local Mobility Anchor (LMA), and Mobile Access Gateways (MAGs), are 116 responsible for managing IP mobility on behalf of the mobile node 117 (MN). An MN connected to a PMIPv6 domain, which only operates 118 according to the base specifications of [RFC5213], cannot participate 119 in multicast communication, as MAGs will discard group packets. 121 Multicast support for mobile listeners can be enabled within a PMIPv6 122 domain by deploying MLD Proxy functions at Mobile Access Gateways, 123 and multicast routing functions at Local Mobility Anchors [RFC6224]. 124 This base deployment option is the simplest way to PMIPv6 multicast 125 extensions in the sense that it follows the common PMIPv6 traffic 126 model and neither requires new protocol operations nor additional 127 infrastructure entities. Standard software functions need to be 128 activated on PMIPv6 entities, only, at the price of possibly non- 129 optimal multicast routing. 131 Alternate solutions leverage performance optimization by providing 132 multicast routing at the access gateways directly, or by selective 133 route optimization schemes. Such approaches (partially) follow the 134 business model of providing multicast data services in parallel to 135 PMIPv6 unicast routing. 137 Multicast listener support satisfies the needs of receptive use cases 138 such as IPTV or sever-centric gaming on mobiles. However, current 139 trends in the Internet enfold towards user-centric, highly 140 interactive group applications like user generated streaming, 141 conferencing, collective mobile sensing, etc. Many of these popular 142 applications create group content at end systems and can largely 143 profit from a direct data transmission to a multicast-enabled 144 network. 146 This document describes the support of mobile multicast senders in 147 Proxy Mobile IPv6 domains subsequently for the base deployment 148 scenario [RFC6224], for direct traffic distribution within an ISP's 149 access network, as well as for selective route optimization schemes. 150 The contribution of this work reflects the source mobility problem as 151 discussed in [RFC5757]. Mobile Nodes in this setting remain agnostic 152 of multicast mobility operations. 154 2. Terminology 156 This document uses the terminology as defined for the mobility 157 protocols [RFC6275], [RFC5213] and [RFC5844], as well as the 158 multicast edge related protocols [RFC3376], [RFC3810] and [RFC4605]. 160 3. Base Solution for Source Mobility and PMIPv6 Routing 162 3.1. Overview 164 The reference scenario for multicast deployment in Proxy Mobile IPv6 165 domains is illustrated in Figure 1. MAGs play the role of first-hop 166 access routers that serve multiple MNs on the downstream while 167 running an MLD/IGMP proxy instance for every LMA upstream tunnel. 169 +-------------+ 170 | Multicast | 171 | Listeners | 172 +-------------+ 173 | 174 *** *** *** *** 175 * ** ** ** * 176 * * 177 * Fixed Internet * 178 * * 179 * ** ** ** * 180 *** *** *** *** 181 / \ 182 +----+ +----+ 183 |LMA1| |LMA2| Multicast Anchor 184 +----+ +----+ 185 LMAA1 | | LMAA2 186 | | 187 \\ //\\ 188 \\ // \\ 189 \\ // \\ Unicast Tunnel 190 \\ // \\ 191 \\ // \\ 192 \\ // \\ 193 Proxy-CoA1 || || Proxy-CoA2 194 +----+ +----+ 195 |MAG1| |MAG2| MLD Proxy 196 +----+ +----+ 197 | | | 198 MN-HNP1 | | MN-HNP2 | MN-HNP3 199 | | | 200 MN1 MN2 MN3 202 Multicast Sender + Listener(s) 204 Figure 1: Reference Network for Multicast Deployment in PMIPv6 with 205 Source Mobility 207 An MN in a PMIPv6 domain will decide on multicast data transmission 208 completely independent of its current mobility conditions. It will 209 send packets as initiated by applications, using its source address 210 with Home Network Prefix (HNP) and a multicast destination address 211 chosen by application needs. Multicast packets will arrive at the 212 currently active MAG via one of its downstream local (wireless) 213 links. A multicast unaware MAG would simply discard these packets in 214 the absence of a multicast routing information base (MRIB). 216 An MN can successfully distribute multicast data in PMIPv6, if MLD 217 proxy functions are deployed at the MAG as described in [RFC6224]. 218 In this set-up, the MLD proxy instance serving a mobile multicast 219 source has configured its upstream interface at the tunnel towards 220 MN's corresponding LMA. For each LMA, there will be a separate 221 instance of an MLD proxy. 223 According to the specifications given in [RFC4605], multicast data 224 arriving from a downstream interface of an MLD proxy will be 225 forwarded to the upstream interface and to all but the incoming 226 downstream interfaces that have appropriate forwarding states for 227 this group. Thus multicast streams originating from an MN will 228 arrive at the corresponding LMA and directly at all mobile receivers 229 co-located at the same MAG and MLD Proxy instance. Serving as the 230 designated multicast router or an additional MLD proxy, the LMA 231 forwards data to the fixed Internet, whenever forwarding states are 232 maintained by multicast routing. If the LMA is acting as another MLD 233 proxy, it will forward the multicast data to its upstream interface, 234 and to downstream interfaces with matching subscriptions, 235 accordingly. 237 In case of a handover, the MN (unaware of IP mobility) can continue 238 to send multicast packets as soon as network connectivity is 239 reconfigured. At this time, the MAG has determined the corresponding 240 LMA, and IPv6 unicast address configuration (including PMIPv6 241 bindings) has been performed . Still multicast packets arriving at 242 the MAG are discarded (if not buffered) until the MAG has completed 243 the following steps. 245 1. The MAG has determined that the MN is admissible to multicast 246 services. 248 2. The MAG has added the new downstream link to the MLD proxy 249 instance with up-link to the corresponding LMA. 251 As soon as the MN's uplink is associated with the corresponding MLD 252 proxy instance, multicast packets are forwarded again to the LMA and 253 eventually to receivers within the PMIP domain (see the call flow in 254 Figure 2). In this way, multicast source mobility is transparently 255 enabled in PMIPv6 domains that deploy the base scenario for 256 multicast. 258 MN1 MAG1 MN2 MAG2 LMA 259 | | | | | 260 | | Mcast Data | | | 261 | |<---------------+ | | 262 | | Mcast Data | | | 263 | Join(G) +================================================>| 264 +--------------> | | | | 265 | Mcast Data | | | | 266 |<---------------+ | | | 267 | | | | | 268 | < Movement of MN 2 to MAG2 & PMIP Binding Update > | 269 | | | | | 270 | | |--- Rtr Sol -->| | 271 | | |<-- Rtr Adv ---| | 272 | | | | | 273 | | | < MLD Proxy Configuration > | 274 | | | | | 275 | | | MLD Query | | 276 | | |<--------------+ | 277 | | | Mcast Data | | 278 | | +-------------->| | 279 | | | | Mcast Data | 280 | | | +===============>| 281 | | | | | 282 | | Mcast Data | | | 283 | |<================================================+ 284 | Mcast Data | | | | 285 |<---------------+ | | | 286 | | | | | 288 Figure 2: Call Flow for Group Communication in Multicast-enabled PMIP 290 These multicast deployment considerations likewise apply for mobile 291 nodes that operate with their IPv4 stack enabled in a PMIPv6 domain. 292 PMIPv6 can provide IPv4 home address mobility support [RFC5844]. 293 IPv4 multicast is handled by an IGMP proxy function at the MAG in an 294 analogous way. 296 Following these deployment steps, multicast traffic distribution 297 transparently inter-operates with PMIPv6. It is worth noting that an 298 MN - while being attached to the same MAG as the mobile source, but 299 associated with a different LMA - cannot receive multicast traffic on 300 a shortest path. Instead, multicast streams flow up to the LMA of 301 the mobile source, are transferred to the LMA of the mobile listener 302 and tunneled downwards to the MAG again (see Appendix A for further 303 considerations). 305 3.2. Base Solution for Source Mobility: Details 307 Incorporating multicast source mobility in PMIPv6 requires to deploy 308 general multicast functions at PMIPv6 routers and to define their 309 interaction with the PMIPv6 protocol in the following way. 311 3.2.1. Operations of the Mobile Node 313 A Mobile Node willing to send multicast data will proceed as if 314 attached to the fixed Internet. No specific mobility or other 315 multicast related functionalities are required at the MN. 317 3.2.2. Operations of the Mobile Access Gateway 319 A Mobile Access Gateway is required to have MLD proxy instances 320 deployed, one for each tunnel to an LMA, which serves as its unique 321 upstream link (cf., [RFC6224]). On the arrival of an MN, the MAG 322 decides on the mapping of downstream links to a proxy instance and 323 the upstream link to the LMA based on the regular Binding Update List 324 as maintained by PMIPv6 standard operations. When multicast data is 325 received from the MN, the MAG MUST identify the corresponding proxy 326 instance from the incoming interface and forwards multicast data 327 upstream according to [RFC4605]. 329 The MAG MAY apply special admission control to enable multicast data 330 transition from an MN. It is advisable to take special care that MLD 331 proxy implementations do not redistribute multicast data to 332 downstream interfaces without appropriate subscriptions in place. 334 3.2.3. Operations of the Local Mobility Anchor 336 For any MN, the Local Mobility Anchor acts as the persistent Home 337 Agent and at the same time as the default multicast upstream for the 338 corresponding MAG. It will manage and maintain a multicast 339 forwarding information base for all group traffic arriving from its 340 mobile sources. It SHOULD participate in multicast routing functions 341 that enable traffic redistribution to all adjacent LMAs within the 342 PMIPv6 domain and thereby ensure a continuous receptivity while the 343 source is in motion. 345 3.2.3.1. Local Mobility Anchors Operating PIM 347 Local Mobility Anchors that operate the PIM-SM routing protocol 348 [RFC4601] will require sources to be directly connected for sending 349 PIM registers to the RP. This does not hold in a PMIPv6 domain, as 350 MAGs are routers intermediate to MN and the LMA. In this sense, MNs 351 are multicast sources external to the PIM-SM domain. 353 To mitigate this incompatibility common to all subsidiary MLD proxy 354 domains, the LMA should act as a PIM Border Router and activate the 355 Border-bit. In this case, the DirectlyConnected(S) is treated as 356 being TRUE for mobile sources and the PIM-SM forwarding rule "iif == 357 RPF_interface(S)" is relaxed to be TRUE, as the incoming tunnel 358 interface from MAG to LMA is considered as not part of the PIM-SM 359 component of the LMA (see A.1 of [RFC4601] ). 361 Notably, running BIDIR PIM [RFC5015] on LMAs remains robust with 362 respect to source location and does not require a special 363 configuration. 365 3.2.4. IPv4 Support 367 An MN in a PMIPv6 domain may use an IPv4 address transparently for 368 communication as specified in [RFC5844]. For this purpose, an LMA 369 can register an IPv4-Proxy-CoA in its Binding Cache and the MAG can 370 provide IPv4 support in its access network. Correspondingly, 371 multicast membership management will be performed by the MN using 372 IGMP. For multicast support on the network side, an IGMP proxy 373 function needs to be deployed at MAGs in exactly the same way as for 374 IPv6. [RFC4605] defines IGMP proxy behaviour in full agreement with 375 IPv6/MLD. Thus IPv4 support can be transparently provided following 376 the obvious deployment analogy. 378 For a dual-stack IPv4/IPv6 access network, the MAG proxy instances 379 SHOULD choose multicast signaling according to address configurations 380 on the link, but MAY submit IGMP and MLD queries in parallel, if 381 needed. It should further be noted that the infrastructure cannot 382 identify two data streams as identical when distributed via an IPv4 383 and IPv6 multicast group. Thus duplicate data may be forwarded on a 384 heterogeneous network layer. 386 A particular note is worth giving the scenario of [RFC5845] in which 387 overlapping private address spaces of different operators can be 388 hosted in a PMIP domain by using GRE encapsulation with key 389 identification. This scenario implies that unicast communication in 390 the MAG-LMA tunnel can be individually identified per MN by the GRE 391 keys. This scenario still does not impose any special treatment of 392 multicast communication for the following reasons. 394 Multicast streams from and to MNs arrive at a MAG on point-to-point 395 links (identical to unicast). Multicast data transmission from the 396 MAG to the corresponding LMA is link-local between the routers and 397 routing/forwarding remains independent of any individual MN. So the 398 MAG-proxy and the LMA SHOULD NOT use GRE key identifiers, but plain 399 GRE encapsulation in multicast communication (including MLD queries 400 and reports). Multicast traffic sent upstream and downstream of MAG- 401 to-LMA tunnels proceeds as router-to-router forwarding according to 402 the multicast routing information base (MRIB) of the MAG or LMA and 403 independent of MN's unicast addresses, while the MAG proxy instance 404 re-distributes multicast data down the point-to-point links 405 (interfaces) according to its own MRIB, independent of MN's IP 406 addresses. 408 3.2.5. Efficiency of the Distribution System 410 In the following efficiency-related issues are enumerated. 412 Multicast reception at LMA In the current deployment scenario, the 413 LMA will receive all multicast traffic originating from its 414 associated MNs. There is no mechanism to suppress upstream 415 forwarding in the absence of receivers. 417 MNs on the same MAG using different LMAs For a mobile receiver and a 418 source that use different LMAs, the traffic has to go up to one 419 LMA, cross over to the other LMA, and then be tunneled back to the 420 same MAG, causing redundant flows in the access network and at the 421 MAG. 423 4. Direct Multicast Routing 425 There are deployment scenarios, where multicast services are 426 available throughout the access network independent of the PMIPv6 427 routing system [I-D.ietf-multimob-pmipv6-ropt]. In these cases, the 428 visited networks grant a local content distribution service (in 429 contrast to LMA-based home subscription) with locally optimized 430 traffic flows. It is also possible to deploy a mixed service model 431 of local and LMA-based subscriptions, provided a unique way of 432 service selection is implemented. For example, access routers (MAGs) 433 could decide on service access based on the multicast address G or 434 the SSM channel (S,G) under request (see Section 5 for a further 435 discussion). 437 4.1. Overview 439 Direct multicast access can be supported by 441 o native multicast routing provided by one multicast router that is 442 neighboring MLD proxies deployed at MAGs within a flat access 443 network, or via tunnel uplinks, 445 o a multicast routing protocol such as PIM-SM [RFC4601] or BIDIR-PIM 446 [RFC5015] deployed at the MAGs. 448 *** *** *** *** 449 * ** ** ** * 450 * * 451 * Multicast * 452 +----+ * Infrastructure * +----+ 453 |LMA | * ** ** ** * |LMA | 454 +----+ *** *** *** *** +----+ 455 | // \\ | 456 \\ // \\ PMIP (unicast) | 457 PMIP \\ // \\ // \\ ** *** *** ** // 458 (unicast) \\ // \\ // \\ * ** ** ** // 459 \\ // \\ // \\* Multicast *// 460 || || || || * || Routing || * 461 +----+ +----+ * +----+ +----+ * 462 MLD Proxy |MAG1| |MAG2| * |MAG1| |MAG2| * 463 +----+ +----+ *+----+ ** ** +----+* 464 | | | | |*** *** ***| 465 | | | | | | 466 MN1 MN2 MN3 MN1 MN2 MN3 468 (a) Multicast Access at Proxy Uplink (b) Multicast Routing at MAG 470 Figure 3: Reference Networks for (a) Proxy-assisted Direct Multicast 471 Access and (b) Dynamic Multicast Routing at MAGs 473 Figure 3 displays the corresponding deployment scenarios, which 474 separate multicast from PMIPv6 unicast routing. It is assumed 475 throughout these scenarios that all MAGs (MLD proxies) are linked to 476 a single multicast routing domain. 478 Multicast traffic distribution can be simplified in these scenarios. 479 A single proxy instance at MAGs with up-link into the multicast 480 domain will serve as a first hop multicast gateway and avoid traffic 481 duplication or detour routing. Multicast routing functions at MAGs 482 will seamlessly embed access gateways within a multicast cloud. 483 However, mobility of the multicast source in this scenario will 484 require some multicast routing protocols to rebuild distribution 485 trees. This can cause significant service disruptions or delays (see 486 [RFC5757] for further aspects). Deployment details are specific to 487 the multicast routing protocol in use, in the following described for 488 common protocols. 490 4.2. MLD Proxies at MAGs 492 In a PMIPv6 domain, single MLD proxy instances can be deployed at 493 each MAG that enable multicast service at the access via an uplink to 494 a multicast service infrastructure (see Figure 3 (a) ). To avoid 495 service disruptions on handovers, the uplinks of all proxies SHOULD 496 be adjacent to the same next-hop multicast router. This can either 497 be achieved by arranging proxies within a flat access network, or by 498 upstream tunnels that terminate at a common multicast router. 500 Multicast data submitted by a mobile source will reach the MLD proxy 501 at the MAG that subsequently forwards flows to the upstream, and all 502 downstream interfaces with appropriate subscriptions. Traversing the 503 upstream will lead traffic into the multicast infrastructure (e.g., 504 to a PIM Designated Router) which will route packets to all local 505 MAGs that have joined the group, as well as further upstream 506 according to protocol procedures and forwarding states. 508 On handover, a mobile source will reattach at a new MAG and can 509 continue to send multicast packets as soon as PMIPv6 unicast 510 configurations have completed. Like at the previous MAG, the new MLD 511 proxy will forward data upstream and downstream to subscribers. 512 Listeners local to the previous MAG will continue to receive group 513 traffic via the local multicast distribution infrastructure following 514 aggregated listener reports of the previous proxy. In general, 515 traffic from the mobile source continues to be transmitted via the 516 same next-hop router using the same source address and thus remains 517 unchanged when seen from the wider multicast infrastructure. 519 4.2.1. Considerations for PIM-SM on the Upstream 521 A mobile source that transmits data via an MLD proxy will not be 522 directly connected to a PIM Designated Router as discussed in 523 Section 3.2.3.1. Countermeasures apply correspondingly. 525 A PIM Designated Router that is connected to MLD proxies via 526 individual IP-tunnel interfaces will experience invalid PIM source 527 states on handover. This problem can be mitigated by aggregating 528 proxies on a lower layer. 530 4.2.2. SSM Considerations 532 Source-specific subscriptions invalidate with routes, whenever the 533 source moves from or to the MAG/proxy of a subscriber. Multicast 534 forwarding states will rebuild with unicast route changes. However, 535 this may lead to noticeable service disruptions for locally 536 subscribed nodes. 538 4.3. PIM-SM 540 The full-featured multicast routing protocol PIM-SM MAY be deployed 541 in the access network for providing multicast services in parallel to 542 unicast routes. Throughout this section, it is assumed that the 543 PMIPv6 mobility domain is part of a single PIM-SM multicast routing 544 domain with PIM-SM routing functions present at all MAGs and all 545 LMAs. The PIM routing instance at a MAG SHALL then serve as the 546 Designated Router (DR) for all directly attached Mobile Nodes. For 547 expediting handover operations, it is advisable to position PIM 548 Rendezvous Points (RPs) in the core of the PMIPv6 network domain. 549 However, regular IP routing tables need not be present in a PMIPv6 550 deployment, and additional effort is required to establish reverse 551 path forwarding rules as required by PIM-SM. 553 4.3.1. Routing Information Base for PIM-SM 555 In this scenario, PIM-SM will rely on a Multicast Routing Information 556 Base (MRIB) that is generated independently of the policy-based 557 routing rules of PMIPv6. The granularity of mobility-related routing 558 locators required in PIM depends on the complexity (phases) of its 559 deployment. 561 The following information is needed for all phases of PIM. 563 o All routes to networks and nodes (including RPs) that are not 564 mobile members of the PMIPv6 domain MUST be defined consistently 565 among PIM routers and remain uneffected by node mobility. The 566 setup of these general routes is expected to follow the topology 567 of the operator network and is beyond the scope of this document. 569 The following route entries are required at a PIM-operating MAG when 570 phases two or three of PIM, or PIM-SSM are in operation. 572 o All MNs that are directly attached to the MAG generate local 573 routes to their Home Network Prefixes (HNPs) at the corresponding 574 point-to-point attachments that MUST be included into the local 575 MRIB. 577 o All routes to MNs that are attached to distant MAGs of the PMIPv6 578 domain point towards their corresponding LMAs. These routes MUST 579 be made available in the MRIB of all PIM routers (except for the 580 local MAG of attachment), but MAY be eventually expressed by an 581 appropriate default entry. 583 4.3.2. Operations of PIM in Phase One 585 A new mobile source S will transmit multicast data of group G towards 586 its MAG of attachment. Acting as a PIM DR, the access gateway will 587 unicast-encapsulate the multicast packets and forward the data to the 588 Virtual Interface (VI) with encapsulation target RP(G), a process 589 known as PIM source registering. The RP will decapsulate and 590 natively forward the packets down the RP-based distribution tree 591 towards (mobile and stationary) subscribers. 593 On handover, the point-to-point link connecting the mobile source to 594 the old MAG will go down and all (S,*) flows terminate. In response, 595 the previous DR (MAG) deactivates the data encapsulation channels for 596 the transient source (e.g., all DownstreamJPState(S,*,VI) are set to 597 NoInfo state). After reattaching and completing unicast handover 598 negotiations, the mobile source can continue to transmit multicast 599 packets, while being treated as a new source at its new DR (MAG). 600 Source register encapsulation will be immediately initiated, and 601 (S,G) data continue to flow natively down the (*,G) RP-based tree. 603 Source handover management in PIM phase one admits low complexity and 604 remains transparent to receivers. In addition, the source register 605 tunnel management of PIM is a fast protocol operation and little 606 overhead can be expected thereof. In a PMIPv6 deployment, PIM RPs 607 MAY be configured to not initiated (S,G) shortest path tress for 608 mobile sources, and thus remain in phase one of the protocol. The 609 price to pay for such simplified deployment lies in possible routing 610 detours by an overall RP-based packet distribution even in those 611 cases, where mobile senders and receivers are attached to the same 612 access router. 614 4.3.3. Operations of PIM in Phase Two 616 After receiving source register packets, a PIM RP eventually will 617 initiated a source-specific Join for creating a shortest path tree to 618 the (mobile) source S, and issue a source register stop at the native 619 arrival of data from S. For initiating an (S,G) tree, the RP, as well 620 as all intermediate routers, require route entries for MN's HNP that 621 - unless the RP coincides with the MAG of S - point towards the 622 corresponding LMA of S. Consequently, the (S,G) tree will proceed 623 from the RP via the (stable) LMA, the LMA-MAG tunnel to the mobile 624 source. This tree can be of lesser routing efficiency than the PIM 625 source register tunnel established in phase one, but provides the 626 advantage of immediate data delivery to receivers that share a MAG 627 with S. 629 On handover, the mobile source reattaches to a new MAG (DR), and 630 PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new 631 point of attachment. However, in the absence of a corresponding 632 multicast forwarding state, the new DR will treat S as a new source 633 and initiate a source registering of PIM phase one. In consequence, 634 the PIM transition from phase one to two will be iterated per 635 handover, leading to an enhanced signaling load and repeated delay 636 variations. 638 4.3.4. Operations of PIM in Phase Three 640 In response to an exceeded threshold of packet transmission, DRs of 641 receivers eventually will initiated a source-specific Join for 642 creating a shortest path tree to the (mobile) source S, thereby 643 transitioning PIM into the final short-cut phase three. For all 644 receivers not sharing a MAG with S, this (S,G) tree will proceed from 645 the receiving DR via the (stable) LMA, the LMA-MAG tunnel to the 646 mobile source. This tree is of higher routing efficiency than 647 established in the previous phase two, but need not outperform the 648 PIM source register tunnel established in phase one. It provides the 649 advantage of immediate data delivery to receivers that share a MAG 650 with S. 652 On handover, the mobile source reattaches to a new MAG (DR), and 653 PMIPv6 unicast management will transfer the LMA-MAG tunnel to the new 654 point of attachment. However, in the absence of a corresponding 655 multicast forwarding state, the new DR will treat S as a new source 656 and initiate a source registering of PIM phase one. In consequence, 657 the PIM transition from phase one to two and three will be iterated 658 per handover, leading to an enhanced signaling load and repeated 659 delay variations. 661 4.3.5. PIM-SSM Considerations 663 Source-specific Joins of receivers will guide PIM to operate in SSM 664 mode and lead to an immediate establishment of source-specific 665 shortest path trees. Such (S,G) trees will equal the distribution 666 system of PIM's final phase three (see Section 4.3.4). However, on 667 handover and in the absence of RP-based data distribution, SSM data 668 delivery cannot be resumed via source registering as in PIM phase 669 one. Consequently, data packets transmitted after a handover will be 670 discarded at the MAG until regular tree maintenance has re- 671 established the (S,G) forwarding state at the new MAG. 673 4.3.6. Handover Optimizations for PIM 675 Source-specific shortest path trees are constructed in PIM-SM (phase 676 two and three), and in PIM-SSM that follow LMA-MAG tunnels towards a 677 source. As PIM remains unaware of source mobility management, these 678 trees invalidate under handovers with each tunnel re-establishment at 679 a new MAG. Regular tree maintenance of PIM will recover the states, 680 but remains unsynchronized and too slow to seamlessly preserve PIM 681 data dissemination. 683 A method to quickly recover PIM (S,G) trees under handover SHOULD 684 synchronize multicast state maintenance with unicast handover 685 operations and MAY proceed as follows. On handover, an LMA reads all 686 (S,G) Join states from its corresponding tunnel interface and 687 identifies those source addresses S_i that match moving HNPs. After 688 re-establishing the new tunnel, it SHOULD associate the (S_i,*) Join 689 states with the new tunnel endpoint and immediately trigger a state 690 maintenance (PIM Join) message. In proceeding this way, the source- 691 specific PIM states are transferred to the new tunnel end point and 692 propagated to the new MAG in synchrony with unicast handover 693 procedures. 695 4.4. BIDIR-PIM 697 BIDIR-PIM MAY be deployed in the access network for providing 698 multicast services in parallel to unicast routes. Throughout this 699 section, it is assumed that the PMIPv6 mobility domain is part of a 700 single BIDIR-PIM multicast routing domain with BIDIR-PIM routing 701 functions present at all MAGs and all LMAs. The PIM routing instance 702 at a MAG SHALL then serve as the Designated Forwarder (DF) for all 703 directly attached Mobile Nodes. For expediting handover operations, 704 it is advisable to position BIDIR-PIM Rendezvous Point Addresses 705 (RPAs) in the core of the PMIPv6 network domain. As regular IP 706 routing tables need not be present in a PMIPv6 deployment, reverse 707 path forwarding rules as required by BIDIR-PIM need to be 708 established. 710 4.4.1. Routing Information Base for BIDIR-PIM 712 In this scenario, BIDIR-PIM will rely on a Multicast Routing 713 Information Base (MRIB) that is generated independently of the 714 policy-based routing rules of PMIPv6. The following information is 715 needed. 717 o All routes to networks and nodes (including RPAs) that are not 718 mobile members of the PMIPv6 domain MUST be defined consistently 719 among BIDIR-PIM routers and remain uneffected by node mobility. 720 The setup of these general routes is expected to follow the 721 topology of the operator network and is beyond the scope of this 722 document. 724 4.4.2. Operations of BIDIR-PIM 726 BIDIR-PIM will establish spanning trees across its network domain in 727 conformance to its preconfigured RPAs and the routing information 728 provided. Multicast data transmitted by a mobile source will 729 immediately be forwarded by its DF (MAG) onto the spanning group tree 730 without further protocol operations. 732 On handover, the mobile source re-attaches to a new MAG (DF), which 733 completes unicast network configurations. Thereafter, the source can 734 immediately proceed with multicast packet transmission onto the pre- 735 established distribution tree. BIDIR-PIM does neither require 736 protocol signaling nor additional reconfiguration delays to adapt to 737 source mobility and can be considered the protocol of choice for 738 mobile multicast operations in the access. As multicast streams 739 always flow up to the Rendezvous Point Link, some care should be 740 taken to configure RPAs compliant with network capacities. 742 5. Extended MLD Proxy Functions for Optimized Source Mobility in PMIPv6 744 A deployment of MLD Proxies (see [RFC4605]) at MAGs has proven a 745 useful and appropriate approach to multicast in PMIPv6, see 746 [RFC6224], [I-D.ietf-multimob-pmipv6-ropt]. However, unmodified 747 standard solutions go along with significant performance degradation 748 for mobile senders as discussed along the lines of this document. To 749 overcome these deficits, optimizing approaches to multicast source 750 mobility are introduced in this section. In particular, uplink 751 capabilities of MLD proxies are extended to allow for rapid, 752 optimized multicast traffic flows from mobile sources. 754 Solutions that extend MLD Proxies by additional uplinking functions 755 need to comply to the following requirements. 757 Prevention of Routing Loops In the absence of a full-featured 758 routing logic at an MLD Proxy, simple and locally decidable rules 759 need to prevent source traffic from traversing the network in 760 loops as potentially enabled by multiple uplinks. 762 Unique coverage of receivers Listener functions at Proxies require 763 simple, locally decidable rules to initiate a unique delivery of 764 multicast packets for all receivers. 766 Following different techniques, these requirements are met in the 767 following solutions. 769 5.1. Multiple Upstream Interface Proxy 771 In this section, we define upstream extensions for an MLD proxy. 772 Multiple proxy instances deployed at a single MAG (see Section 3) can 773 be avoided by adding multiple upstream interfaces to a single MLD 774 Proxy. In a typical PMIPv6 deployment, each upstream of a single 775 Proxy instance can interconnect one of the LMAs. With such ambiguous 776 upstream options, appropriate forwarding rules MUST be supplied to 778 o unambiguously guide traffic forwarding from directly attached 779 mobile sources, and 781 o lead listener reports to initiating unique traffic subscriptions. 783 This can be achieved by a complete set of source- and group-specific 784 filter rules (e.g., (S,*), (*,G)) installed at proxy interfaces. 785 These filters MAY be derived in parts from PMIPv6 routing policies, 786 and can include a default behavior (e.g., (*,*)). 788 TODO details 790 5.1.1. Operations for Local Multicast Sources 792 Packets from a locally attached multicast source will be forwarded to 793 all downstream interfaces with appropriate subscriptions, as well as 794 up the interface with the matching source-specific filter. 796 TODO details 798 5.1.2. Operations for Local Multicast Subscribers 800 Multicast listener reports are group-wise aggregated by the MLD 801 proxy. The aggregated report is issued to the upstream interface 802 with matching group-specific filter. 804 TODO details 806 5.2. Peering Function for MLD Proxies 808 In this section, we define a peering interface for MLD proxies that 809 allows for a direct data exchange of locally attached multicast 810 sources. Such peering interfaces can be configured - as a direct 811 link or a bidirectional tunnel - between any two proxy instances 812 (locally deployed as in [RFC6224] or remotely) and remains a silent 813 virtual link in regular proxy operations. Data on such link is 814 exchanged only in cases, where one peering proxy connects to a source 815 of multicast traffic, which the other peering proxy actively 816 subscribes to. Operations are defined for ASM and SSM, but provide 817 superior performance in SSM mode. 819 5.2.1. Operations at the Multicast Sender 821 An MLD Proxy with peering interfaces will install and maintain source 822 filters at its peering links that will restrict data transmission to 823 those packets that originate from a locally attached source. In this 824 way, a multihop forwarding on peering links is prevented. Multicast 825 packets that arrive from the upstream interface of the Proxy are thus 826 be forwarded only to regular downstream interfaces with appropriate 827 subscription states. 829 Multicast traffic arriving from a locally attached source will be 830 forwarded to the regular upstream interface and all downstreams with 831 appropriate subscription states (i.e., regular Proxy operations). In 832 addition, local multicast packets are transferred to those peering 833 interfaces with appropriate subscription states. As seen from the 834 sender side, peering interfaces act as restricted downstream 835 interfaces. 837 5.2.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 provide several interfaces for pulling remote traffic: the regular 842 upstream and the peerings. Traffic arriving from any of the peering 843 links will normally also be available from the upstream. To prevent 844 duplicate traffic from arriving at the listener side, the Proxy 846 o MAY delay aggregated reports to the upstream, and 848 o MUST apply appropriate filters to exclude duplicate streams. 850 In detail, it first issues listener reports (in parallel) to its 851 peering links, which are only one (virtual) hop apart. Whenever the 852 expected traffic (e.g., SSM channels) does not completely arrive from 853 the peerings after a waiting time (default: 10 ms), additional 854 (complementary, in the case of SSM) reports are sent to the standard 855 upstream interface. 857 After the arrival of traffic from peering links, an MLD proxy MUST 858 install source filters at the upstream in the following way. 860 ASM In the presence of Any Source Multicast (IGMPv2/MLDv1), only, 861 the Proxy cannot signal source filtering to its upstream. 862 Correspondingly, it applies (S,*) ingress filters at its upstream 863 interface. It is noteworthy that unwanted traffic is still 864 replicated to the proxy via the access network. 866 SSM In the presence of source-specific signaling (IGMPv3/MLDv2), the 867 upstream interface is set to (S,*) exclude mode for all sources S 868 seen in traffic of the peering links. The corresponding source- 869 specific signaling will prevent duplicate traffic forwarding 870 throughout the access network. 872 In proceeding this way, multicast group data arrive from peering 873 interfaces first, while only peer-wise unavailable traffic is 874 retrieved from the regular upstream interface. 876 6. IANA Considerations 878 TODO. 880 Note to RFC Editor: this section may be removed on publication as an 881 RFC. 883 7. Security Considerations 885 TODO 887 Consequently, no new threats are introduced by this document in 888 addition to those identified as security concerns of [RFC3810], 889 [RFC4605], [RFC5213], and [RFC5844]. 891 However, particular attention should be paid to implications of 892 combining multicast and mobility management at network entities. As 893 this specification allows mobile nodes to initiate the creation of 894 multicast forwarding states at MAGs and LMAs while changing 895 attachments, threats of resource exhaustion at PMIP routers and 896 access networks arrive from rapid state changes, as well as from high 897 volume data streams routed into access networks of limited 898 capacities. In addition to proper authorization checks of MNs, rate 899 controls at replicators MAY be required to protect the agents and the 900 downstream networks. In particular, MLD proxy implementations at 901 MAGs SHOULD carefully procure for automatic multicast state 902 extinction on the departure of MNs, as mobile multicast listeners in 903 the PMIPv6 domain will not actively terminate group membership prior 904 to departure. 906 8. Acknowledgements 908 The authors would like to thank (in alphabetical order) Muhamma Omer 909 Farooq, Bohao Feng, Dirk von Hugo, Ning Kong, Jouni Korhonen, He-Wu 910 Li, Akbar Rahman, Stig Venaas, Li-Li Wang, Qian Wu, Zhi-Wei Yan for 911 advice, help and reviews of the document. Funding by the German 912 Federal Ministry of Education and Research within the G-LAB 913 Initiative (project HAMcast) is gratefully acknowledged. 915 9. References 917 9.1. Normative References 919 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 920 Requirement Levels", BCP 14, RFC 2119, March 1997. 922 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 923 Listener Discovery (MLD) for IPv6", RFC 2710, 924 October 1999. 926 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 927 Thyagarajan, "Internet Group Management Protocol, Version 928 3", RFC 3376, October 2002. 930 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 931 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 933 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 934 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 935 Protocol Specification (Revised)", RFC 4601, August 2006. 937 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 938 "Internet Group Management Protocol (IGMP) / Multicast 939 Listener Discovery (MLD)-Based Multicast Forwarding 940 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 942 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 943 "Bidirectional Protocol Independent Multicast (BIDIR- 944 PIM)", RFC 5015, October 2007. 946 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 947 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 949 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 950 Mobile IPv6", RFC 5844, May 2010. 952 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 953 in IPv6", RFC 6275, July 2011. 955 9.2. Informative References 957 [I-D.ietf-multimob-pmipv6-ropt] 958 Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. 959 Kim, "Multicast Mobility Routing Optimizations for Proxy 960 Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-00 (work in 961 progress), March 2012. 963 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 964 2", RFC 2236, November 1997. 966 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 967 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 968 and Brief Survey", RFC 5757, February 2010. 970 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 971 "Generic Routing Encapsulation (GRE) Key Option for Proxy 972 Mobile IPv6", RFC 5845, June 2010. 974 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 975 Deployment for Multicast Listener Support in Proxy Mobile 976 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 978 Appendix A. Evaluation of Traffic Flows 980 TODO 982 Appendix B. Change Log 984 The following changes have been made from version 985 draft-ietf-multimob-pmipv6-source-00: 987 1. Direct routing with PIM-SM and PIM-SSM has been added. 989 2. PMIP synchronization with PIM added for improved handover. 991 3. Direct routing with BIDIR-PIM has been added. 993 4. MLD Proxy extensions requirements added. 995 5. Peering of MLD Proxies added. 997 6. First sketch of multiple upstream proxy added. 999 7. Editorial improvements. 1001 8. Updated references. 1003 Authors' Addresses 1005 Thomas C. Schmidt 1006 HAW Hamburg 1007 Berliner Tor 7 1008 Hamburg 20099 1009 Germany 1011 Email: schmidt@informatik.haw-hamburg.de 1012 URI: http://inet.cpt.haw-hamburg.de/members/schmidt 1013 Shuai Gao 1014 Beijing Jiaotong University 1015 Beijing, 1016 China 1018 Phone: 1019 Fax: 1020 Email: shgao@bjtu.edu.cn 1021 URI: 1023 Hong-Ke Zhang 1024 Beijing Jiaotong University 1025 Beijing, 1026 China 1028 Phone: 1029 Fax: 1030 Email: hkzhang@bjtu.edu.cn 1031 URI: 1033 Matthias Waehlisch 1034 link-lab & FU Berlin 1035 Hoenower Str. 35 1036 Berlin 10318 1037 Germany 1039 Email: mw@link-lab.net