idnits 2.17.1 draft-liu-multimob-pmipv6-multicast-ro-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 30, 2012) is 4281 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4140 (Obsoleted by RFC 5380) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 6224 Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group J. Liu 3 Internet-Draft W. Luo 4 Intended status: Standards Track ZTE Corporation 5 Expires: January 31, 2013 July 30, 2012 7 Routes Optimization for Multicast Sender in Proxy Mobile IPv6 Domain 8 draft-liu-multimob-pmipv6-multicast-ro-02 10 Abstract 12 To support IP multicasting in PMIPv6 domain, MULTIMOB WG has issued 13 several proposals including the base solution, dedicated schemes and 14 direct routing which requires all communications to go through the 15 local mobility anchor(LMA), the dedicated server and the native 16 multicasting infrastructure, respectively. As this can be 17 suboptimal, this document describes multicast routes optimazition 18 mechanisms for multicast sender. Multicast sender attached to the 19 same or different mobile access gateways(MAG) with multicast listener 20 sends multicast data via the tunnel between the gateways without any 21 dedicated devices or dependence of the native multicasting 22 infrastructure. The MAG and the LMA are the mobility entities 23 defined in the PMIPv6 protocol and act as PIM-SM routers. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on January 31, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Add Route to MRIB . . . . . . . . . . . . . . . . . . . . 6 61 4.2. Optimized Multicast Route Establishment . . . . . . . . . 6 62 4.3. Multicast Route Deletion . . . . . . . . . . . . . . . . . 8 63 4.4. Multicast sender handover . . . . . . . . . . . . . . . . 10 64 4.5. Multicast listener handover . . . . . . . . . . . . . . . 10 65 4.6. ASM Scecario . . . . . . . . . . . . . . . . . . . . . . . 10 66 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 10 67 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 11 68 6.1. MN1 and MN2 attach to the same MAG . . . . . . . . . . . . 11 69 6.2. MN1 and MN2 attach to different MAG . . . . . . . . . . . 11 70 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 12 71 8. Message Format Extension . . . . . . . . . . . . . . . . . . . 12 72 8.1. Proxy Binding Update with Source Address Query 73 Extension . . . . . . . . . . . . . . . . . . . . . . . . 12 74 8.2. Proxy Binding Acknowledgement Message with Source 75 Address Query Extension . . . . . . . . . . . . . . . . . 13 76 8.3. Care-of Address Option . . . . . . . . . . . . . . . . . . 14 77 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 79 11. Normative References . . . . . . . . . . . . . . . . . . . . . 15 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 82 1. Introduction 84 Proxy Mobile IPv6 (PMIPv6) [RFC5213] enables network-based mobility 85 for IPv6 mobile nodes (MNs) that do not implement any mobility 86 protocols. The Local Mobility Anchor (LMA) is the topological anchor 87 point to manages the mobile node's binding state. The Mobile Access 88 Gateway (MAG) is an access router or gateway that manages the 89 mobility-related signaling for an MN. An MN is attached to the Proxy 90 Mobile IPv6 Domain (PMIPv6-Domain) that includes LMA and MAG(s), and 91 is able to receive data coming from outside of the PMIPv6-Domain 92 through LMA and MAG. 94 Network-based mobility support for unicast is addressed in [RFC5213], 95 while multicast support in PMIPv6 is not discussed in it. In order 96 to deploy the multicast service in the PMIPv6 domain, many schemes 97 have been proposed: 99 The base solution described in [RFC6224] provides options for 100 deploying multicast listener functions in PMIPv6-Domains without 101 modifying mobility and multicast protocol standards. However, in 102 this specification, MAG MUST act as an MLD proxy [RFC4605] and hence 103 MUST dedicate a tunnel link between LMA and MAG to an upstream 104 interface for all multicast traffic. It requires all the LMA to 105 forward multicast packets to MAG via PMIPv6 tunnel which can be 106 suboptimal. 108 [draft-ietf-multimob-pmipv6-ropt-00]uses a multicast tree mobility 109 anchor(MTMA) as the topological anchor point for multicast traffic, 110 as well as a direct routing option where the MAG can provide access 111 to multicast content in the local network. All the multicast traffic 112 has to go through the MAG-MTMA tunnel which result in suboptimal 113 multicast routing path like the base solution. And the direct 114 routing solution needs native multicasting infrastructure as a 115 requirement. 117 [draft-ietf-multimob-pmipv6-source-01]describes the support of 118 multicast senders in Proxy Mobile IPv6 domains. MLD proxy functions 119 are deployed at the MAG. Multicast traffic MUST be tunneled up to 120 the LMA of the multicast sender, transferred to the LMA of the 121 multicast listener and then tunneled downwards to the MAG of the 122 multicast listener. The problem is especially manifested when 123 multicast listener and sender attach to the same MAG but different 124 LMAs, the traffic has to go up to one LMA, cross over to the other 125 LMA, and then be tunneled back to the same MAG, causing non-optimal 126 multicast routes and redundant flows at the MAG.In the direct routing 127 scenario when PIM-SM and PIM-SSM are deployed in MAGs, Source- 128 specific shortest path trees(SPT) have to follow LMA-MAG tunnels 129 towards the multicast sender which can be suboptimal. 131 This document describes multicast routes optimazition mechanisms for 132 multicast sender. Figure 1 shows the Architecture of Multicast 133 Deployment with listener and sender in the same PMIPv6 domain. 135 Internet 136 : 137 | 138 | 139 +-----+ 140 | LMA | Multicast Anchor 141 +-----+ 142 || 143 //\\ 144 // \\ 145 // \\ 146 // \\ 147 // \\ 148 // \\ 149 || || 150 +----+ +----+ 151 |MAG1| |MAG2| 152 +----+ +----+ 153 | | 154 | | 155 +----+ +----+ 156 | MN1| | MN2| 157 +----+ +----+ 158 Multicast Listener(s) Multicast Sender(s) 160 Figure1 Architecture of Multicast Deployment with listener and source 161 in the same PMIPv6 domain 163 The proposed protocol assumes that both LMA and MAG enable the 164 Protocol- Independent Multicast - Sparse Mode (PIM-SM) multicast 165 routing protocol [RFC4601], and further MAG MUST operate as an "SSM- 166 aware" router [RFC4604]. 168 2. Terminology 170 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 171 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 172 document are to be interpreted as described in RFC 2119 [RFC2119]. 174 The following terms used in this document are to be interpreted as 175 defined in [RFC5213]; Home Address(HoA), Mobile Access Gateway (MAG), 176 Local Mobility Anchor (LMA), Mobile Node (MN), Proxy Mobile IPv6 177 Domain (PMIPv6-Domain), LMA Address (LMAA), Proxy Care-of Address 178 (Proxy-CoA), Proxy Binding Update (PBU), and Proxy Binding 179 Acknowledgement (PBA). 181 Terms DR(Designated Router), MRIB(Multicast Routing Information 182 Base), RPF(Reverse Path Forwarding), RPF Neighbor, SPT(shortest-path 183 tree), PIM Join, Pim Prune, iif(incoming interface),oiflist(outgoing 184 interface list), Source-Specific Multicast(SSM) are to be interpreted 185 as defined in[RFC4601] 187 3. Overview 189 In the SSM scenario, the multicast Listeners actively send the (S,G) 190 subscribe message, S is the multicast sender's Home Address (HoA) . 192 Internet 193 : 194 | 195 | 196 +-----+ 197 | LMA | Unicast Anchor 198 +-----+ 199 || 200 // \\ 201 // \\ 202 // \\ Unicast Tunnel 203 // \\ 204 // \\ 205 // \\ 206 || || 207 +----+ +----+ 208 |MAG1|=O=O=O=O=O=O=O=O=O=O|MAG2| 209 +----+ +----+ 210 | Multicast Tunnel | 211 | | 212 +----+ +----+ 213 | MN1| | MN2| 214 +----+ +----+ 215 Multicast Listener(s) Multicast Sender(s) 217 Figure2 Architecture of Optimized Multicast Routing 219 As shown in Figure 2, MN1(the multicast Listener) and MN2(the 220 multicast sender) are both mobile nodes in the same PMIPv6 domain, 221 they both have binding cache entry in the LMA. MN1 sends (S,G) 222 subscribe message(MLD Report messages) to the access link to 223 establish the SPT, MN1 has to operate as an "SSM-aware" host 224 [RFC4604]. On receiving the (S,G) subscribe message from MN1, the 225 attached MAG1 sends a PBU-Q message to LMA to query the CoA (i. e., 226 IP address of MAG2) of MN2. On the reception of PBU-Q, the LMA 227 responds with a PBA-Q message including the CoA of MN2 to MAG1. 228 After acquiring the CoA of MN2, MAG1 establishes bi-directional 229 tunnel with MAG2, and sends PIM Join message to MAG2 through this 230 tunnel, MAG1 and MAG2 establish the ralated muticast state. So the 231 MAG-based SPT is established successfully and the subsequent 232 multicast data flow will be transmitted through the MAG-based SPT 233 which is represented by "=O" in Figure 2. Unicast data flow will be 234 transmitted through base PMIPv6 tunnel which is represented by "||" 235 in Figure 2. 237 The tunnel between MAG1 and MAG2 is used for multicast 238 packets(including signaling and data flow) transmission only. 240 As described in [RFC4601], on receipt of data from S to G on 241 interface iif (incoming interface of the packet), the DR will firstly 242 check whether the source is directly connected and the iif is 243 identical to the Reverse Path Forwarding (RPF) interface. As shown 244 in Figure 2, MAG2 is the DR of MN2, MAG1 is the DR of MN1. After 245 tunnel establishment between MAG1 and MAG2, MAG1 add the tunnel route 246 to the MRIB, the RPF check will be successful. 248 This draft assumes that every MN supporting multicast service is 249 previously registered in the PMIPv6 unicast domain to get a unicast 250 IP address(HoA). 252 4. Protocol Operation 254 4.1. Add Route to MRIB 256 In PIM-SM, the MRIB is used to decide where to send Join/Prune 257 messages. on receiving the MLD Report message from MN,the MAG of MN 258 has to choose a RPF Neighbor that the MRIB indicates should be used 259 to forward packets to, and then send the Join/Prune message to the 260 RPF Neighbor. 262 After tunnel establishment between MAG1 and MAG2, MAG1 add the tunnel 263 route to the MRIB, so that the RPF Neighbor of MAG1 is MAG2, MAG1 264 send PIM Join/Prune message through this tunnel. 266 4.2. Optimized Multicast Route Establishment 268 This section provides the multicast routes optimization procedure.The 269 procedures are described as follows and illustrated in Figure 3. 271 MN1 MAG1 LMA MN2 MAG2 272 | 1. | | | | 273 |--MLD Report->| | | | 274 | (S,G) join | 2. | | | 275 | |------PBU-Q------->| | | 276 | | 3. | | | 277 | |<------PBA-Q-------| | | 278 | |Acquire CoA of MN2 | | | 279 | | | | | 280 | | | | | 281 | | 4. | | 282 | |<=====================================>| 283 | | Establish multicast Bi-dir tunnel | 284 | | | | | 285 | 5. | | | 286 | Add route to MRIB | | | 287 | | | | | 288 | | | | | 289 | 6. | | | 290 | Update (S,G) state | | | 291 | Set iif | | | 292 | | | | | 293 | | 7. | | 294 | | PIM (S,G) join | | 295 | |=============Bi-dir tunnel============>| 296 | | | | | 297 | | | | 8. 298 | | | |Update (S,G) state 299 | | | | Set oiflist 300 | | | | | 301 | | | Multicast data 302 | | 9. |--------->| 303 | | Multicast data | | 304 |Multicast data|<============Bi-dir tunnel=============| 305 |<-------------| | | | 307 Figure3 Procedure of establishing multicast Route 309 1.MN1 sends (S,G) subscribe message to the access link, S is the HoA 310 of MN2. 312 2.On receiving the (S,G) subscribe message from MN1, the attached 313 MAG1 sends a PBU-Q message to LMA to query the CoA (i. e., IP address 314 of MAG2) of MN2. 316 3.On the reception of PBU-Q, the LMA responds with a PBA-Q message 317 including the CoA of MN2. 319 4.After acquire the CoA of MN2, MAG1 establish bi-directional tunnel 320 with MAG2. 322 5.After tunnel establishment, MAG1 add the tunnel route to the MRIB, 323 so that the RPF Neighbor of MAG1 is MAG2. 325 6.If there are multicast channels the MN1 has subscribed but MAG1 has 326 not yet subscribed, MAG1 establishes multicast state for the channel, 327 and sets the iif of the multicast state as MAG1-MAG2 tunnel 328 interface. if MAG1 already subscribed the channel, MAG1 updates the 329 iif of the multicast state as MAG1-MAG2 tunnel interface. 331 7.MAG1 joins the corresponding multicast channels by sending the PIM 332 Join message to the RPF Neighbor MAG2 through the MAG1-MAG2 tunnel. 334 8.On the reception of PIM Join message from MAG1, If MAG2 has not yet 335 subscribed the multicast channel, MAG2 establishes multicast state 336 for the channel, and adds the MAG2-MAG1 tunnel interface to the 337 oiflist of the multicast state. if MAG2 already subscribed the 338 channel, MAG2 updates the oiflist of the multicast state by adding 339 the MAG2-MAG1 tunnel interface to the oiflist. 341 9.The subsequent multicast data flow will be transmitted through the 342 optimized multicast route(MAG1-MAG2 bi-directional tunnel). 344 4.3. Multicast Route Deletion 345 MN1 MAG1 MAG2 346 | 1. | | 347 |--MLD Report->| | 348 | leave (S,G) | | 349 | | | 350 | 2. | 351 |With regard to MN2,MN1 is the | 352 |last multicast listener on MAG1 | 353 | | | 354 | | | 355 | 3. | 356 | delete all the (S,G) state | 357 | ralating to MN2 on MAG1 | 358 | | | 359 | | | 360 | | | 361 | | 4. | 362 | | PIM (S,G) prune | 363 | |=============Bi-dir tunnel============>| 364 | | | 365 | | | 366 | | 5. 367 | | update (S,G) state 368 | | update oiflist 369 | | 6. | 370 | | Remove multicast Bi-dir tunnel | 371 | |<======================================| 372 | | | 374 Figure4 Procedure of deleting multicast Route 376 1.MN1 sends (S,G) leave message(MLD Report messages) to the access 377 link, S is the HoA of MN2. 379 2.On receiving the (S,G) leave message from the MN1, if MAG1 figures 380 that MN1 is the last multicast listener subscribed to the MN2, MAG1 381 perform the following steps, otherwise, MAG1 simply delete the 382 multicast state of MN1 as normal, which is removing MAG1-MN1 383 interface from the oiflist of the multicast state. 385 3.MAG1 delete all the multicast state related to MN2. 387 4.MAG1 remove the tunnel route from the MRIB and leave the 388 corresponding multicast channels by sending the PIM Prune message to 389 the RPF Neighbor MAG2 through the MAG1-MAG2 tunnel. 391 5.On the reception of PIM Prune message from MAG1, MAG2 updates the 392 oiflist of the multicast state by removing the MAG2-MAG1 tunnel 393 interface from the oiflist. 395 6.Remove bi-directional tunnel between MAG1 and MAG2. 397 4.4. Multicast sender handover 399 When the multicast sender handover from the old MAG to a new MAG. 400 From the old MAG, the new MAG gets the addresses of all the distant 401 MAGs(MAGs attached by the multicast listeners that have subscribed to 402 the multicast sender) according to the multicast states that match 403 the moving multicast sender. The new MAG establishes tunnels with 404 the distant MAGs and notify these distant MAGs to update their 405 multicast states so the multicast listeners could receive traffic 406 through the new tunnel between the new MAG and the distant MAGs. 408 TODO details. 410 4.5. Multicast listener handover 412 When the multicast listener handover from the old MAG to a new MAG. 413 From the old MAG, the new MAG gets all the active multicast 414 subscriptions that match the moving multicast listener and then 415 reestablishes the multicast route the same way as describe in section 416 4.2. 418 TODO details. 420 4.6. ASM Scecario 422 In this scenario,PIM-SM first establishes as usual RP-based 423 distribution tree(RPT) and SPT in phase one and phase two. In phase 424 three,the DR(MAG) on the multicast listener's side will choose to 425 initiate a transfer from the shared tree to a source-specific 426 shortest-path tree (SPT). 428 At this point the DR knows the HoA of the multicast sender,it then 429 gets the CoA of the multicast sender from LMA and establishes the 430 shortest path tree the way as described in section 4.2. 432 TODO details. 434 5. Local Mobility Anchor Operation 436 On receiving a PBU-Q message from MAG1, the LMA must perform the 437 following operations. 439 1.Check if the PBU-Q message contains the Q flag set to 1. 441 2.Query the CoA of MN2 by looking up the binding cache of LMA. 443 3.If the corresponding HoA-CoA entry is found in the binding cache, 444 LMA will respond PBA-Q message containing a success indication. 445 Otherwise, if not found, LMA will respond PBA-Q message containing a 446 failure indication. 448 The responding PBA-Q message from LMA to MAG1 is constructed as 449 follows. 451 1.Source address field in the IP header must be set to IP address of 452 LMA. 454 2.Destination address filed in the IP header must be set to IP 455 address of the MAG1. 457 3.The PBA-Q message MUST include the CoA of MN2. 459 6. Mobile Access Gateway Operation 461 The MAG MUST operate as an "SSM-aware" router. [RFC4604] provide the 462 behavior of an "SSM-aware" router. 464 6.1. MN1 and MN2 attach to the same MAG 466 On receiving the (S,G) subscribe message from the MN1, MAG1 could 467 decide whether MN2 attachs to itself according to MN2's HoA which is 468 included in the (S,G) subscribe message. If MAG1 figures that MN1 469 and MN2 both attach to it. MAG1 operates as below: 471 If there are multicast channels the MN1 has subscribed but MAG1 has 472 not yet subscribed, MAG1 establishes multicast state for the 473 channel,and adds the MAG1-MN1 interface to the oiflist of the 474 multicast state. 476 If MAG1 already subscribed the channel, MAG1 updates the oiflist of 477 the multicast state by adding the MAG1-MN1 interface to the oiflist. 479 MAG1 will send the multicast data flow from MN2 to MN1 locally. 481 6.2. MN1 and MN2 attach to different MAG 483 The PBU-Q message from MAG1 to LMA MUST be constructed, as specified 484 below. 486 1.Source address field in the IP header must contain the IP address 487 of MAG1. 489 2.Destination address filed in the IP header must contain the IP 490 address of LMA. 492 3.The PBU-Q message must include the HoA of MN2. 494 On receiving a PBA-Q message from LMA, MAG1 MUST perform the 495 following operations. 497 1.Check if the PBA-Q message contains the Q flag set to 1. 499 2.MAG1 MUST establish a tunnel with MAG2 for muticast data delivery. 501 3.MAG1 MUST add route to Multicast Routing Information Base (MRIB) 502 and send PIM Join/Prune messages through MAG1-MAG2 tunnel interface. 504 4.MAG1 MUST create/update multicast state for the channel, the iif of 505 the multicast state MUST be set to MAG1-MAG2 tunnel interface. 507 On receiving a PIM Join/Prune messages from MAG2-MAG1 tunnel 508 interface, MAG2 MUST create/update multicast state for the channel. 510 1.Add MAG2-MAG1 tunnel interface to the oiflist of the multicast 511 state on receiving a PIM Join message from MAG2-MAG1 tunnel 512 interface. 514 2.Delete MAG2-MAG1 tunnel interface from the oiflist of the multicast 515 state on receiving a PIM Prune message from MAG2-MAG1 tunnel 516 interface. 518 7. Mobile Node Operation 520 The MN MUST operate as an "SSM-aware" host . [RFC4604] provide the 521 behavior of an "SSM-aware" host. 523 8. Message Format Extension 525 8.1. Proxy Binding Update with Source Address Query Extension 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Sequence # | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 |A|H|L|K|M|R|P|Q| Reserved | Lifetime | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | | 534 . . 535 . Mobility Options . 536 . . 538 | | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure5 Proxy Binding Update with Source Address Query Extension 543 A Binding Update message that is sent by MAG to LMA is referred to as 544 the "Proxy Binding Source Address Query" message. A new flag (Q) is 545 included in the Proxy Binding Update message with Source Address 546 Query extension (PBU-Q). The rest of the Binding Update message 547 format remains the same as defined in[RFC3775] and with the 548 additional (R), (M), and (P) flags, as specified in [RFC3963], 549 [RFC4140], and [RFC5213], respectively. 551 Source Address Query Flag 553 A new flag (Q) is included in the Binding Update message to indicate 554 to LMA that the Binding Update message is a Source Address Query 555 message. In the normal PMIP operation, the flag must be set to 0. 557 The PBU-Q message is transfered for quering the MN2's CoA. The rest 558 of the PBU message remains unchanged. 560 8.2. Proxy Binding Acknowledgement Message with Source Address Query 561 Extension 562 0 1 2 3 563 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 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 | Status |K|R|P|Q|Reserve| 566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 567 | Sequence # | Lifetime | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 | | 570 . . 571 . Mobility Options . 572 . . 574 | | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 Figure6 Proxy Binding Update with Source Address Query Extension 579 A "Proxy Binding Acknowledgement" message is sent from LMA to MAG in 580 response to a Proxy Binding Update message. A new flag (Q) is 581 included in the Proxy Binding Acknowledgement message with Source 582 Address Query extension (PBA-Q). The rest of the Binding 583 Acknowledgement message format remains the same as defined in 584 [RFC3775] and with the additional (R) flag, as specified in [RFC3963] 585 and [RFC5213], respectively. 587 Source Address Query Flag 589 A new flag (Q) is included in the Binding Acknowledgement message to 590 indicate to MAG that the Binding Acknowledgement message is a Source 591 Address Query message. In the normal PMIP operation, the flag must 592 be set to 0. 594 When (Q) flag is specified in PBA-Q message, the mobility options 595 field includes "MN2's CoA"(Section 8.3). 597 8.3. Care-of Address Option 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Type = TBD | Length = 16 | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | 604 + + 605 | | 606 + Care-of Address + 607 | | 608 + + 609 | | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 Figure7 Care-of Address Option 614 The Care-of Address field contains the care-of address of MN2. 616 This option is valid only in PBA-Q message. On the reception of 617 PBU-Q, the LMA responds with a PBA-Q message including the Care-of 618 Address Option. 620 9. Security Considerations 622 TBD 624 10. IANA Considerations 626 11. Normative References 628 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 629 Requirement Levels", BCP 14, RFC 2119, March 1997. 631 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 632 in IPv6", RFC 3775, June 2004. 634 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 635 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 636 January 2005. 638 [RFC4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 639 Bellier, "Hierarchical Mobile IPv6 Mobility Management 640 (HMIPv6)", August 2005. 642 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 643 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 644 Protocol Specification (Revised)", August 2006. 646 [RFC4604] Holbrook, H., Cain, B., and B. Haberman, "Using Internet 647 Group Management Protocol Version 3 (IGMPv3) and Multicast 648 Listener Discovery Protocol Version 2 (MLDv2) for Source- 649 Specific Multicast", August 2006. 651 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 652 "Internet Group Management Protocol (IGMP) / Multicast 653 Listener Discovery (MLD)-Based Multicast Forwarding 654 ("IGMP/MLD Proxying")", August 2006. 656 [RFC5213] Gundavelli, S, Ed., Leung, K., Devarapalli, V., Chowdhury, 657 K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, 658 August 2008. 660 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 661 Deployment for Multicast Listener Support in Proxy Mobile 662 IPv6 (PMIPv6) Domains", April 2011. 664 [draft-ietf-multimob-pmipv6-ropt-00] 665 Zuniga, JC., Contreras, LM., Bernardos, CJ., and S. Jeon, 666 "Multicast Mobility Routing Optimizations for Proxy Mobile 667 IPv6", March 2012. 669 [draft-ietf-multimob-pmipv6-source-01] 670 Schmidt, TC., Gao, S., Zhang, H., and M. Waehlisch, 671 "Mobile Multicast Sender Support in Proxy Mobile IPv6 672 (PMIPv6) Domains", July 2012. 674 Authors' Addresses 676 Juan Liu 677 ZTE Corporation 678 RD Building 1,Zijinghua Road No.68 679 Yuhuatai District,Nanjing 210012 680 P.R.China 682 Email: liu.juan45@zte.com.cn 683 Wen Luo 684 ZTE Corporation 685 RD Building 1,Zijinghua Road No.68 686 Yuhuatai District,Nanjing 210012 687 P.R.China 689 Email: luo.wen@zte.com.cn