idnits 2.17.1 draft-ietf-multimob-fmipv6-pfmipv6-multicast-05.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 is 1 instance of too long lines in the document, the longest one being 67 characters in excess of 72. -- The draft header indicates that this document updates RFC5568, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2014) is 3683 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 941 -- Looks like a reference, but probably isn't: '2' on line 947 == Missing Reference: 'M' is mentioned on line 957, but not defined == Unused Reference: 'RFC1112' is defined on line 1132, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 1147, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-09) exists of draft-ietf-multimob-pmipv6-source-08 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 4 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 Updates: 5568 (if approved) M. Waehlisch 5 Intended status: Experimental link-lab & FU Berlin 6 Expires: September 20, 2014 R. Koodli 7 Intel 8 G. Fairhurst 9 University of Aberdeen 10 Dapeng. Liu 11 China Mobile 12 March 19, 2014 14 Multicast Listener Extensions for MIPv6 and PMIPv6 Fast Handovers 15 draft-ietf-multimob-fmipv6-pfmipv6-multicast-05 17 Abstract 19 Fast handover protocols for MIPv6 and PMIPv6 define mobility 20 management procedures that support unicast communication at reduced 21 handover latency. Fast handover base operations do not affect 22 multicast communication, and hence do not accelerate handover 23 management for native multicast listeners. Many multicast 24 applications like IPTV or conferencing, though, comprise delay- 25 sensitive real-time traffic and will benefit from fast handover 26 completion. This document specifies extension of the Mobile IPv6 27 Fast Handovers (FMIPv6) and the Fast Handovers for Proxy Mobile IPv6 28 (PFMIPv6) protocols to include multicast traffic management in fast 29 handover operations. This multicast support is provided first at the 30 control plane by a management of rapid context transfer between 31 access routers, second at the data plane by an optional fast traffic 32 forwarding that may include buffering. An FMIPv6 access router 33 indicates support for multicast using an updated Proxy Router 34 Advertisements message format. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on September 20, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 1.1. Use Cases and Deployment Scenarios . . . . . . . . . . . 4 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. Multicast Context Transfer between Access Routers . . . . 6 75 3.2. Protocol Operations Specific to FMIPv6 . . . . . . . . . 8 76 3.3. Protocol Operations Specific to PFMIPv6 . . . . . . . . . 10 77 4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . 13 78 4.1. Protocol Operations Specific to FMIPv6 . . . . . . . . . 14 79 4.1.1. Operations of the Mobile Node . . . . . . . . . . . . 14 80 4.1.2. Operations of the Previous Access Router . . . . . . 14 81 4.1.3. Operations of the New Access Router . . . . . . . . . 15 82 4.1.4. Buffering Considerations . . . . . . . . . . . . . . 16 83 4.2. Protocol Operations Specific to PFMIPv6 . . . . . . . . . 16 84 4.2.1. Operations of the Mobile Node . . . . . . . . . . . . 16 85 4.2.2. Operations of the Previous MAG . . . . . . . . . . . 16 86 4.2.3. Operations of the New MAG . . . . . . . . . . . . . . 17 87 4.2.4. IPv4 Support Considerations . . . . . . . . . . . . . 18 88 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 19 89 5.1. Multicast Indicator for Proxy Router Advertisement 90 (PrRtAdv) . . . . . . . . . . . . . . . . . . . . . . . . 19 91 5.2. Extensions to Existing Mobility Header Messages . . . . . 19 92 5.3. New Multicast Mobility Option . . . . . . . . . . . . . . 20 93 5.4. New Multicast Acknowledgement Option . . . . . . . . . . 22 94 5.5. Length Considerations: Number of Records and Addresses . 23 95 5.6. MLD (IGMP) Compatibility Requirements . . . . . . . . . . 23 97 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 98 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 99 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 100 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 101 9.1. Normative References . . . . . . . . . . . . . . . . . . 25 102 9.2. Informative References . . . . . . . . . . . . . . . . . 26 103 Appendix A. Considerations for Mobile Multicast Sources . . . . 26 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 106 1. Introduction 108 Mobile IPv6 [RFC6275] defines a network layer mobility protocol 109 involving participation by mobile nodes, while Proxy Mobile IPv6 110 [RFC5213] provides a mechanism without requiring mobility protocol 111 operations at a Mobile Node (MN). Both protocols introduce traffic 112 disruptions on handovers that may be intolerable in many real-time 113 application scenarios such as gaming or conferencing. Mobile IPv6 114 Fast Handovers (FMIPv6) [RFC5568], and Fast Handovers for Proxy 115 Mobile IPv6 (PFMIPv6) [RFC5949] improve the performance of these 116 handover delays for unicast communication to the order of the maximum 117 of the delays needed for link switching and signaling between Access 118 Routers (ARs) or Mobile Access Gateways (MAGs) [FMIPv6-Analysis]. 120 No dedicated treatment of seamless multicast data service has been 121 proposed by any of the above protocols. MIPv6 only roughly defines 122 multicast for Mobile Nodes using a remote subscription approach or a 123 home subscription through bi-directional tunneling via the Home Agent 124 (HA). Multicast forwarding services have not been specified in 125 [RFC5213], but are subject to current specification [RFC6224], 126 [I-D.ietf-multimob-pmipv6-source]. It is assumed throughout this 127 document that mechanisms and protocol operations are in place to 128 transport multicast traffic to ARs. These operations are referred to 129 as 'JOIN/LEAVE' of an AR, while the explicit techniques to manage 130 multicast transmission are beyond the scope of this document. 132 Mobile multicast protocols need to support applications such as IPTV 133 with high-volume content streams and allow distribution to 134 potentially large numbers of receivers. They should thus preserve 135 the multicast nature of packet distribution and approximate optimal 136 routing [RFC5757]. It is undesirable to rely on home tunneling for 137 optimizing multicast. Unencapsulated, native multicast transmission 138 requires establishing forwarding state, which will not be transferred 139 between access routers by the unicast fast handover protocols. Thus 140 multicast traffic will not experience expedited handover performance, 141 but an MN - or its corresponding MAG in PMIPv6 - can perform remote 142 subscriptions in each visited network. 144 This document specifies extensions to FMIPv6 and PFMIPv6 that include 145 multicast traffic management for fast handover operations in the 146 presence of any source or source specific multicast. The protocol 147 extensions were designed under the requirements that 149 o multicast context transfer shall be transparently included in 150 unicast fast handover operations 152 o neither unicast mobility protocols nor multicast routing shall be 153 modified or otherwise affected 155 o no active participation of MNs in PMIPv6 domains is defined. 157 The solution common to both underlying unicast protocols defines the 158 per-group or per channel transfer of multicast contexts between ARs 159 or MAGs. The protocol defines corresponding message extensions 160 necessary for carrying (*,G) or (S,G) context information independent 161 of the particular handover protocol. ARs or MAGs are then enabled to 162 treat multicast traffic according to fast unicast handovers and with 163 similar performance. No protocol changes are introduced that prevent 164 a multicast unaware node from performing fast handovers with 165 multicast aware ARs or MAGs. 167 The specified mechanisms apply when a mobile node has joined and 168 maintains one or several multicast group subscriptions prior to 169 undergoing a fast handover. It does not introduce any requirements 170 on the multicast routing protocols in use, nor are the ARs or MAGs 171 assumed to be multicast routers. It assumes network conditions, 172 though, that allow native multicast reception in both, the previous 173 and new access network. Methods to bridge regions without native 174 multicast connectivity are beyond the scope of this document. 176 Section 5.1 of this memo updates the Proxy Router Advertisements 177 (PrRtAdv) message format defined in Section 6.1.2. of [RFC5568] to 178 allow an FMIPv6 AR to indicate support for multicast. 180 1.1. Use Cases and Deployment Scenarios 182 Multicast Extensions for Fast Handovers enable multicast services in 183 those domains that operate any of the unicast fast handover protocols 184 [RFC5568] or [RFC5949]. Typically, fast handover protocols are 185 activated within an operator network or within a dedicated service 186 installation. 188 Multicast group communication has a variety of dominant use cases. 189 One traditional application area is infotainment with voluminous 190 multimedia streams delivered to a large number of receivers (e.g., 191 IPTV). Other time-critical news items like stock-exchange prices are 192 commonly transmitted via multicast to support fair and fast updates. 193 Both may be mobile and both largely benefit from fast handover 194 operations. Operators may enhance their operational quality or offer 195 premium services by enabling fast handovers. 197 Another traditional application area for multicast is conversational 198 group communication in scenarios like conferencing or gaming, but 199 also in dedicated collaborative environments or teams. Machine-to- 200 machine communication in the emerging Internet of Things is expected 201 to generate various additional mobile use cases (e.g., among cars). 202 High demands on transmission quality and rapidly moving parties may 203 require fast handovers. 205 Most of the deployment scenarios above are bound to a fixed 206 infrastructure with consumer equipment at the edge. Today, they are 207 thus likely to follow an operator-centric approach like PFMIPv6. 208 However, Internet technologies evolve for adoption in 209 infrastructureless scenarios, at disaster recovery, rescue, crisis 210 prevention and civil safety for example. Mobile end-to-end 211 communication in groups is needed in Public Protection and Disaster 212 Relief (PPDR) scenarios, where mobile multicast communication needs 213 to be supported between members of rescue teams, police officers, 214 fire brigade teams, paramedic teams, command control offices in order 215 to support the protection and health of citizens. These use cases 216 require fast and reliable mobile services which cannot rely on 217 operator infrastructure. They are thus predestined to running 218 multicast with FMIPv6. 220 2. Terminology 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in RFC 2119 [RFC2119]. 225 The use of the term, "silently ignore" is not defined in RFC 2119. 226 However, the term is used in this document and can be similarly 227 construed. 229 This document uses the terminology of [RFC5568], [RFC5949], 230 [RFC6275], and [RFC5213] for mobility entities. 232 3. Protocol Overview 234 This section provides an informative overview of the protocol 235 mechanisms without normative specifications. 237 The reference scenario for multicast fast handover is illustrated in 238 Figure 1. A Mobile Node is initially attached to the previous access 239 network (P-AN) via the Previous Access Router (PAR) or Previous 240 Mobile Access Gateway (PMAG) and moves to the new access network 241 (N-AN) connected via a New AR (NAR) or New MAG (NMAG). 243 *** *** *** *** 244 * ** ** ** * 245 * * 246 * Multicast Cloud * 247 * * 248 * ** ** ** * 249 *** *** *** *** 250 / \ 251 / \ 252 / \ 253 +........../..+ +..\..........+ 254 . +-------+-+ .______. +-+-------+ . 255 . | PAR |()_______)| NAR | . 256 . | (PMAG) | . . | (NMAG) | . 257 . +----+----+ . . +----+----+ . 258 . | . . | . 259 . ___|___ . . ___|___ . 260 . / \ . . / \ . 261 . ( P-AN ) . . ( N-AN ) . 262 . \_______/ . . \_______/ . 263 . | . . | . 264 . +----+ . . +----+ . 265 . | MN | ----------> | MN | . 266 . +----+ . . +----+ . 267 +.............+ +.............+ 269 Figure 1: Reference Network for Fast Handover 271 3.1. Multicast Context Transfer between Access Routers 273 In a fast handover scenario (cf. Figure 1), ARs/MAGs establish a 274 mutual binding and provide the capability to exchange context 275 information concerning the MN. This context transfer will be 276 triggered by detecting the forthcoming movement of an MN to a new AR 277 and assists the MN to immediately resume communication on the new 278 subnet using its previous IP address. In contrast to unicast, 279 multicast flow reception does not primarily depend on address and 280 binding cache management, but requires distribution trees to adapt so 281 that traffic follows the movement of the MN. This process may be 282 significantly slower than fast handover management [RFC5757]. To 283 accelerate the handover, multicast listeners may offer the twofold 284 advantage of including the multicast groups under subscription in the 285 context transfer. First, the NAR can proactively join the subscribed 286 groups as soon as it gains knowledge of them. Second, multicast 287 flows can be included in traffic forwarding via the tunnel 288 established from the PAR to the NAR. 290 There are two modes of operation in FMIPv6 and in PFMIPv6. The 291 predictive mode allows for AR-binding and context transfer prior to 292 an MN handover, while in the reactive mode, these steps are executed 293 after detection that the MN has re-attached to a NAR (NMAG). Details 294 of the signaling schemes differ between FMIPv6 and PFMIPv6 and are 295 outlined in Section 3.2 and Section 3.3. 297 In a predictive fast handover, the access router (i.e., PAR (PMAG) in 298 Figure 1) learns about the impending movement of the MN and 299 simultaneously about the multicast group context as specified in 300 Section 3.2 and Section 3.3. Thereafter, the PAR will initiate an 301 AR-binding and context transfer by transmitting a HI message to NAR 302 (NMAG). The Handover Initiation (HI) message is extended by 303 multicast group states carried in mobility header options as defined 304 in Section 5.3. On reception of the HI message, the NAR returns a 305 multicast acknowledgement in its Handover Acknowledgement (HACK) 306 answer that indicates its ability to support each requested group 307 (see Section 5.4). The NAR (NMAG) expresses its willingness to 308 receive multicast traffic forwarded by the PAR using standard MLD 309 signaling. There are several reasons to waive forwarding, e.g., the 310 NAR could already have a native subscription for the group(s), or 311 capacity constraints can hinder decapsulation of additional streams. 312 At the previous network, there may be policy of capacity constraints 313 that make it undesirable to forward the multicast traffic. The PAR 314 can add the tunnel interface to its multicast forwarding database for 315 those groups the MN wishes to receive, so that multicast flows can be 316 forwarded in parallel to the unicast traffic. 318 The NAR implements an MLD proxy [RFC4605] providing host-side 319 behaviour towards the upstream PAR. The proxy will submit an MLD 320 report to the upstream tunnel interface to signal that it requests 321 the groups/channels to be forwarded. It will terminate multicast 322 forwarding from the tunnel when the group is natively received. In 323 parallel, the NAR joins all groups that are not already under 324 subscription using its native multicast upstream interface. While 325 the MN has not arrived at a downstream interface of the NAR, 326 multicast subscriptions on behalf of the MN are associated with a 327 downstream Loopback interface. Reception of the Join at the NAR 328 enables downstream native multicast forwarding of the subscribed 329 group(s). 331 In a reactive fast handover, the PAR will learn about the movement of 332 the MN, after the latter has re-associated with the new access 333 network. Also from the new link, it will be informed about the 334 multicast context of the MN. As group membership information is 335 present at the new access network prior to context transfer, MLD join 336 signaling can proceed in parallel to HI/HACK exchange. Following the 337 context transfer, multicast data can be forwarded to the new access 338 network using the PAR-NAR tunnel of the fast handover protocol. 339 Depending on the specific network topology multicast traffic for some 340 groups may natively arrive before it is forwarded from PAR. 342 In both modes of operation, it is the responsibility of the PAR 343 (PMAG) to properly apply multicast state management when an MN leaves 344 (i.e., to determine if it can prune the traffic for any unsubscribed 345 group). Depending on the link type and MLD parameter settings, 346 methods for observing the departure of an MN need to be applied (cf., 347 [RFC5757]). While considering subscriptions of the remaining nodes 348 and from the tunnel interfaces, the PAR uses normal multicast 349 forwarding rules to determine whether multicast traffic can be 350 pruned. 352 This method allows an MN to participate in multicast group 353 communication with a handover performance that is comparable to 354 unicast handover. 356 3.2. Protocol Operations Specific to FMIPv6 358 ARs that provide multicast support in FMIPv6 will advertise this 359 general service by setting an indicator bit (M-bit) in its PrRtAdv 360 message as defined in Section 5.1. Additional details about the 361 multicast service support, e.g., flavors and groups, will be 362 exchanged within HI/HACK dialogs later at handover. 364 An MN operating FMIPv6 will actively initiate the handover management 365 by submitting a Fast Binding Update (FBU). The MN, which is aware of 366 the multicast groups it wishes to maintain, will attach mobility 367 options containing its group states (see Section 5.3) to the FBU, and 368 thereby inform ARs about its multicast context. ARs will use these 369 multicast context options for inter-AR context transfer. 371 In predictive mode, the FBU is issued on the previous link and 372 received by the PAR as displayed in Figure 2. The PAR will extract 373 the multicast context options and append them to its HI message. 374 From the HACK message, PAR will redistribute the multicast 375 acknowledgement by adding the corresponding mobility options to its 376 Fast Binding ACK (FBACK) message. From receiving the FBACK message, 377 the MN will group-wise learn about the multicast support in the new 378 access network. If some groups or multicast service models are not 379 supported, it can decide on taking actions to overcome the missing 380 service (e.g., by tunneling). Note that the proactive multicast 381 context transfer may proceed successfully, even if the MN misses the 382 FBACK message on the previous link. 384 MN PAR NAR 385 | | | 386 |------RtSolPr------->| | 387 |<-----PrRtAdv--------| | 388 | | | 389 | | | 390 |---------FBU-------->|----------HI--------->| 391 | (Multicast MobOpt) | (Multicast MobOpt) | 392 | | | 393 | |<--------HAck---------| 394 | | (Multicast AckOpt) | 395 | | Join to 396 | | Multicast 397 | | Groups 398 | | | 399 | <-----FBack---|--FBack------> | 400 | (Multicast AckOpt) | (Multicast AckOpt) | 401 | | | 402 disconnect optional | 403 | packet ================>| 404 | forwarding | 405 | | | 406 connect | | 407 | | | 408 |------------UNA --------------------------->| 409 |<=================================== deliver packets 410 | | 412 Figure 2: Predictive Multicast Handover for FMIPv6 414 The flow diagram for reactive mode is depicted in Figure 3. After 415 attaching to the new access link and performing an unsolicited 416 neighbor advertisement (UNA), the MN issues an FBU which the NAR 417 forwards to the PAR without processing. At this time, the MN is able 418 to re-join all subscribed multicast groups without relying on AR 419 assistance. Nevertheless, multicast context options are exchanged in 420 the HI/HACK dialog to facilitate intermediate forwarding of requested 421 flows. The multicast traffic could arrive from a MN subscription at 422 the same time the NAR receives the HI message. Such multicast flows 423 may be transparently excluded from forwarding by setting an 424 appropriate multicast acknowledge option. In either case, the NAR 425 MUST ensure that not more than one flow of the same group is 426 forwarded to the MN. 428 MN PAR NAR 429 | | | 430 |------RtSolPr------->| | 431 |<-----PrRtAdv--------| | 432 | | | 433 disconnect | | 434 | | | 435 | | | 436 connect | | 437 |-------UNA-----------|--------------------->| 438 |-------FBU-----------|---------------------)| 439 | (Multicast MobOpt) |<-------FBU----------)| 440 | | | 441 Join to | | 442 Multicast | | 443 Groups | | 444 | |----------HI--------->| 445 | | (Multicast MobOpt) | 446 | |<-------HAck----------| 447 | | (Multicast AckOpt) | 448 | | | 449 | |(HI/HAck if necessary)| 450 | | | 451 | FBack, optional | 452 | packet forwarding ==========>| 453 | | | 454 |<=================================== deliver packets 455 | | 457 Figure 3: Reactive Multicast Handover for FMIPv6 459 3.3. Protocol Operations Specific to PFMIPv6 461 In a proxy mobile IPv6 environment, the MN remains agnostic of 462 network layer changes, and fast handover procedures are operated by 463 the access routers or MAGs to which MNs are connected via node- 464 specific point-to-point links. The handover initiation, or the re- 465 association respectively are managed by the access networks. 466 Consequently, access routers need to be aware of multicast membership 467 state at the mobile node. There are two ways to obtain the multicast 468 membership of an MN. 470 o MAGs may perform explicit tracking (see [RFC4605], [RFC6224]) or 471 extract membership status from forwarding states at node-specific 472 links. 474 o routers can issue a general MLD query at handovers. Both methods 475 are equally applicable. However, a router that does not operate 476 explicit tracking needs to query its downstream links after a 477 handover. The MLD membership information then allows the PMAG 478 (PAR) to learn the multicast group/channel subscriptions of the 479 MN. 481 In predictive mode, the PMAG (PAR) will learn about the upcoming 482 movement of the mobile node. Without explicit tracking, it will 483 immediately submit a general MLD query and receive MLD reports for 484 the subscribed group(s). As displayed in Figure 4, it will initiate 485 binding and context transfer with the NMAG (NAR) by issuing a HI 486 message that is augmented by multicast contexts in the mobility 487 options defined in Section 5.3. NAR will extract multicast context 488 information and act as described in Section 3.1. 490 PMAG NMAG 491 MN P-AN N-AN (PAR) (NAR) 492 | | | | | 493 | Report | | | | 494 |---(MN ID,-->| | | | 495 | New AP ID) | | | | 496 | | HO Indication | | 497 | |--(MN ID, New AP ID)-->| | 498 | | | | | 499 | | | Optional: | 500 | | | MLD Query | 501 | | | | | 502 | | | |------HI---->| 503 | | | |(Multicast MobOpt) 504 | | | | | 505 | | | |<---HAck-----| 506 | | | |(Multicast AckOpt) 507 | | | | | 508 | | | | Join to 509 | | | | Multicast 510 | | | | Groups 511 | | | | | 512 | | | |HI/HAck(optional) 513 | | | |<- - - - - ->| 514 | | | | | 515 | | | optional packet | 516 | | | forwarding =======>| 517 disconnect | | | | 518 | | | | | 519 connect | | | | 520 | MN-AN connection | AN-MAG connection | 521 |<----establishment----->|<----establishment------->| 522 | | | (substitute for UNA) | 523 | | | | | 524 |<========================================== deliver packets 525 | | | | | 527 Figure 4: Predictive Multicast Handover for PFMIPv6 529 In reactive mode, the NMAG (NAR) will learn the attachment of the MN 530 to the N-AN and establish connectivity using the PMIPv6 protocol 531 operations. However, it will have no knowledge about multicast state 532 at the MN. Triggered by a MN attachment, the NMAG will send a 533 general MLD query and thereafter join the requested groups. In the 534 case of a reactive handover, the binding is initiated by the NMAG, 535 and the HI/HACK message semantic is inverted (see [RFC5949]). For 536 multicast context transfer, the NMAG attaches to its HI message those 537 group identifiers it requests to be forwarded from PMAG. Using the 538 identical syntax in its multicast mobility option headers as defined 539 in Section 5.4, the PMAG acknowledges the set of requested groups in 540 a HACK answer, indicating the group(s) it is willing to forward. The 541 corresponding call flow is displayed in Figure 5. 543 PMAG NMAG 544 MN P-AN N-AN (PAR) (NAR) 545 | | | | | 546 disconnect | | | | 547 | | | | | 548 connect | | | | 549 | | | | | 550 | MN-AN connection | AN-MAG connection | 551 |<---establishment---->|<----establishment------->| 552 | | |(substitute for UNA & FBU)| 553 | | | | | 554 | | | | MLD Query 555 | | | | | 556 | | | | Join to 557 | | | | Multicast 558 | | | | Groups 559 | | | | 560 | | | |<------HI----| 561 | | | |(Multicast MobOpt) 562 | | | | | 563 | | | |---HAck----->| 564 | | | |(Multicast AckOpt) 565 | | | | | 566 | | | | | 567 | | | |HI/HAck(optional) 568 | | | |<- - - - - ->| 569 | | | | | 570 | | | optional packet | 571 | | | forwarding =======>| 572 | | | | | 573 |<======================================== deliver packets 574 | | | | | 576 Figure 5: Reactive Multicast Handover for PFMIPv6 578 4. Protocol Details 580 In this section the protocol operations are defined in a normative 581 way. 583 4.1. Protocol Operations Specific to FMIPv6 585 4.1.1. Operations of the Mobile Node 587 A Mobile Node willing to manage multicast traffic by fast handover 588 operations MUST transfer its MLD listener state records within fast 589 handover negotiations. 591 When sensing a handover in predictive mode, an MN MUST build a 592 Multicast Mobility Option as described in Section 5.3 that contains 593 the MLD (IGMP) multicast listener state and append it to the Fast 594 Binding Update (FBU) prior to signaling with PAR. 596 It will receive the Multicast Acknowledgement Option(s) as part of 597 the Fast Binding Acknowledge (FBACK) (see Section 5.4) and learn 598 about unsupported or prohibited groups at the NAR. The MN MAY take 599 appropriate actions like home tunneling to receive groups/channels 600 not available from NAR. No multicast-specific operation is required 601 by the MN when re-attaching in the new network besides standard 602 FMIPv6 signaling. 604 In reactive mode, the MN MUST append the identical Multicast Mobility 605 Option to FBU sent after its reconnect. In response, it will learn 606 about the Multicast Acknowledgement Option(s) from FBACK and expect 607 corresponding multicast data. Concurrently it joins all subscribed 608 multicast groups (channels) directly on its newly established access 609 link. 611 4.1.2. Operations of the Previous Access Router 613 A PAR MUST advertise its support for multicast by setting the M-bit 614 in PrRtAdv as specified in Section 5.1 of this document. This 615 indicator exclusively serves the purpose of informing MNs about the 616 capability of the PAR to process and exchange Multicast Mobility 617 Options during Fast Handover operations. 619 In predictive mode, a PAR will receive the multicast listener state 620 of an MN prior to handover from the Multicast Mobility Option 621 appended to the FBU. It forwards these records to NAR within HI 622 messages and will expect Multicast Acknowledgement Option(s) in HACK, 623 which itself is returned to the MN as an appendix to FBACK. In 624 performing multicast context exchange, the PAR is instructed to 625 include the PAR-to-NAR tunnel obtained from unicast handover 626 management in its multicast downstream interfaces and await MLD 627 listener reports from the NAR. In response to receiving multicast 628 subscriptions, the PAR SHOULD forward group data acting as a regular 629 multicast router or proxy. However, the PAR MAY refuse to forward 630 some or all of the multicast flows (e.g., due to administrative 631 configurations or load conditions). 633 In reactive mode, the PAR will receive the FBU augmented by the 634 Multicast Mobility Option from the new network, but continues with an 635 identical multicast record exchange in the HI/HACK dialog. As in the 636 predictive case, it configures the PAR-to-NAR tunnel for the 637 multicast downstream and forwards data according to MLD reports 638 obtained from NAR, if capable of forwarding. 640 In both modes, the PAR MUST interpret the first of the two events - 641 the departure of the MN or the reception of the Multicast 642 Acknowledgement Option(s) - as if the MN had sent a multicast LEAVE 643 message and react according to the signaling scheme deployed in the 644 access network (i.e., MLD querying, explicit tracking). 646 4.1.3. Operations of the New Access Router 648 A NAR MUST advertise its multicast support by setting the M-bit in 649 PrRtAdv as specified in Section 5.1 of this document. This indicator 650 exclusively serves the purpose of informing MNs about the capability 651 of the PAR to process and exchange Multicast Mobility Options during 652 Fast Handover operations. 654 In predictive mode, a NAR will receive the multicast listener state 655 of an expected MN from the Multicast Mobility Option appended to the 656 HI message. It will extract the MLD/IGMP records from the message 657 and intersect the request subscription with its multicast service 658 offer. Further on it will adjoin the supported groups (channels) to 659 the MLD listener state using Loopback as downstream interface. This 660 will lead to suitable regular subscriptions on its native multicast 661 upstream interface without additional forwarding. Concurrently, the 662 NAR builds a Multicast Acknowledgement Option(s) (see Section 5.4) 663 listing those groups (channels) unsupported on the new access link 664 and returns them within HACK. As soon as the bidirectional tunnel 665 from PAR to NAR is operational, the NAR joins the groups subscribed 666 for forwarding on the tunnel link. 668 In reactive mode, the NAR will learn about the multicast listener 669 state of a new MN from the Multicast Mobility Option appended to a HI 670 message at a time, when the MN has already performed local 671 subscriptions of the multicast service. Thus the NAR solely 672 determines the intersection of requested and supported groups 673 (channels) and issues the join requests for group forwarding on the 674 PAR-NAR tunnel interface. 676 In both modes, the NAR MUST send a LEAVE message to the tunnel after 677 forwarding of a group (channel) becomes unneeded, e.g., after native 678 multicast traffic arrives or group membership of the MN terminates. 679 Sending this immediately eliminates the need for PAR and NAR to 680 process traffic that is not forwarded. 682 4.1.4. Buffering Considerations 684 Multicast packets may be lost during handover. For example, in 685 predictive mode as illustrated by figure 2, packets may be lost while 686 the MN is - already or still - detached from the networks, even 687 though they are forwarded to the NAR. In reactive mode as 688 illustrated by figure 3, the situation may be worse since there will 689 be a delay for joining the multicast group after the MN re-attaches 690 to the NAR. Multicast packets cannot be delivered during this time. 691 Buffering the multicast packets at the PAR can reduce the multicast 692 packet loss, but may increase resource consumption and delay in 693 packet transmission. Implementors should balance the different 694 requirements in the context of predominant application demands (e.g., 695 real-time requirements). 697 4.2. Protocol Operations Specific to PFMIPv6 699 4.2.1. Operations of the Mobile Node 701 A Mobile Node willing to participate in multicast traffic will join, 702 maintain and leave groups as if located in the fixed Internet. It 703 will cooperate in handover indication as specified in [RFC5949] and 704 required by its access link-layer technology. No multicast-specific 705 mobility actions nor implementations are required at the MN in a 706 PMIPv6 domain. 708 4.2.2. Operations of the Previous MAG 710 A MAG receiving a handover indication for one of its MNs follows the 711 predictive fast handover mode as a PMAG. It MUST issue an MLD 712 General Query immediately on its corresponding link unless it 713 performs an explicit tracking on that link. After knowledge of the 714 multicast subscriptions of the MN is acquired, the PMAG builds a 715 Multicast Mobility Option as described in Section 5.3 that contains 716 the MLD (IGMP) multicast listener state. If not empty, this Mobility 717 Option is appended to the regular fast handover HI messages, or - in 718 the case of unicast HI message being submitted prior to multicast 719 state detection - sent in an additional HI message to the NMAG. 721 The PMAG then waits until it receives the Multicast Acknowledgement 722 Option(s) with a HACK message (see Section 5.4) and the creation of 723 the bidirectional tunnel with NMAG. After the HACK message is 724 received, the PMAG adds the tunnel to its downstream interfaces in 725 the multicast forwarding database. For those groups (channels) 726 reported in the Multicast Acknowledgement Option(s), i.e., not 727 supported in the new access network, the PMAG normally takes 728 appropriate actions (e.g., forwarding, termination) in concordance 729 with the network policy. It SHOULD start forwarding traffic down the 730 tunnel interface for those groups for which an MLD listener report 731 was received from NMAG. However, it MAY deny forwarding for some or 732 all groups included in the listener report. 734 After the departure of the MN and on the reception of LEAVE messages 735 for groups/channels, it is RECOMMENDED that the PMAG terminates 736 forwarding of the specific groups and updates its multicast 737 forwarding database. Correspondingly it issues a group/channel LEAVE 738 to its upstream link, if no more listeners are present on its 739 downstream links. 741 A MAG receiving a HI message with the Multicast Mobility Option for a 742 currently attached node follows the reactive fast handover mode as a 743 PMAG. It will return Multicast Acknowledgement Option(s) (see 744 Section 5.4) within a HACK message listing those groups/channels it 745 does not support to forward to the NMAG. It will add the 746 bidirectional tunnel with NMAG to its downstream interfaces and will 747 start forwarding multicast traffic for those groups it receives an 748 MLD listener report message from the NMAG. At the reception of LEAVE 749 messages for groups (channels), the PMAG terminates forwarding of the 750 specific groups and update its multicast forwarding database. 751 According to its multicast forwarding state, it will need to issue a 752 group/channel LEAVE to its upstream link, if no more listeners are 753 present on its downstream links. 755 In both modes, the PMAG will interpret the departure of the MN as a 756 multicast LEAVE message of the MN and react according to the 757 signaling scheme deployed in the access network (i.e., MLD querying, 758 explicit tracking). 760 4.2.3. Operations of the New MAG 762 A MAG receiving a HI message with a Multicast Mobility Option for a 763 currently unattached node follows the predictive fast handover mode 764 as an NMAG. It will decide on those multicast groups/channels it 765 selects to be forwarded from the PMAG and builds a Multicast 766 Acknowledgement Option (see Section 5.4) that enumerates only 767 unwanted groups/channels. This Mobility Option is appended to the 768 regular fast handover HACK messages, or - in the case of a unicast 769 HACK message being submitted prior to multicast state acknowledgement 770 - sent in an additional HACK message to the PMAG. Immediately 771 thereafter, the NMAG SHOULD update its MLD membership state based on 772 the report received in the Multicast Mobility Option. Until the MN 773 re-attaches, the NMAG uses its Loopback interface for downstream and 774 MUST NOT forward traffic to the potential link of the MN. The NMAG 775 SHOULD issue JOIN messages for those newly selected groups to its 776 regular multicast upstream interface. As soon as the bidirectional 777 tunnel with PMAG is established, the NMAG additionally joins those 778 groups/channels on the tunnel interface that it wants to receive 779 forwarded from the PMAG. 781 A MAG experiencing a connection request for an MN without prior 782 reception of a corresponding Multicast Mobility Option is operating 783 in the reactive fast handover mode as an NMAG. Following the re- 784 attachment, it SHOULD immediately issue an MLD General Query to learn 785 about multicast subscriptions of the newly arrived MN. Using 786 standard multicast operations, the NMAG joins the missing groups 787 (channels) on its regular multicast upstream interface. 788 Concurrently, it selects groups (channels) for forwarding from PMAG 789 and builds a Multicast Mobility Option as described in Section 5.3 790 that contains the MLD (IGMP) multicast listener state. If not empty, 791 this Mobility Option is appended to the regular fast handover HI 792 messages with the F flag set, or - in the case of unicast HI message 793 being submitted prior to multicast state detection - sent in an 794 additional HI message to the PMAG. Upon reception of the Multicast 795 Acknowledgement Option and establishment of the bidirectional tunnel, 796 the NMAG additionally joins those groups/channels on the tunnel 797 interface that it wants to receive by forwarding from the PMAG. When 798 multicast flows arrive, the NMAG forwards data to the appropriate 799 downlink(s). 801 In both modes, the NMAG MUST send a LEAVE message to the tunnel after 802 forwarding of a group (channel) becomes unneeded, e.g., after native 803 multicast traffic arrives or group membership of the MN terminates. 804 Sending this immediately eliminates the need for PMAG and NMAG to 805 process traffic that is not forwarded. 807 4.2.4. IPv4 Support Considerations 809 An MN in a PMIPv6 domain MAY use an IPv4 address transparently for 810 communication as specified in [RFC5844]. For this purpose, LMAs can 811 register IPv4-Proxy-CoAs in its Binding Caches and MAGs can provide 812 IPv4 support in access networks. Correspondingly, multicast 813 membership management will be performed by the MN using IGMP. For 814 multi-protocol multicast support on the network side, IGMPv3 router 815 functions are required at both MAGs (see Section 5.6 for 816 compatibility considerations with previous IGMP versions). Context 817 transfer between MAGs can transparently proceed in the HI/HACK 818 message exchanges by encapsulating IGMP multicast state records 819 within Multicast Mobility Options (see Section 5.3 and Section 5.4 820 for details on message formats). 822 The deployment of IPv4 multicast support SHOULD be homogeneous across 823 a PMIP domain. This avoids multicast service breaks during 824 handovers. 826 It is worth mentioning the scenarios of a dual-stack IPv4/IPv6 access 827 network, and the use of GRE tunneling as specified in[RFC5845]. 828 Corresponding implications and operations are discussed in the PMIP 829 Multicast Base Deployment document, see[RFC6224]. 831 5. Message Formats 833 5.1. Multicast Indicator for Proxy Router Advertisement (PrRtAdv) 835 This document updates the Proxy Router Advertisements (PrRtAdv) 836 message format defined in Section 6.1.2. of [RFC5568]. The update 837 assigns the first bit of the Reserved field, to carry the 'M' bit, as 838 defined in Figure 6. An FMIPv6 AR indicates support for multicast by 839 assigning the setting 'M' bit to a value of 1. 841 0 1 2 3 842 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type | Code | Checksum | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | Subtype |M| Reserved | Identifier | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Options ... 849 +-+-+-+-+-+-+-+-+-+-+-+- 851 Figure 6: Multicast Indicator Bit for Proxy Router Advertisement 852 (PrRtAdv) Message 854 This document updates the reserved field to include the 'M' bit 855 specified as follows. 857 M = 1 indicates that the specifications of this document apply 859 M = 0 indicates that the behaviour during Fast Handover proceeds 860 according to [RFC5568]. 862 The default value (0) of this bit indicates a non-multicast capable 863 service. 865 5.2. Extensions to Existing Mobility Header Messages 867 The fast handover protocols use an IPv6 header type called Mobility 868 Header as defined in [RFC6275]. Mobility headers can carry variable 869 Mobility Options. 871 The multicast listener context of an MN is transferred in fast 872 handover operations from PAR/PMAG to NAR/NMAG within a new Multicast 873 Mobility Option, and MUST be acknowledged by a corresponding 874 Multicast Acknowledgement Option. Depending on the specific handover 875 scenario and protocol in use, the corresponding option is included 876 within the mobility option list of HI/HACK only (PFMIPv6), or of FBU/ 877 FBACK/HI/HACK (FMIPv6). 879 5.3. New Multicast Mobility Option 881 This section defines the Multicast Mobility Option. It contains the 882 current listener state record of the MN obtained from the MLD Report 883 message, and has the format displayed in Figure 7. 885 0 1 2 3 886 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Type | Length | Option-Code | Reserved | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | | 891 + + 892 | | 893 + MLD (IGMP) Report Payload + 894 ~ ~ 895 ~ ~ 896 | | 897 + + 898 | | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 Figure 7: Mobility Header Multicast Option 903 RFC Editor note: IANA is requested to allocate the value XXX and 904 remove this note prior to publication. 906 Type: XXX 908 Length: 8-bit unsigned integer. The length in octets of this option, 909 not including the Option Type and Option Length fields. 911 Option-Code: 913 1: IGMPv3 Payload Type 915 2: MLDv2 Payload Type 917 3: IGMPv3 Payload Type from IGMPv2 Compatibility Mode 918 4: MLDv2 Payload Type from MLDv1 Compatibility Mode 920 Reserved: MUST be set to zero by the sender and MUST be ignored by 921 the receiver. 923 MLD (IGMP) Report Payload: this field is composed of the MLD (IGMP) 924 Report message after stripping its ICMP header. This Report Payload 925 always contains an integer number of muticast records. Corresponding 926 message formats are defined for MLDv2 in [RFC3810], and for IGMPv3 in 927 [RFC3376]. This field MUST always contain the first header line 928 (reserved field and No of Mcast Address Records). 930 Figure 8 shows the Report Payload for MLDv2, while the payload format 931 for IGMPv3 is defined corresponding to the IGMPv3 payload format (see 932 Section 5.2. of [RFC3810], or Section 4.2 of [RFC3376]) for the 933 definition of Multicast Address Records). 935 0 1 2 3 936 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | Reserved |No of Mcast Address Records (M)| 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 940 | | . . 941 . Multicast Address Record [1] . 942 . . 943 | | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 | | 946 . . 947 . Multicast Address Record [2] . 948 . . 949 | | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | . | 952 . . . 953 | . | 954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 | | 956 . . 957 . Multicast Address Record [M] . 958 . . 959 | | 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 962 Figure 8: MLDv2 Report Payload 964 5.4. New Multicast Acknowledgement Option 966 The Multicast Acknowledgement Option reports the status of the 967 context transfer and contains the list of state records that could 968 not be successfully transferred to the next access network. It has 969 the format displayed in Figure 9. 971 0 1 2 3 972 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Type | Length | Option-Code | Status | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | | 977 + + 978 | | 979 + MLD (IGMP) Unsupported Report Payload + 980 ~ ~ 981 ~ ~ 982 | | 983 + + 984 | | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Figure 9: Mobility Header Multicast Acknowledgement Option 989 RFC Editor note: IANA is requested to allocate the value XXX and 990 remove this note prior to publication. 992 Type: XXX 994 Length: 8-bit unsigned integer. The length in octets of this option, 995 not including the Option Type and Option Length fields. 997 Option-Code: 0 999 Status: 1001 1: Report Payload type unsupported 1003 2: Requested group service unsupported 1005 3: Requested group service administratively prohibited 1007 MLD (IGMP) Unsupported Report Payload: this field is syntactically 1008 identical to the MLD (IGMP) Report Payload field described in 1009 Section 5.3, but is only composed of those multicast address records 1010 that are not supported or prohibited in the new access network. This 1011 field MUST always contain the first header line (reserved field and 1012 No of Mcast Address Records), but MUST NOT contain any Mcast Address 1013 Records, if the status code equals 1. 1015 Note that group subscriptions to specific sources may be rejected at 1016 the destination network, and thus the composition of multicast 1017 address records may differ from initial requests within an MLD (IGMP) 1018 Report Payload option. 1020 5.5. Length Considerations: Number of Records and Addresses 1022 Mobility Header Messages exchanged in HI/HACK and FBU/FBACK dialogs 1023 impose length restrictions on multicast context records. The maximal 1024 payload length available in FBU/FBACK messages is the PATH-MTU - 40 1025 octets (IPv6 Header) - 6 octets (Mobility Header) - 6 octets (FBU/ 1026 FBACK Header). For example, on an Ethernet link with an MTU of 1500 1027 octets, not more than 72 Multicast Address Records of minimal length 1028 (without source states) may be exchanged in one message pair. In 1029 typical handover scenarios, this number reduces further according to 1030 unicast context and Binding Authorization data. A larger number of 1031 MLD Reports that exceed the available payload size MAY be sent within 1032 multiple HI/HACK or FBU/FBACK message pairs. In PFMIPv6, context 1033 information can be fragmented over several HI/HACK messages. 1034 However, a single MLDv2 Report Payload MUST NOT be fragmented. 1035 Hence, for a single Multicast Address Record on an Ethernet link, the 1036 number of source addresses (S,.) is limited to 89. 1038 5.6. MLD (IGMP) Compatibility Requirements 1040 Access routers (MAGs) MUST support MLDv2 (IGMPv3). To enable 1041 multicast service for MLDv1 (IGMPv2) listeners, the routers MUST 1042 follow the interoperability rules defined in [RFC3810] ([RFC3376]) 1043 and appropriately set the Multicast Address Compatibility Mode. 1045 When the Multicast Address Compatibility Mode is MLDv1 (IGMPv2), a 1046 router internally translates the following MLDv1 (IGMPv2) messages 1047 for that multicast address to their MLDv2 (IGMPv2) equivalents and 1048 uses these messages in the context transfer. The current state of 1049 Compatibility Mode is translated into the code of the Multicast 1050 Mobility Option as defined in Section 5.3. A NAR (nMAG) receiving a 1051 Multicast Mobility Option during handover will switch to the lowest 1052 level of MLD (IGMP) Compatibility Mode that it learned from its 1053 previous and new option values. This minimal compatibility agreement 1054 is used to allow for continued operation. 1056 6. Security Considerations 1058 Security vulnerabilities that exceed issues discussed in the base 1059 protocols of this document ([RFC5568], [RFC5949], [RFC3810], 1060 [RFC3376]) are identified as follows. 1062 Multicast context transfer at predictive handovers implements group 1063 states at remote access routers and may lead to group subscriptions 1064 without further validation of the multicast service requests. 1065 Thereby a NAR (nMAG) is requested to cooperate in potentially complex 1066 multicast re-routing and may receive large volumes of traffic. 1067 Malicious or inadvertent multicast context transfers may result in a 1068 significant burden of route establishment and traffic management onto 1069 the backbone infrastructure and the access router itself. Rapid re- 1070 routing or traffic overload can be mitigated by a rate control at the 1071 AR that restricts the frequency of traffic redirects and the total 1072 number of subscriptions. In addition, the wireless access network 1073 remains protected from multicast data injection until the requesting 1074 MN attaches to the new location. 1076 7. IANA Considerations 1078 This document defines two new mobility options which need allocation 1079 from the Mobility Header Type registry at http://www.iana.org/ 1080 assignments/mobility-parameters. 1082 XXX Multicast Mobility Option, described in Section 5.3 1084 XXX Multicast Acknowledgement Option, described in Section 5.4 1086 RFC Editor note: The RFC Editor is requested to replace "XXX" by the 1087 IANA-assigned value prior to publication and may then remove this 1088 note. 1090 8. Acknowledgments 1092 Protocol extensions to support multicast in Fast Mobile IPv6 have 1093 been loosely discussed for several years. Repeated attempts have 1094 been taken to define corresponding protocol extensions. The first 1095 draft [fmcast-mip6] was presented by Suh, Kwon, Suh, and Park in 1096 2004. 1098 This work was stimulated by many fruitful discussions in the MobOpts 1099 research group. We would like to thank all active members for 1100 constructive thoughts and contributions on the subject of multicast 1101 mobility. The MULTIMOB working group has provided continuous 1102 feedback during the evolution of this work. Comments, discussions 1103 and reviewing remarks have been contributed by (in alphabetical 1104 order) Carlos J. Bernardos, Luis M. Contreras, Hui Deng, Shuai Gao, 1105 Dirk von Hugo, Min Hui, Georgios Karagian, Marco Liebsch, Behcet 1106 Sarikaya, Stig Venaas and Juan Carlos Zuniga. 1108 Funding has been provided by the German Federal Ministry of Education 1109 and Research within the projects Mindstone, SKIMS and SAFEST, which 1110 is gratefully acknowledged. 1112 9. References 1114 9.1. Normative References 1116 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1117 Requirement Levels", BCP 14, RFC 2119, March 1997. 1119 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1120 in IPv6", RFC 6275, July 2011. 1122 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1123 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1125 [RFC5568] Koodli, R., "Mobile IPv6 Fast Handovers", RFC 5568, July 1126 2009. 1128 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 1129 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 1130 September 2010. 1132 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1133 RFC 1112, August 1989. 1135 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1136 "Internet Group Management Protocol (IGMP) / Multicast 1137 Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP 1138 /MLD Proxying")", RFC 4605, August 2006. 1140 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1141 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1143 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1144 Thyagarajan, "Internet Group Management Protocol, Version 1145 3", RFC 3376, October 2002. 1147 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1148 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1149 May 2008. 1151 9.2. Informative References 1153 [RFC5757] Schmidt, T., Waehlisch, M., and G. Fairhurst, "Multicast 1154 Mobility in Mobile IP Version 6 (MIPv6): Problem Statement 1155 and Brief Survey", RFC 5757, February 2010. 1157 [fmcast-mip6] 1158 Suh, K., Kwon, D., Suh, Y., and Y. Park, "Fast Multicast 1159 Protocol for Mobile IPv6 in the fast handovers 1160 environments", draft-suh-mipshop-fmcast-mip6-00 (work in 1161 progress), July 2004. 1163 [FMIPv6-Analysis] 1164 Schmidt, TC. and M. Waehlisch, "Predictive versus Reactive 1165 - Analysis of Handover Performance and Its Implications on 1166 IPv6 and Multicast Mobility", Telecommunication Systems 1167 Vol 33, No. 1-3, pp. 131-154, November 2005. 1169 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1170 Deployment for Multicast Listener Support in Proxy Mobile 1171 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1173 [I-D.ietf-multimob-pmipv6-source] 1174 Schmidt, T., Gao, S., Zhang, H., and M. Waehlisch, "Mobile 1175 Multicast Sender Support in Proxy Mobile IPv6 (PMIPv6) 1176 Domains", draft-ietf-multimob-pmipv6-source-08 (work in 1177 progress), March 2014. 1179 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1180 Mobile IPv6", RFC 5844, May 2010. 1182 [RFC5845] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, 1183 "Generic Routing Encapsulation (GRE) Key Option for Proxy 1184 Mobile IPv6", RFC 5845, June 2010. 1186 Appendix A. Considerations for Mobile Multicast Sources 1188 This document specifies protocol operations for a fast handover of 1189 mobile listeners, only. In this appendix, we briefly discuss aspects 1190 of supporting mobile multicast sources. 1192 In a multicast-enabled Proxy Mobile IPv6 domain, multicast sender 1193 support is likely to be enabled by any one of the mechanisms 1194 described in [I-D.ietf-multimob-pmipv6-source]. In this case, 1195 multicast data packets from an MN are transparently forwarded either 1196 to its associated LMA or to a multicast-enabled access network. In 1197 any case, a mobile source can continue to transmit multicast packets 1198 after a handover from pMAG to nMAG without additional management 1199 operations. Packets (with a persistent source address) will continue 1200 to flow via the LMA or the access network into the previously 1201 established distribution system. 1203 In contrast, an MN will change its Care-of Address while performing 1204 FMIPv6 handovers. Even though MNs are enabled to send packets via 1205 the reverse NAR-PAR tunnel using their previous Care-of Address for a 1206 limited time, Multicast sender support in such a Mobile IPv6 regime 1207 will most likely follow one of the basic mechanisms (1) bidirectional 1208 tunneling, (2) remote subscription, or (3) agent-based as described 1209 in Section 5.1 of [RFC5757]. A solution for multicast senders that 1210 is homogeneously deployed throughout the mobile access network can 1211 support seamless services during Fast Handovers, the details of which 1212 are beyond the scope of this document. 1214 Authors' Addresses 1216 Thomas C. Schmidt (editor) 1217 HAW Hamburg 1218 Dept. Informatik 1219 Berliner Tor 7 1220 Hamburg D-20099 1221 Germany 1223 Email: schmidt@informatik.haw-hamburg.de 1225 Matthias Waehlisch 1226 link-lab & FU Berlin 1227 Hoenower Str. 35 1228 Berlin D-10318 1229 Germany 1231 Email: mw@link-lab.net 1233 Rajeev Koodli 1234 Intel 1235 3600 Juliette Lane 1236 Santa Clara, CA 95054 1237 USA 1239 Email: rajeev.koodli@intel.com 1240 Godred Fairhurst 1241 University of Aberdeen 1242 School of Engineering 1243 Aberdeen AB24 3UE 1244 UK 1246 Email: gorry@erg.abdn.ac.uk 1248 Dapeng Liu 1249 China Mobile 1251 Phone: +86-123-456-7890 1252 Email: liudapeng@chinamobile.com