idnits 2.17.1 draft-asaeda-multimob-pmip6-extension-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 7 characters in excess of 72. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2012) is 4202 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: '11' is defined on line 628, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4601 (ref. '3') (Obsoleted by RFC 7761) == Outdated reference: A later version (-13) exists of draft-ietf-pim-explicit-tracking-02 == Outdated reference: A later version (-03) exists of draft-ietf-multimob-fast-handover-01 == Outdated reference: A later version (-03) exists of draft-vonhugo-multimob-cxtp-extension-02 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Group H. Asaeda 3 Internet-Draft NICT 4 Intended status: Standards Track P. Seite 5 Expires: April 25, 2013 France Telecom 6 October 22, 2012 8 Multicast Routing Optimization by PIM-SM with PMIPv6 9 draft-asaeda-multimob-pmip6-extension-11 11 Abstract 13 This document describes IP multicast routing optimization using 14 PIM-SM in Proxy Mobile IPv6 (PMIPv6) environment. The Mobile Access 15 Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility 16 entities defined in the PMIPv6 protocol and act as PIM-SM routers. 17 The proposed protocol optimization addresses the tunnel convergence 18 problem and cooperates with seamless handover mechanisms. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 25, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 56 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.1. Multicast Communication in PMIPv6 . . . . . . . . . . . . 4 58 3.2. Protocol Sequence for Multicast Channel Subscription . . . 6 59 4. Multicast Tunnel (M-Tunnel) . . . . . . . . . . . . . . . . . 7 60 4.1. Packet Encapsulation . . . . . . . . . . . . . . . . . . . 7 61 4.2. M-Tunnels Connecting to Multiple PIM-SM Routers and 62 ECMP Routing . . . . . . . . . . . . . . . . . . . . . . . 9 63 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10 64 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 11 65 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 11 66 8. Localized Multicast Routing . . . . . . . . . . . . . . . . . 12 67 9. Smooth Handover . . . . . . . . . . . . . . . . . . . . . . . 12 68 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 69 11. Security Considerations . . . . . . . . . . . . . . . . . . . 15 70 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 73 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 Proxy Mobile IPv6 (PMIPv6) [1] enables network-based mobility for 79 IPv6 mobile nodes (MNs) that do not implement any mobility protocols. 80 The Local Mobility Anchor (LMA) is the topological anchor point to 81 manages the mobile node's binding state. The Mobile Access Gateway 82 (MAG) is an access router or gateway that manages the mobility- 83 related signaling for an MN. An MN is attached to the Proxy Mobile 84 IPv6 Domain (PMIPv6-Domain) that includes LMA and MAG(s), and is able 85 to receive data coming from outside of the PMIPv6-Domain through LMA 86 and MAG. 88 Network-based mobility support for unicast is addressed in [1], while 89 multicast support in PMIPv6 is not discussed in it. Since LMA and 90 MAG set up a bi-directional IPv6-in-IPv6 tunnel for each mobile node 91 and forwards all mobile node's traffic according to [1], it highly 92 wastes network resources when a large number of mobile nodes join/ 93 subscribe the same multicast sessions/channels, because independent 94 data copies of the same multicast packet are delivered to the 95 subscriber nodes in a unicast manner through MAG. 97 The base solution described in [12] provides options for deploying 98 multicast listener functions in PMIPv6-Domains without modifying 99 mobility and multicast protocol standards. However, in this 100 specification, MAG MUST act as an MLD proxy [2] and hence MUST 101 dedicate a tunnel link between LMA and MAG to an upstream interface 102 for all multicast traffic. This limitation does not allow to use 103 PIM-SM native routing on MAG, and hence does not solve the tunnel 104 convergence problem; MAG receives the same data from multiple LMAs 105 when MAG attaches to them for mobile nodes and has subscribed the 106 same multicast channel to them. It does not enable direct routing 107 and does not optimize source mobility. 109 This document describes IP multicast routing optimization using 110 PIM-SM in Proxy Mobile IPv6 (PMIPv6) environment. The Mobile Access 111 Gateway (MAG) and the Local Mobility Anchor (LMA) are the mobility 112 entities defined in the PMIPv6 protocol and act as PIM-SM routers. 113 The proposed protocol optimization assumes that both LMA and MAG 114 enable the Protocol-Independent Multicast - Sparse Mode (PIM-SM) 115 multicast routing protocol [3]. The proposed optimization uses a 116 dedicated GRE [4] tunnel for multicast, called M-Tunnel between MAG 117 and PIM-SM router such as LMA. The proposed protocol optimization 118 addresses the tunnel convergence problem and provides seamless 119 handover. It can cooperate with localized routing and direct routing 120 to deliver IP multicast packets for mobile nodes and source mobility. 121 In this document, because multicast listener mobility is mainly 122 focused on, the detail specification of source mobility is not 123 described. 125 This document does not require to change unicast communication 126 methods or protocols defined in [1], and therefore both unicast and 127 multicast communications for mobile nodes in PMIPv6-Domain are 128 enabled if this extension is implemented. 130 2. Conventions and Terminology 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 133 NOT","SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in 134 this document are to be interpreted as described in RFC 2119 [5]. 136 The following terms used in this document are to be interpreted as 137 defined in the Proxy Mobile IPv6 specification [1]; Mobile Access 138 Gateway (MAG), Local Mobility Anchor (LMA), Mobile Node (MN), Proxy 139 Mobile IPv6 Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of 140 Address (Proxy-CoA), Mobile Node's Home Network Prefix (MN-HNP), 141 Mobile Node Identifier (MN-Identifier), Proxy Binding Update (PBU), 142 and Proxy Binding Acknowledgement (PBA). 144 3. Overview 146 3.1. Multicast Communication in PMIPv6 148 Required components to enable IP multicast are multicast routing 149 protocols and host-and-router communication protocols. This document 150 assumes PIM-SM [3] as the multicast routing protocol and Multicast 151 Listener Discovery (MLD) as the host-and-router communication 152 protocol. This document allows mobile nodes to participate in Any- 153 Source Multicast (ASM) and Source-Specific Multicast (SSM) [6]. 154 However, in order to explicitly participate in SSM, mobile nodes MUST 155 support either MLDv2 [7] or Lightweight-MLDv2 (LW-MLDv2) [8]. 157 The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1. 158 LMA and MAG are the core functional entities in PMIPv6-Domain. The 159 entire PMIPv6-Domain appears as a single link from the perspective of 160 each mobile node. 162 +---------+ 163 | Content | 164 | Source | 165 +---------+ 166 | 167 *** *** *** *** *** 168 * ** ** ** ** * 169 * * 170 * Fixed Internet * 171 * * 172 * ** ** ** ** * 173 *** *** *** *** *** 174 / \ 175 +----+ +----+ 176 |LMA1| |LMA2| 177 +----+ +----+ 178 LMAA1 -> | | <-- LMAA2 179 | | 180 \\ //\\ 181 \\ // \\ 182 \\ // \\ 183 \\ // \\ 184 \\ // \\ 185 \\ // \\ 186 Proxy-CoA1--> | | <-- Proxy-CoA2 187 +----+ +----+ 188 |MAG1|---{MN2} |MAG2| 189 +----+ | +----+ 190 | | | 191 MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4 192 {MN1} {MN3} 194 Figure 1: Proxy Mobile IPv6 Domain 196 When a mobile node wants to subscribe/unsubscribe a multicast 197 channel, it sends MLD Report messages specifying sender and multicast 198 addresses to the access link. The attached MAG detects this 199 membership information and sends the PIM Join/Prune message to the 200 corresponding LMA over a bi-directional GRE tunnel called M-Tunnel 201 (described in Section 4) when the LMA is selected as the previous-hop 202 router for the multicast channel, or sends the PIM Join/Prune message 203 to the adjacent upstream multicast router for the multicast channel. 204 When the LMA or the adjacent router receives the PIM Join/Prune 205 message, it coordinates the corresponding multicast routing tree if 206 necessary and starts forwarding the data. 208 When the MAG detects mobile node's handover, it can proceed the 209 seamless handover procedures. Since both PMIPv6 and multicast 210 protocols (i.e., MLD and PIM-SM) do not have functions for multicast 211 context transfer in their original protocol specifications, the 212 external functions or protocols should be used for handover. One of 213 the possibile ways is the use of "mobile node's Policy Profile", as 214 it could include "multicast channel information", which expresses 215 mobile node's subscribing multicast channel list, as well as the 216 mandatory fields of the Policy Profile specified in [1]. Mobile 217 node's Policy Profile is provided by "policy store" whose definition 218 is the same as of [1]. 220 3.2. Protocol Sequence for Multicast Channel Subscription 222 A mobile node sends unsolicited MLD Report messages including source 223 and multicast addresses when it subscribes a multicast channel. 224 Although MLDv2 specification [7] permits to use the unspecified 225 address (::) for a host whose interface has not acquired a valid 226 link-local address yet, MAG SHOULD send MLDv2 Report messages with a 227 valid IPv6 link-local source address as defined in [13]. As well, 228 MLDv2 Report messages MAY be sent with an IP destination address of 229 FF02:0:0:0:0:0:0:16, to which all MLDv2-capable multicast routers 230 listen, but the IP unicast address of the attached MAG SHALL be used 231 for the destination of MLDv2 Report messages. 233 When the MAG operating as a PIM-SM router receives MLD Report 234 messages from attached mobile nodes, it joins the multicast delivery 235 tree by sending PIM Join messages to its neighboring routers 236 (Figure 2). When the upstream router for the requested channel is 237 LMA, the MAG sends the corresponding PIM Join messages to the LMA 238 using M-Tunnel (described in Section 4), if the MAG has not joined to 239 the requested multicast channel. When the upstream router for the 240 requested channel is an adjacent router that is not the LMA, the MAG 241 sends the corresponding PIM Join messages to the adjacent upstream 242 router natively, if the MAG has not joined to the requested multicast 243 channel. The LMA or the adjacent upstream router then joins the 244 multicast delivery tree and forwards the packets to the downstream 245 MAG. 247 MN1 MN2 MAG LMA 248 | | | | 249 |------MLD Report--------->| | 250 | (S1,G1) join | PIM (S1,G1) Join | 251 | | |===== M-Tunnel ===>| 252 | | | |---> PIM (S1,G1) Join 253 | | | | 254 | |--MLD Report-->| | 255 | | (S2,G2) join | | 256 | | |---> PIM (S2,G2) Join 257 | | | | 258 | |--MLD Report-->| | 259 | | (S1,G1) join | | 260 | | | | 262 Figure 2: MLD Report and PIM Messages Transmission 264 The MAG selects only one upstream interface (either M-Tunnel 265 interface or physical interface) for a multicast channel by the 266 Reverse Path Forwarding (RPF) algorithm. This does not cause the 267 tunnel convergence problem, because Multicast Routing Information 268 Base (MRIB) used by PIM-SM selects only one upstream interface for 269 each multicast channel and hence duplicate packets are not forwarded 270 to the MAG. 272 4. Multicast Tunnel (M-Tunnel) 274 4.1. Packet Encapsulation 276 M-Tunnel is a bi-directional GRE tunnel [4] dedicated for PIM 277 messages and IP multicast data transmissions. The tunnel end-point 278 of M-Tunnel is a MAG that is a PIM-SM capable router. Another tunnel 279 end-point is also a PIM-SM capable router. The typical use case of 280 M-Tunnel is to establish a bi-directional tunnel link between LMA and 281 MAG; therefore LMA shall be another tunnel end-point. M-Tunnel can 282 be established in a bootstrap phase of MAG (without detecting a 283 multicast channel subscription request from a mobile node) and kept 284 while the MAG enables PIM routing functions to forward multicast 285 packets. An M-Tunnel is not set up per mobile node basis, but per 286 MAG basis; it can be shared with mobile nodes attached to the MAG as 287 seen in Figure 3. 289 MC1 290 \ 291 \--> 292 MC2---->LMA===MC1,MC2 for MNs====>MAG 294 MC: Multicast packets, ==>: M-Tunnel 296 Figure 3: Multicast packet forwarding through M-Tunnel 298 In order for the PIM routing protocol to use an M-Tunnel for 299 multicast forwarding, an M-Tunnel interface must be recognized by the 300 PIM routing protocol as the upstream multicast interface for MAG. It 301 is done by the configuration of static multicast routes, such as "ip 302 mroute 0.0.0.0 0.0.0.0 gre0" or "ip mroute 1.1.1.0 255.255.255.0 303 gre0". By such configuration, MAG inserts the multicast route paths 304 using the M-Tunnel into its MRIB. MAG then selects the M-Tunnel 305 interface as the corresponding RPF interface, and forwards the PIM 306 Join/Prune messages over the M-Tunnel. If operators want to select 307 other interface, e.g. a physical interface, as the upstream multicast 308 interface for some specific source prefixes, e.g. sources inside the 309 PMIPv6-Domain, they can *additionally* configure the specific 310 multicast routes with longer prefixes. This configuration will be 311 used for direct routing. Then the MAG selects as the appropriate 312 upstream router according to the MRIB entry. Note that the case 313 having multiple M-Tunnels configured on MAG is described in 314 Section 4.2. 316 The format of the tunneled multicast packet forwarded from LMA to MAG 317 is shown below. "S" and "G" are the same notation used for (S,G) 318 multicast channel. 320 IPv6 header (src= LMAA, dst= Proxy-CoA) /* Outer Header */ 321 GRE header /* Encapsulation Header */ 322 IPv6 header (src= S, dst= G) /* Inner Header */ 323 Upper layer protocols /* Packet Content */ 325 Figure 4: Multicast packet format tunneled from LMA to MAG 327 When a PIM message is sent from MAG to LMA, the src and dst addresses 328 of the outer tunnel header will be replaced to Proxy-CoA and LMAA, 329 respectively. To convey a PIM message, the src address of the inner 330 packet header is changed to either LMA's or MAG's link-local address. 331 The dst address of the packet header is assigned based on the PIM's 332 condition (see [3]). 334 In order to establish M-Tunnel, LMA and MAG need to negotiate GRE 335 encapsulation and GRE keys for M-Tunnel. The GRE Key option to be 336 used for the negotiation of GRE tunnel encapsulation mode and 337 exchange of the uplink and downlink GRE keys is defined in [9]. It 338 is also possible to use the static fixed GRE keys for M-Tunnel. 340 4.2. M-Tunnels Connecting to Multiple PIM-SM Routers and ECMP Routing 342 There can be multiple LMAs in a PMIPv6-Domain each serving a 343 different group of mobile nodes. In that case, a MAG will connect to 344 multiple LMAs with different M-Tunnels having different GRE keys. 345 For example, in Figure 5, MAG1 establishes two M-Tunnels with LMA1 346 and LMA2, and MAG2 establishes one M-Tunnel with LMA2. 348 A MAG that has multiple M-Tunnels, such as MAG1 in Figure 5, must 349 decide a single upstream M-Tunnel interface for an RP or a source 350 address or prefix. There are two ways to decide a single upstream 351 M-Tunnel for a MAG. One is only with static MRIB configuration by 352 operation. For example, operators can configure each M-Tunnel 353 interface as the RPF interface for specific source adddress(es) or 354 prefix(es) one by one. Each M-Tunnel interface is then inserted into 355 the MAG's MRIB and used for different source adddress(es) or 356 prefix(es). 358 The other way to select a single upstream M-Tunnel interface is with 359 PIM ECMP [14]. A MAG enabling PIM routing functions selects a path 360 in the ECMP based on its own implementation specific choice, which 361 may refer to the description in [14]. The PIM ECMP function chooses 362 the PIM neighbor with the highest IP address, or picks the PIM 363 neighbor with the best hash value over the destination and source 364 addresses. When operators decide to use PIM ECMP to select a single 365 upstream M-Tunnel from multiple M-Tunnels, both MAG and the tunnel 366 end-point PIM-SM routers (e.g., LMAs) MUST enable PIM ECMP. 368 +----+ +----+ 369 |LMA1| |LMA2| 370 +----+ +----+ 371 || || || 372 || || || 373 \\ M-Tunnel // \\ 374 \\ | // \\ 375 \\ +-> // \\ <-- M-Tunnel 376 M-Tunnel ---> \\ // \\ 377 (encapsulating \\ // \\ 378 with GRE header) \\ // \\ 379 || || || 380 +----+ +----+ 381 |MAG1|---{MN2} |MAG2| 382 +----+ +----+ 383 | | 384 | | 385 {MN1} {MN3} 387 Figure 5: M-Tunnels established between LMA and MAG 389 5. Local Mobility Anchor Operation 391 The LMA is responsible for maintaining the mobile node's reachability 392 state and is the topological anchor point for the mobile node's home 393 network prefix(es). This document assumes that the LMA is capable of 394 forwarding multicast packets to the MAG by enabling the Protocol- 395 Independent Multicast - Sparse Mode (PIM-SM) multicast routing 396 protocol [3]. The LMA acting as a PIM-SM multicast router may serve 397 MAGs as downstream routers for some multicast channels when a mobile 398 node is a multicast data receiver (or as upstream routers when a 399 mobile node is a multicast data sender). The downstream (or 400 upstream) MAG is connected to the LMA through the M-Tunnel for 401 multicast communication. 403 When the LMA sets up the multicast state and joins the group as the 404 MAG's upstream router, the multicast packets are tunneled to the MAG 405 that requested to receive the corresponding multicast session. The 406 MAG then forwards the packets to the mobile node according to the 407 multicast listener state maintained in the MAG. [1] supports only 408 point-to-point access link types for MAG and mobile node connection; 409 hence a mobile node and the MAG are the only two nodes on an access 410 link, where the link is assumed to be multicast capable. 412 6. Mobile Access Gateway Operation 414 The MAG is the entity that performs the mobility management on behalf 415 of a mobile node. This document assumes that the MAG is PIM-SM 416 capable and forwards multicast packets to the corresponding mobile 417 nodes attached to MAG by enabling the PIM-SM multicast routing 418 protocol. In addition, the MAG must maintain multicast membership 419 status for the attached mobile nodes at the edge and forwards the 420 multicast data to the member mobile nodes. This condition requires 421 MAG to support MLDv2 [7] or LW-MLDv2 [8], as well. 423 When mobile nodes subscribe multicast channel(s), they send MLD 424 Report messages with their link-local address to the MAG, and the MAG 425 sends the corresponding PIM Join messages to the upstream router if 426 the MAG has no multicast state for the requested channel(s). The 427 upstream router is selected by the Reverse Path Forwarding (RPF) 428 lookup algorithm, and that is either the LMA or an adjacent multicast 429 router attached to the same link. If the LMA is the upstream router 430 for the channel(s) for the MAG, the MAG encapsulates PIM Join 431 messages using the M-Tunnel. 433 The MAG also sends MLD Query messages to attached mobile nodes to 434 maintain up-to-date membership states. Since the MAG may deal with a 435 large number of the downstream mobile nodes, the MLD protocol 436 scalability should be taken into account as described in [13]. 437 Therefore it is RECOMMENDED that the explicit tracking function [15] 438 is enabled on the MAG. 440 The optimal multicast routing path may not include the LMA, 441 especially in localized routing as described in Section 6.10.3 of [1] 442 and [10]. The localized routing option is designed to support node- 443 to-node communication within PMIPv6-Domain where a local content 444 source exists. Details are described in Section 8. 446 7. Mobile Node Operation 448 Mobile nodes attached to the MAG can behave as regular receiver 449 hosts. A mobile node sends MLD report messages to the MAG when it 450 wants to subscribe and unsubscribe IP multicast channels. 452 In order to subscribe/unsubscribe multicast channel(s) by unsolicited 453 report messages and inform current membersip state by solicited 454 report messages, mobile nodes MUST support either MLDv1 [7], MLDv2 455 [7], or LW-MLDv2 [8], and SHOULD support MLDv2 or LW-MLDv2. 457 8. Localized Multicast Routing 459 Localized routing defined in [10] allows mobile nodes attached to the 460 same or different MAGs to directly exchange unicast traffic by using 461 localized forwarding or a direct tunnel between the MAGs. Localized 462 routing must be initiated both MAG and LMA. Localized routing is not 463 persistent, and is initiated by two signaling messages, Localized 464 Routing Initiation (LRI) and Local Routing Acknowledgment (LRA), sent 465 by LMA or MAG. 467 To support localized multicast routing with PIM-SM capable LMA and 468 MAG, both LMA and MAG MUST include the routes orgzanized by the 469 localized routing procedure specified in [10] into their MRIBs. The 470 exact mechanism to do this is not specified in this document and is 471 left open for implementations and specific deployments. 473 To support localized routing for the case that a source node and a 474 receiver node are attached to different MAGs but the same LMA (as 475 seen in Section 6 of [10]), these MAGs must use the same tunneling 476 mechanism for the data traffic tunneled between them. M-Tunnel 477 defined in this document corresponds to the concept; these MAGs 478 establish M-Tunnel and enable localized multicast routing. 480 9. Smooth Handover 482 The MAG is responsible for detecting the mobile node's movements to 483 and from the access link and for initiating binding registrations to 484 the mobile node's LMA. In PMIPv6, it does not require for mobile 485 nodes to initiate to re-subscribe multicast channels, and the MAG 486 keeps multicast channel subscription status for mobile nodes even if 487 they move to a different MAG (i.e., n-MAG) in PMIPv6-Domain. 489 The MAG needs to join the multicast delivery tree when an attached 490 mobile node subscribes a multicast channel. When the mobile node 491 changes the network, it seamlessly receives multicast data from the 492 new MAG according to the multicast channel information stored in the 493 "MN's Policy Profile" or by some handover mechanisms such as [16] and 494 [17]. Whether the MN's Policy Profile or a hondover mechanism mobile 495 operators use depend on their policy or implementation. 497 Here, a handover procedure using the MN's Policy Profile is described 498 as an example. When the multicast channel information subscribed by 499 mobile nodes is maintained in "MN's Policy Profile" stored in a 500 policy store [1], the MAG can use the channel information to provide 501 seamless handover. The procedures are described as follows and 502 illustrated in Figure 6; 503 1. Figure 6 shows the examples that a mobile node has received 504 multicast data from an upstream multicast router via p-MAG (*1) 505 and from LMA via p-MAG (*2). 507 2. Whenever the mobile node moves a new network and attaches to 508 n-MAG, the n-MAG obtains the MN-Identifier (MN-ID) and learns 509 multicast channel information described in Mobile Node's Policy 510 Profile associated to this MN-Identifier. Describing the method 511 how the n-MAG identifies the p-MAG is out of scope of this 512 document, while using the same mechanism described in [18] would 513 be one of the possible methods. 515 3. If there are multicast channels the mobile node has subscribed 516 but the n-MAG has not yet subscribed, n-MAG joins the 517 corresponding multicast channels by sending the PIM Join message 518 to its upstream router. If the upstream router is the LMA, the 519 PIM messages are encapsulated and transmitted over the M-Tunnel 520 (*4); otherwise the PIM messages are sent natively to the 521 adjacent upstream router (*3). 523 4. The multicast data is forwarded from the LMA through the 524 M-Tunnel between the LMA and n-MAG (*4) or from the adjacent 525 upstream router (*3). 527 MN p-MAG LMA n-MAG 528 | | | | 529 |--MLD Report->| | | 530 | |---> PIM Join (*1) | 531 | | PIM Join (*2) | | 532 | |==== M-Tunnel ====>| | 533 | | |---> PIM Join (*2) 534 | | | | 535 |<--Multicast--| | | 536 | data (*1) | | | 537 | |Multicast data (*2)| | 538 |<-------------|<=== M-Tunnel =====| | 539 | | | | 540 Detach | | | 541 | | | | 542 Attach | | | 543 | | | MN attachment event 544 | | | (Acquire MN-ID and Profile) 545 |-------------------------RS-------------------------->| 546 | | | | 547 | | |<-------PBU--------| 548 | | | | 549 | | |--------PBA------->| 550 | | | |---> PIM Join (*3) 551 | | | PIM Join (*4) | 552 | | |<==== M-Tunnel ====| 553 | | | | 554 |<------------------------RA---------------------------| 555 | | | | 556 | | Multicast data (*3) | 557 |<-----------------------------------------------------| 558 | | |Multicast data (*4)| 559 | | |==== M-Tunnel ====>| 560 |<-----------------------------------------------------| 561 | | | | 563 Figure 6: Handover with MN's Policy Profile 565 After MN attaches to n-MAG, the multicast data will be delivered to 566 the MN immediately. MN's multicast membership state is maintained 567 with MLD Query and Report messages exchanged by MN and n-MAG. If 568 p-MAG thinks that the moving mobile node is the last member of 569 multicast channel(s) (according to the membership record maintained 570 by the explicit tracking function [15]), p-MAG confirms it by sending 571 MLD query. After the confirmation, p-MAG leaves the channel(s) by 572 sending the PIM Prune message to its upstream router. 574 10. IANA Considerations 576 This document has no actions for IANA. 578 11. Security Considerations 580 TBD. 582 12. Acknowledgements 584 Many of the specifications described in this document are discussed 585 and provided by the multimob mailing-list. 587 13. References 589 13.1. Normative References 591 [1] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, K., 592 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 594 [2] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet 595 Group Management Protocol (IGMP) / Multicast Listener Discovery 596 (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", 597 RFC 4605, August 2006. 599 [3] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 600 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 601 Protocol Specification (Revised)", RFC 4601, August 2006. 603 [4] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, 604 "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. 606 [5] Bradner, S., "Key words for use in RFCs to indicate requirement 607 levels", RFC 2119, March 1997. 609 [6] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", 610 RFC 4607, August 2006. 612 [7] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 613 (MLDv2) for IPv6", RFC 3810, June 2004. 615 [8] Liu, H., Cao, W., and H. Asaeda, "Lightweight Internet Group 616 Management Protocol Version 3 (IGMPv3) and Multicast Listener 617 Discovery Version 2 (MLDv2) Protocols", RFC 5790, 618 February 2010. 620 [9] Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung, "Generic 621 Routing Encapsulation (GRE) Key Option for Proxy Mobile IPv6", 622 RFC 5845, June 2010. 624 [10] Krishnan, S., Koodli, R., Loureiro, P., Wu, Q., and A. Dutta, 625 "Localized Routing for Proxy Mobile IPv6", RFC 6705, 626 September 2012. 628 [11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 629 Discovery (MLD) for IPv6", RFC 2710, October 1999. 631 13.2. Informative References 633 [12] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base Deployment 634 for Multicast Listener Support in Proxy Mobile IPv6 (PMIPv6) 635 Domains", RFC 6224, April 2011. 637 [13] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of the 638 Internet Group Management Protocol (IGMP) and Multicast 639 Listener Discovery (MLD) for Routers in Mobile and Wireless 640 Networks", RFC 6636, May 2012. 642 [14] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 643 Multicast Next-Hop Selection", RFC 2991, November 2000. 645 [15] Asaeda, H. and N. Leymann, "IGMP/MLD-Based Explicit Membership 646 Tracking Function for Multicast Routers", 647 draft-ietf-pim-explicit-tracking-02.txt (work in progress), 648 October 2012. 650 [16] Contreras, LM., Bernardos, CJ., and I. Soto, "PMIPv6 multicast 651 handover optimization by the Subscription Information 652 Acquisition through the LMA (SIAL)", 653 draft-ietf-multimob-fast-handover-01.txt (work in progress), 654 July 2012. 656 [17] von Hugo, D. and H. Asaeda, "Context Transfer Protocol 657 Extension for Multicast", 658 draft-vonhugo-multimob-cxtp-extension-02.txt (work in 659 progress), August 2012. 661 [18] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. Xia, 662 "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 663 September 2010. 665 Authors' Addresses 667 Hitoshi Asaeda 668 National Institute of Information and Communications Technology 669 4-2-1 Nukui-Kitamachi 670 Koganei, Tokyo 184-8795 671 Japan 673 Email: asaeda@nict.go.jp 675 Pierrick Seite 676 France Telecom 677 4, rue du Clos Courtel 678 BP 91226, Cesson-Sevigne 35512 679 France 681 Email: pierrick.seite@orange-ftgroup.com