idnits 2.17.1 draft-contreras-multimob-rams-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1409 has weird spacing: '...dresses set t...' -- The document date (March 10, 2012) is 4424 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3775 (ref. '3') (Obsoleted by RFC 6275) == Outdated reference: A later version (-08) exists of draft-ietf-multimob-pmipv6-ropt-00 == Outdated reference: A later version (-06) exists of draft-ietf-multimob-igmp-mld-tuning-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group Luis M. Contreras 3 INTERNET-DRAFT (Telefonica I+D) 4 Intended Status: Experimental Carlos J. Bernardos 5 Expires: September 11, 2012 (Universidad Carlos III de Madrid) 6 Ignacio Soto 7 (Universidad Politecnica de Madrid) 8 March 10, 2012 10 PMIPv6 multicast handover optimization by the 11 Request of Active Multicast Subscription (RAMS) 12 14 Abstract 16 This document specifies a multicast handover optimization mechanism 17 for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic 18 to mobile nodes after handovers. The mechanism is based on speeding 19 up the acquisition of mobile nodes' active multicast subscriptions 20 information by the mobile access gateways. To do that, extensions to 21 the current Proxy Mobile IPv6 protocol are proposed. These extensions 22 are not only applicable to the base solution for multicast support in 23 Proxy Mobile IPv6, but also can be applied to other solutions 24 envisioned as possible architectural evolutions of it. Furthermore, 25 they are also independent of the role played by the mobile access 26 gateway within the multicast network (either acting as multicast 27 listener discovery proxy or multicast router). 29 Status of this Memo 31 This Internet-Draft is submitted to IETF in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as 37 Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/1id-abstracts.html 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html 49 Copyright and License Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 68 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3 PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . . . 8 70 3.1. New mobility option . . . . . . . . . . . . . . . . . . . . 8 71 3.1.1. New "Active Multicast Subscription" mobility option . . 8 72 3.1.1.1. Option application rules . . . . . . . . . . . . . 8 73 3.1.1.2. Option format . . . . . . . . . . . . . . . . . . . 8 74 3.2. New flags . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.2.1. New "multicast Signaling" flag on PBU/PBA message 76 headers . . . . . . . . . . . . . . . . . . . . . . . . 9 77 3.2.1.1. Flag application rules . . . . . . . . . . . . . . 9 78 3.2.1.1.1. Registration process . . . . . . . . . . . . . 10 79 3.2.1.1.2. De-registration process . . . . . . . . . . . . 11 80 3.2.1.2. New format of conventional PBU/PBA messages . . . . 11 81 3.2.1.2.1. Proxy Binding Update Message . . . . . . . . . 11 82 3.2.1.2.2. Proxy Binding Acknowledgement Message . . . . . 12 83 3.2.2. New "multicast Active" flag in the LMA Binding Cache 84 and (optionally) on the MN's policy store . . . . . . . 12 85 3.2.2.1. Flag application rules . . . . . . . . . . . . . . 12 86 3.3. New messages . . . . . . . . . . . . . . . . . . . . . . . 13 87 3.3.1. New messages for active multicast subscription 88 interrogation . . . . . . . . . . . . . . . . . . . . . 13 89 3.3.1.1. Subscription Query message . . . . . . . . . . . . 14 90 3.3.1.1.1. Message application rules . . . . . . . . . . . 14 91 3.3.1.1.2. Message format . . . . . . . . . . . . . . . . 14 92 3.3.1.2. Subscription Response message . . . . . . . . . . . 15 93 3.3.1.2.1. Message application rules . . . . . . . . . . . 15 94 3.3.1.2.2. Message format . . . . . . . . . . . . . . . . 15 95 3.3.2. New messages for active multicast subscription 96 indication . . . . . . . . . . . . . . . . . . . . . . 16 97 3.3.2.1. Multicast Activity Indication message . . . . . . . 16 98 3.3.2.1.1. Message application rules . . . . . . . . . . . 16 99 3.3.2.1.2. Message format . . . . . . . . . . . . . . . . 17 100 3.3.2.2. Multicast Activity Indication Acknowledge message . 18 101 3.3.2.2.1. Message application rules . . . . . . . . . . . 18 102 3.3.2.2.2. Message format . . . . . . . . . . . . . . . . 18 103 3.4. New "PBA timer" in the LMA . . . . . . . . . . . . . . . . 19 104 4 Signaling processes description . . . . . . . . . . . . . . . . 20 105 4.1. Multicast Activity signaling . . . . . . . . . . . . . . . 20 106 4.1.1. Multicast Activity set to ON (A=1) . . . . . . . . . . 20 107 4.1.2. Multicast Activity set to OFF (A=0) . . . . . . . . . . 21 108 4.2. Handover signaling procedures . . . . . . . . . . . . . . . 21 109 4.2.1. Handover of proactive type . . . . . . . . . . . . . . 22 110 4.2.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . 22 111 4.2.1.2. Message flow description . . . . . . . . . . . . . 22 112 4.2.2. Handover of reactive type . . . . . . . . . . . . . . . 24 113 4.2.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . 24 114 4.2.2.2. Message flow description . . . . . . . . . . . . . 25 115 4.2.2.3. Further considerations for the reactive handover 116 signaling . . . . . . . . . . . . . . . . . . . . . 28 117 4.2.3. LMA decision process . . . . . . . . . . . . . . . . . 28 118 4.2.3.1. LMA processing of S flag on reception of PBU 119 messages . . . . . . . . . . . . . . . . . . . . . 29 120 4.2.3.1.1. Proactive handover . . . . . . . . . . . . . . 29 121 4.2.3.1.2. Reactive handover . . . . . . . . . . . . . . . 29 122 4.2.3.2. LMA set-up of S flag in PBA messages . . . . . . . 30 123 4.2.4. Prevention of large delays of the binding 124 acknowledgement for unicast traffic . . . . . . . . . . 31 125 5. Co-existence with PMIPv6 multicast architectural evolutions . . 34 126 6. Benefits of layer-2 triggers for fast handover . . . . . . . . 34 127 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 35 128 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 35 129 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 130 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 131 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 132 11.1 Normative References . . . . . . . . . . . . . . . . . . . 36 133 11.2 Informative References . . . . . . . . . . . . . . . . . . 36 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37 136 1 Introduction 138 The base solution describing how continuous multicast service 139 delivery can be provided in Proxy Mobile IPv6 domains is described in 140 RFC 6224 [4]. This solution specifies the basic functionality needed 141 in the Proxy Mobile IPv6 entities to provide a multicast service, and 142 supports the continuous delivery of multicast traffic by obtaining, 143 after a handover, the on-going multicast subscription information 144 directly from the mobile node. When a mobile node attaches to a new 145 mobile access gateway, the mobile node is interrogated by the mobile 146 access gateway through a multicast listener discovery General Query, 147 which is sent just after any new link is set up, to get knowledge of 148 any existing subscription, as specified in [2]. 150 However, as highlighted by [5], the base solution needs to be 151 improved to meet some performance requirements, especially those 152 referred to the user perceived service quality, which is seriously 153 affected by the disruption of multicast content forwarding to the 154 mobile node during handovers. 156 A mobile node with an active multicast subscription, moving from one 157 point of attachment to another within a Proxy Mobile IPv6 domain, 158 experiences a certain delay until it resumes receiving again the 159 multicast content that it was receiving at the previous location. 160 Such delay causes a gap in the content reception. Two different 161 actions can help to mitigate such reception gap. One of them is to 162 buffer at the previous mobile access gateway the traffic with 163 destination at the mobile node and forward it to the new mobile 164 access gateway, in order to deliver that traffic to the mobile node. 165 The other possible (complementary) action is to reduce the time 166 needed by the new mobile access gateway to get knowledge of the 167 active multicast subscription of the mobile node (i.e., the IP 168 addresses of the multicast groups subscribed and the sources 169 providing them), so the new mobile access gateway can subscribe to 170 the multicast group(s) on behalf of the mobile node as soon as 171 possible. 173 While the first mechanism can be accomplished by using [7] or some 174 evolution of it (despite being only applicable in the case the 175 underlying radio access technology supports layer-2 triggers, and it 176 requires additional support on the mobile node), there is no a 177 generic standard solution for the accelerated acquisition of the on- 178 going multicast subscription of the mobile node. 180 The approach followed by the base solution [4] to get knowledge of an 181 existing multicast subscription relies on the behavior of the 182 IGMP/MLD protocols. Both protocols send multicast membership 183 interrogation messages when a new link is up. The response to that 184 request reports any existing multicast subscription by the mobile 185 node. While this is a straightforward approach, it also causes that 186 the mobile access gateway can incur in a non-negligible delay in 187 receiving the corresponding MLD Report message. This delay is caused 188 by the time needed for the detection of the attachment in the new 189 link, the radio transfer delays associated with the signaling to the 190 mobile node, and the MLD query response interval time required by 191 this procedure (whose default value is 10 seconds as defined in [2], 192 or between 5 and 10 seconds as considered in the best case wireless 193 link scenario in [8]). 195 This document extends the Proxy Mobile IPv6 signaling protocol 196 defined in the base protocol [1] by including a new multicast 197 information option to update Proxy Mobile IPv6 entities during the 198 registration and de-registration processes, and new messages to 199 trigger the transfer of multicast information. No extension is 200 required in any of the multicast-related protocols in use (IGMP/MLD 201 or PIM protocols). This document provides a signaling method internal 202 to the network to speed up the subscription information acquisition 203 by the mobile access gateway, in order to accelerate the multicast 204 delivery to the mobile node after having completed a handover. By 205 doing so, the knowledge by the mobile access gateway of the currently 206 active multicast subscription becomes independent of the underlying 207 radio technology dynamics and relaxes the requirement of a rapid 208 response from the mobile node in processing MLD control messages. 209 Issues like radio framing, radio access contention, channel 210 reliability, MN's capabilities (i.e., layer-2 triggering support), 211 IGMP/MLD timers optimization for wireless environments, etc, do not 212 impact on the observed multicast performance during handovers. 214 The solution described in this document is not only applicable to the 215 base solution defined in [4], but also it can be applied to other 216 solutions envisioned as possible architectural evolutions of it, as 217 those stated in [6]. Furthermore, it is also independent of the role 218 played by the mobile access gateway within the multicast network 219 (either acting as MLD proxy or multicast router). 221 1.1 Terminology 223 This document uses the terminology referring to PMIPv6 components as 224 defined in [1]. 226 Additionally, the following terms are defined. 228 pMAG 229 The previous MAG or pMAG is the MAG where the MN is initially 230 registered in a handover event. 232 nMAG 233 The new MAG or nMAG is the MAG where the MN is registered at the 234 end of the handover event. 236 Reactive Handover 237 A reactive handover is a handover event in which the LMA receives 238 the MN registration from the nMAG without having previously 239 received the MN de-registration from the pMAG. 241 Proactive handover 242 A proactive handover is a handover event where the LMA 243 receives the MN de-registration from the pMAG previously to 244 receive the MN registration from the nMAG. 246 2. Overview 248 The LMA is a key element within the PMIPv6 infrastructure, which 249 traces the MN reachability along the PMIPv6 domain. Therefore the LMA 250 is the best element to maintain the MNs' multicast subscription 251 information updated and to forward it to the rest of PMIPv6 entities 252 (i.e., to the MAGs) as needed when MNs move within the domain. The 253 LMA has timely knowledge of the MNs' location, especially during 254 handover events, and it is therefore able to quickly provide 255 information to the new one point of attachment (querying the previous 256 one if required). 258 The LMA only obtains the detailed subscription information (in terms 259 of the IP addresses of both the multicast group subscribed, G, and 260 the source delivering it, S) during a handover event. There is no 261 need of continuously informing the LMA about MNs' multicast state 262 while the mobile nodes remain attached to the same mobile access 263 gateway. Such a continuous updating procedure would significantly 264 increase the signaling load within the PMIPv6 domain without a clear 265 benefit. The subscription information (S,G) is only critical during 266 handovers, neither after nor before. Indicating the active 267 subscription while the handover is ongoing guarantees that such 268 information will be up-to-date, ready to be transferred to the new 269 MAG where the MN has just attached. 271 To be able to transfer the multicast subscription information between 272 PMIPv6 entities during a handover, this document extends the PMIPv6 273 protocol in several ways. First of all, a new mobility option is 274 defined to carry the IP addresses of the current multicast 275 subscription. Furthermore, additional messages are defined to manage 276 the interchange of the multicast information among PMIPv6 entities. 277 Finally, some flags are defined to govern the process. 279 Next sections provide the details of these Proxy Mobile IPv6 protocol 280 extensions. 282 3 PMIPv6 extensions 284 This section outlines the extensions proposed to the PMIPv6 protocol 285 specified in [1]. 287 3.1. New mobility option 289 3.1.1. New "Active Multicast Subscription" mobility option 291 3.1.1.1. Option application rules 293 A new TLV-encoded mobility option, "Active Multicast Subscription" 294 option is defined for use with the PBU (Proxy Binding Update) and PBA 295 (Proxy Binding Acknowledge) messages exchanged between an LMA and a 296 MAG to transfer the multicast subscription information. This option 297 is used for exchanging the IP addresses of both the group subscribed 298 to by the MN, and the source delivering it. There can be multiple 299 "Active Multicast Subscription" options present in the message, one 300 for each active subscription maintained by the MN when the handover 301 is taking place. 303 This option does not include specific information about the 304 applicable filter mode defined in [9]. After the handover process, 305 the MN has to receive the same multicast flow being received before 306 the handover initiation (in terms of the (S,G) duple), then the 307 filter mode information is not strictly critical to accelerate the 308 reception of the multicast flow at the new point of attachment. This 309 information can be, however, retrieved later through the response 310 message to the MLD Query sent by the nMAG once the point-to-point 311 link of the entering MN is set-up, as defined in [4]. 313 This new option will be also used, with the same aim, by the new 314 message Subscription Response described later in this document. 316 3.1.1.2. Option format 318 The format of this new option is as follows: 320 0 1 2 3 321 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 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | Type | Length | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | | 326 + Multicast Source IP address + 327 | | 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | | 330 + Multicast Group IP address + 331 | | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 Type 335 To be defined 337 Length 338 8-bit unsigned integer indicating the length of the option in 339 octects, excluding the type and length fields. This field must be 340 set to the value 8 for IPv4, and 32 for IPv6. 342 Multicast Source IP address 343 Unicast IP address of the node which injects the multicast content 344 in the network. Multicast Group IP address. 346 Multicast Group IP address 347 Multicast IP address identifying the content which the MN 348 subscribes to. 350 3.2. New flags 352 Two new flags are defined and used to handle the forwarding of 353 multicast subscription information. 355 3.2.1. New "multicast Signaling" flag on PBU/PBA message headers 357 3.2.1.1. Flag application rules 359 A new flag S is added in both PBU and PBA message headers to advise 360 about the MAG and the LMA capabilities of processing multicast- 361 related signaling for the MN that caused the message. 363 This flag will govern the multicast-related signaling between the LMA 364 and the MAG. As a general rule, the value of the flag in the PBA 365 message should be a copy of the value received in the PBU message. 366 Specific rules are described in next sub-sections. 368 3.2.1.1.1. Registration process 370 During handover, the entities involved in this process are the nMAG 371 and the LMA. These rules also apply for the Initial Binding 372 registration process. 374 o PBU message 376 * S=0, it indicates that the MAG sending the PBU message does not 377 accept multicast-related signaling for the MN being attached. This 378 can be used to discriminate PMIPv6 nodes which are not multicast 379 enabled, for backward compatibility reasons. 381 * S=1, it indicates that the MAG sending the PBU message accepts 382 multicast-related signaling for the MN being attached. Depending 383 on the type of handover (reactive or proactive) the LMA will take 384 some actions, described later in this document. 386 o PBA message 388 * If S=0 in the corresponding PBU message, the value of the flag 389 in the PBA message should be a copy of the value received in the 390 PBU message (thus S=0), without any further meaning. 392 * If S=1 in the corresponding PBU message, two sub-cases can 393 happen 395 - S=1 and "Active Multicast Subscription" mobility option in 396 the PBA message. When the MN maintains an active multicast 397 session, if the LMA is able to provide the multicast 398 subscription information during registration, the PBA message 399 will include the "Active Multicast Subscription" mobility 400 option with the IP addresses of the subscribed group and the 401 source providing it. If the LMA is not able to provide such 402 information during registration, the PBA message will include 403 the "Active Multicast Subscription" mobility option with the IP 404 addresses of the group and the source set to 0. This case is 405 useful to decouple unicast and multicast signaling for an MN 406 being registered at nMAG. A way for obtaining later active 407 multicast-subscription information is described later in this 408 document. 410 - S=0 in the PBA message if the MN does not maintain an active 411 multicast subscription (note that for backward compatibility 412 reasons an LMA not supporting multicast related signaling would 413 always send S=0). 415 3.2.1.1.2. De-registration process 417 During handover, the entities involved in this process are the pMAG 418 and the LMA. These rules apply for the Binding De-registration 419 process 421 o PBU message 423 * S=0, it indicates that the MN has no active multicast session 424 (note that for backward compatibility reasons a pMAG not 425 supporting multicast related signaling would always send S=0). 427 * S=1, it indicates that the MN has an active multicast session, 428 and the IP addresses of the subscribed group and the source 429 providing it are transported in the "Active Multicast 430 Subscription" mobility option. 432 o PBA message 434 The value of the flag in the PBA message should be 0, without any 435 further meaning (note that for backward compatibility reasons an LMA 436 not supporting multicast related signaling would always send S=0). 438 3.2.1.2. New format of conventional PBU/PBA messages 440 3.2.1.2.1. Proxy Binding Update Message 442 As result of the new defined flag, the PBU message results as 443 follows: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Sequence # | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |A|H|L|K|M|R|P|S| Reserved | Lifetime | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | | 453 . . 454 . Mobility options . 455 . . 456 | | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 3.2.1.2.2. Proxy Binding Acknowledgement Message 461 As result of the new defined flag, the PBA message results as 462 follows: 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Status |K|R|P|S| Rsrvd | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Sequence # | Lifetime | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | | 472 . . 473 . Mobility options . 474 . . 475 | | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 3.2.2. New "multicast Active" flag in the LMA Binding Cache and 479 (optionally) on the MN's policy store 481 3.2.2.1. Flag application rules 483 A new flag A is added in the LMA Binding Cache to retain the 484 knowledge that the registered MN maintains or not an active multicast 485 subscription. The basic use of this flag is to restrict the 486 interrogation of the pMAG only to the cases in which the MN certainly 487 is maintaining an active subscription. The algorithm which is 488 followed by the LMA to interrogate or not the pMAG (after receiving a 489 PBU message from the nMAG) is as follows: 491 - Flag S=0 & flag A=0: this situation represents the case where 492 the nMAG does not support multicast-related signaling for the MN 493 being registered, and, additionally, the LMA is not aware of any 494 active multicast subscription on-going. Then, the LMA does not 495 interrogate the pMAG, and registers the MN as attached to the nMAG 496 as usual. 498 - Flag S=0 & flag A=1: this situation represents the case where 499 the nMAG does not support multicast-related signaling for the MN 500 being registered, but the LMA is aware of one or more on-going 501 MN's active multicast subscriptions. Due to the fact that 502 multicast signaling is not supported by the nMAG for that MN, the 503 LMA does not interrogate the pMAG, and registers the MN as 504 attached to the nMAG as usual. 506 - Flag S=1 & flag A=0: this situation represents the case where 507 the nMAG supports multicast-related signaling for the MN being 508 registered, but the LMA is not aware of any active multicast 509 subscription. Then, the LMA does not interrogate the pMAG, and 510 registers the MN as attached to the nMAG as usual. 512 - Flag S=1 & flag A=1: this situation represents the case where 513 the nMAG supports multicast-related signaling for the MN being 514 registered, and, additionally, the LMA is aware of one or more on- 515 going MN's active multicast subscriptions. Then, the LMA 516 interrogates the pMAG to obtain the multicast subscription details 517 in the form of (S,G) previously to complete the registration of 518 the MN attached to the nMAG. 520 The flag A should be initialized to the value 0. 522 Optionally, this flag can be also added to the MN's policy store, and 523 dynamically updated by the LMA to signal that the MN has (or not) an 524 active multicast subscription. By introducing this flag in the MN's 525 policy profile, the nMAG can know in advance the existence of an 526 active multicast session by the incoming MN. 528 3.3. New messages 530 3.3.1. New messages for active multicast subscription interrogation 532 A new pair of messages is defined for interrogating entities about 533 the active multicast subscription of the MN when the handover is of 534 reactive type. 536 These messages are sent using the Mobility Header as defined in [3]. 538 3.3.1.1. Subscription Query message 540 3.3.1.1.1. Message application rules 542 The Subscription Query message is sent by the LMA towards the pMAG to 543 interrogate it about any existing multicast subscription of the MN 544 which is being registered by the nMAG. This message is generated in 545 case that the handover is of reactive type. 547 Additionally, this message is sent by the nMAG towards the LMA to 548 interrogate it about the existing multicast subscription of the MN 549 when the LMA acknowledges the PBU sent by the nMAG but the multicast 550 information is not provided (in detail, when the PBU messages has set 551 the flag S to 1, and the PBA message has set the flag S to 1 but the 552 IP addresses of the group and the source in the "Active Multicast 553 Subscription" mobility option are set to 0). 555 3.3.1.1.2. Message format 557 The Subscription Query message has the following format. 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Sequence # | Reserved | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | | 565 . . 566 . Mobility options . 567 . . 568 | | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 Sequence Number 573 The Sequence Number field establishes the order of the messages 574 sent in the Subscription Query / Subscription Response dialogue 575 between the LMA and the MAG for a certain MN. The initial Sequence 576 Number will be determined by the entity which creates the message 577 (either LMA or MAG, depending on the scenario), which will be 578 responsible of managing this counter. 580 Reserved 582 This field is unused for now. The value must be initialized to 0. 584 Mobility options 586 This message will carry one or more TLV-encoded mobility options. 587 The valid mobility options for this message are the following: 589 - Mobile Node Identifier option (mandatory) 591 - Home Network Prefix option (optional) 593 There can be one or more instances of the Home Network Prefix 594 option, but only one instance of the Mobile Node Identifier 595 option. 597 3.3.1.2. Subscription Response message 599 3.3.1.2.1. Message application rules 601 The Subscription Response message is sent by the pMAG towards the 602 LMA, or by the LMA towards the nMAG, to answer a previously received 603 Subscription Query message, as described above. 605 3.3.1.2.2. Message format 607 The Subscription Response message has the following format. 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Sequence # |I| Reserved | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | | 615 . . 616 . Mobility options . 617 . . 618 | | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 Sequence Number 623 The value of the Sequence Number field in the Subscriber Response 624 message must be a copy of the Sequence Number received in the 625 Subscription Query message. 627 Multicast Information (I) 629 The multicast Information flag I specifies if there is multicast 630 subscription information available for the MN or not. The meaning 631 is the following: 633 I=0: there is no multicast subscription information available for 634 the MN identified by the Mobile Node Identifier option in this 635 message. 637 I=1: there is multicast subscription information available for the 638 MN identified by the Mobile Node Identifier option in this 639 message. The multicast subscription information is carried on one 640 or more instances of the Active Multicast Subscription option in 641 this message (one instance for each active subscription). 643 Reserved 645 This field is unused for now. The value must be initialized to 0. 647 Mobility options 649 This message will carry one or more TLV-encoded mobility options. 650 The valid mobility options for this message are the following: 652 - Mobile Node Identifier option (mandatory) 654 - Active Multicast Subscription option (mandatory) only when 655 flag I=1, not present in any other case 657 - Home Network Prefix option (optional) 659 There can be one or more instances of the Home Network Prefix 660 option (in all cases) and the Active Multicast Subscription option 661 (only when I=1), but only one instance of the Mobile Node 662 Identifier option. 664 3.3.2. New messages for active multicast subscription indication 666 A new pair of messages is defined for setting up and down the 667 optional A flag defined above. 669 These messages are sent using the Mobility Header as defined in [3]. 671 3.3.2.1. Multicast Activity Indication message 673 3.3.2.1.1. Message application rules 675 The Multicast Activity Indication message is sent by a MAG towards 676 the LMA to set to 1 or 0 the A flag either to indicate the start or 677 the complete cease of any multicast subscription by the MN. Through 678 the use of this message, the LMA becomes aware that one or more 679 multicast flows are being forwarded to a MN. This information is 680 useful for the LMA during a handover to discriminate if the pMAG 681 should be asked or not about multicast information corresponding to 682 the MN being registered at the nMAG, in case that the handover is of 683 reactive type. 685 3.3.2.1.2. Message format 687 The Multicast Activity Indication message has the following format. 689 0 1 2 3 690 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 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 692 | Sequence # |A| Reserved | 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | | 695 . . 696 . Mobility options . 697 . . 698 | | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 Sequence Number 703 The Sequence Number field establishes the order of the messages 704 sent in the Activity Indication / Activity Indication Ack dialogue 705 between the MAG and the LMA for a certain MN. The initial Sequence 706 Number will be determined by the MAG, which will be responsible of 707 managing this counter. 709 Activity indicator (A) 711 The Activity indicator flag A specifies if the MN multicast 712 activity is on, that is, if the MN maintains one or more active 713 multicast subscriptions at the MAG. The meaning is the following: 715 A=0: the multicast activity of the MN (identified by the Mobile 716 Node Identifier option in this message) is off. 718 A=1: the multicast activity of the MN (identified by the Mobile 719 Node Identifier option in this message) is on. 721 Reserved 723 This field is unused for now. The value must be initialized to 0. 725 Mobility options 727 This message will carry one or more TLV-encoded mobility options. 728 The valid mobility options for this message are the following: 730 - Mobile Node Identifier option (mandatory) 732 - Home Network Prefix option (optional) 734 There can be one or more instances of the Home Network Prefix 735 option, but only one instance of the Mobile Node Identifier 736 option. 738 3.3.2.2. Multicast Activity Indication Acknowledge message 740 3.3.2.2.1. Message application rules 742 The Multicast Activity Indication Acknowledge message is sent by the 743 LMA towards a MAG to confirm the reception of a previously sent 744 Multicast Activity Indication message. 746 3.3.2.2.2. Message format 748 The Multicast Activity Indication message has the following format. 750 0 1 2 3 751 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 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Sequence # | Reserved | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | | 756 . . 757 . Mobility options . 758 . . 759 | | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 762 Sequence Number 764 The value of the Sequence Number field in the Activity Indication 765 Ack message must be a copy of the Sequence Number received in the 766 Activity Indication message. 768 Reserved 770 This field is unused for now. The value must be initialized to 0. 772 Mobility options 774 This message will carry one or more TLV-encoded mobility options. 775 The valid mobility options for this message are the following: 777 - Mobile Node Identifier option (mandatory) 779 - Home Network Prefix option (optional) 781 There can be one or more instances of the Home Network Prefix 782 option, but only one instance of the Mobile Node Identifier 783 option. 785 3.4. New "PBA timer" in the LMA 787 A new timer named "PBA timer" is used in the LMA to define the 788 maximum waiting time before the PBA message is sent to the nMAG in 789 case the multicast subscription information relative to the MN is not 790 yet available. The aim of this timer is to prevent potential large 791 delays in the forwarding of unicast traffic towards the MN being 792 registered at the nMAG. This timer allows decoupling the unicast 793 signaling from the multicast one. 795 This timer should be upper bounded by the constant defined in [3] 796 INIT_BINDACK_TIMEOUT, whose default value is 1 s. This constant sets 797 the time when the nMAG will retry the MN registration by sending 798 again the PBU message. The "PBA timer" has to ensure that the nMAG 799 does not enter the retry mode. 801 4 Signaling processes description 803 A number of new signaling processes are introduced with this 804 solution. Next sections describe these new processes in detail. 806 4.1. Multicast Activity signaling 808 This solution makes use of the flag A to keep track of existing 809 multicast activity in a certain MN. The idea behind this is to define 810 a mechanism which helps the LMA to decide whether to interrogate or 811 not the pMAG about potential subscription information. 813 4.1.1. Multicast Activity set to ON (A=1) 815 The figure 1 summarizes this process. 817 +-----+ +-----+ +-----+ 818 | MN1 | | MAG | | LMA | 819 +-----+ +-----+ +-----+ 820 | | | 821 1) | |==Bi-Dir Tunnel=| 822 | | | 823 | unicast data | | 824 |<-v-v-v-v-v-v-v-| | 825 | | | 826 | MLD Rep(S,G) | | 827 |--------------->| Act Ind(start) | 828 2) | |--------------->| 829 | (S,G) Data | (flag A = 1) 830 |<---------------| Act Ind Ack | 831 | |<---------------| 832 | | | 834 Figure 1. Multicast Activity set to ON 836 The sequence of messages is the following: 838 1) A MN, named MN1, is attached to the MAG. The MN is a multicast- 839 enabled node, and it is only receiving unicast traffic as usual in 840 PMIPv6 domains, with no multicast subscription yet. At some point 841 in time, the MN1 requests to the MAG to be subscribed to the 842 content identified by the IP addresses (S,G), by sending a 843 standard MLD report from the MN to the MAG. The MAG will keep the 844 multicast status state of the point-to-point link with the MN. In 845 case the MAG has not already subscribed to the multicast flow 846 (S,G) it joins the content on behalf of MN. Multicast flow (S,G) 847 is subsequently forwarded by the MAG to the MN1. 849 2) Due to this initial multicast subscription for the MN1, the MAG 850 triggers the multicast Activity Indication message towards the 851 LMA, to indicate that the MN1 multicast activity is ON. The LMA 852 will set the flag A to 1. Afterwards, the LMA sends an Activity 853 Indication Ack message to the MAG to acknowledge the previous 854 indication. 856 4.1.2. Multicast Activity set to OFF (A=0) 858 Figure 2 presents the corresponding flow. 860 +-----+ +-----+ +-----+ 861 | MN1 | | MAG | | LMA | 862 +-----+ +-----+ +-----+ 863 | | | 864 | MLD Done(S,G) | | 865 1) |---------------->X stops fwrding | 866 | | | 867 | | Act Ind(stop) | 868 2) | |--------------->| 869 | | (flag A = 0) 870 | | Act Ind Ack | 871 | |<---------------| 872 | | | 874 Figure 2. Multicast Activity set to OFF 876 The message flow is as follows: 878 1) Some time later, the MN1 decides to totally stop all the active 879 multicast subscriptions that it maintains. The MN1 will send an 880 MLD Done message to the MAG to request the cease of the multicast 881 traffic delivery. As a consequence, the MAG will stop all the 882 multicast traffic forwarding to the MN1. 884 2) After removing the active subscriptions for the MN1, the MAG 885 sends a multicast Activity Indication message to the LMA 886 indicating that the MN1 multicast activity is OFF. The LMA will 887 set the flag A to 0, its default value. Afterwards, the LMA sends 888 an Activity Indication Ack message to the MAG to acknowledge the 889 previous indication. 891 4.2. Handover signaling procedures 893 As the MN moves from one access gateway (named previous-MAG, pMAG) to 894 another (named new-MAG, nMAG), the mobility-related signaling due to 895 the handover event is carried out independently by the pMAG and the 896 nMAG. That signaling process is not synchronized and, thus, two 897 scenarios should be considered depending on the order in which the 898 LMA receives notification of the MN registration and de-registration 899 in the nMAG and the pMAG respectively. 901 4.2.1. Handover of proactive type 903 4.2.1.1. Rationale 905 In the proactive case, the LMA receives the MN de-registration from 906 the pMAG previously to receive the MN registration from the nMAG. 908 Only for those MNs which maintain an active multicast subscription, 909 the pMAG will include, as part of the PBU message (with flag S set to 910 1), the new TLV-encoded mobility option "Active Multicast 911 Subscription" carrying the IP addresses of the multicast 912 subscription(s) active in the MN at that moment. 914 The LMA will store that information in the corresponding binding 915 cache. If, later on, the MN attaches to a nMAG, this information will 916 be sent (using the same TLV option) to the nMAG as part of the PBA 917 confirmation of the registration process (the PBU message sent by the 918 nMAG should set the flag S to 1). On the other hand, if no further 919 registration happens, the multicast information will be removed 920 together with the rest of binding database for that MN. 922 After receiving the multicast addresses of the group(s) subscribed to 923 by the MN, and of the source(s) delivering the corresponding 924 multicast content, the nMAG can subscribe to the multicast flow(s) on 925 behalf of the MN if there is no other MN receiving it already at the 926 nMAG. The multicast status can be also set in advance for the point- 927 to-point link towards the MN. 929 4.2.1.2. Message flow description 931 The figure 3 summarizes this process. 933 +-----+ +----+ +-----+ +----+ 934 | MN | |pMAG| | LMA | |nMAG| 935 +-----+ +----+ +-----+ +----+ 936 | | | | 937 | |==Bi-Dir Tunnel=| | 938 | Multicast Data | | | 939 |<---------------| | | 940 | | | | 941 1) MN Detached | | | 942 | MN Detached Event | | 943 | | | | 944 | |Ext'd DeReg PBU | | 945 2) | |--------------->| | 946 | | | | 947 3) | | Accept PBU | 948 | |(Multicast Subscription info stored) 949 | | | | 950 | | PBA | | 951 4) | |<---------------| | 952 | | | | 953 5) MN Attached | | | 954 | | | MN Attached Event 955 | | | | 956 | | | PBU | 957 6) | | |<---------------| 958 | | | | 959 | | | Ext'd PBA | 960 7) | | |--------------->| 961 | | | | 962 8) | | | Accept PBA, 963 | | | Multicast Group join 964 | | | and P-t-P status setup 965 | | | | 966 | | |==Bi-Dir Tunnel=| 967 | | | | 968 | | | Multicast Data | 969 |<-------------------------------------------------| 970 | | | | 971 | | | | 973 Figure 3. Proactive handover 975 The sequence of messages is the following: 977 1) A registered MN is receiving a multicast content which has been 978 previously subscribed to by sending a standard MLD report from the 979 MN to the currently serving MAG, pMAG. The pMAG keeps the 980 multicast status state of the point-to-point link with the MN. 982 2) The MN perceives a better radio link and decides to initiate a 983 handover process over a radio access controlled by a new MAG, 984 nMAG. As a consequence, pMAG determines a detach event 985 corresponding to this MN, and updates the attachment status of 986 this MN to the LMA by sending an extended Proxy Binding Update 987 message, including a new TLV-encoded option, named "Active 988 Multicast Subscription", which contains the IP addresses of the 989 (S,G) pairs of the active multicast subscriptions in the moment of 990 handover. 992 3) The LMA processes the PBU message. Additionally, the LMA stores 993 in the Binding Cache the information regarding the on-going 994 multicast subscription(s) when the detachment is initiated. This 995 information will be kept until a new registration of the MN is 996 completed by another MAG, or till the Binding Cache expiration, 997 according to [1]. 999 4) The LMA acknowledges to the pMAG the previous PBU message. 1001 5) As a result of the handover process, the MN attaches to another 1002 MAG, called nMAG. 1004 6) The nMAG triggers a registration process by sending a PBU 1005 message (with flag S set to 1) to the LMA. 1007 7) After the analysis of the PBU message, the LMA sends an 1008 extended PBA including the new "Active Multicast Subscription" 1009 option, which contains the IP addresses of the (S,G) pairs of the 1010 active multicast subscriptions in the moment of handover. 1012 8) The nMAG processes the PBA message following all the standard 1013 procedures described in [1]. Additionally, with the new 1014 information relative to multicast subscription, the nMAG will set 1015 up the multicast status of the point-to-point link between the 1016 nMAG and the MN, and will join the content identified by (S,G) on 1017 behalf of the MN in case the nMAG is not receiving already such 1018 content due to a previous subscription ordered by another MN 1019 attached to it. From that instant, the multicast content is served 1020 to the MN. 1022 4.2.2. Handover of reactive type 1024 4.2.2.1. Rationale 1026 In the reactive case, the LMA receives the MN registration from the 1027 nMAG without having previously received the MN de-registration from 1028 the pMAG. 1030 As the nMAG is not aware of any active multicast subscription of the 1031 MN, the nMAG will start a conventional registration process, by 1032 sending a normal PBU message (with flag S set to 1) towards the LMA. 1034 After receiving the PBU message from the nMAG, the LMA will take the 1035 decision of interrogating or not the pMAG regarding any existing 1036 multicast subscription for that MN. This decision is taken following 1037 a procedure that is described later. 1039 Once the multicast subscription information is retrieved from the 1040 pMAG, the LMA encapsulates it in the PBA message by using the TLV 1041 option "Active Multicast Subscription", and forwards the PBA message 1042 to the nMAG. Then, the nMAG can subscribe the multicast flow on 1043 behalf of the MN, if there is no other MN receiving it already at the 1044 nMAG. The multicast status can be also set in advance for the point- 1045 to-point link towards the MN. 1047 4.2.2.2. Message flow description 1049 The figures 4a and 4b summarize this process. 1051 Consider as starting point the situation where a couple of MNs, named 1052 MN1 and MN2, are attached to the pMAG, both MNs being multicast- 1053 enabled nodes, but only MN1 maintains an active multicast 1054 subscription at this moment. As consequence, the value of the A flag 1055 in the LMA is set to 1 for MN1, and set to 0 for MN2. 1057 The sequence of messages for the handover of MN1 and MN2 is the 1058 following (as depicted in figure 4a): 1060 +-----+ +-----+ +----+ +-----+ +----+ 1061 | MN1 | | MN2 | |pMAG| | LMA | |nMAG| 1062 +-----+ +-----+ +----+ +-----+ +----+ 1063 | | | | | 1064 | | | | MN1 Attached Event 1065 | | | | | 1066 | | | | PBU | 1067 1) | | | |<---------------| 1068 | | | LMA decision | 1069 | | | | | 1070 | | | Subscr Query | | 1071 2) | | |<---------------| | 1072 | | | | | 1073 | | | Subscr Resp | | 1074 3) | | |--------------->| | 1075 | | | | | 1076 | | | (Multicast Subscription | 1077 | | | info forwarding) | 1078 | | | | | 1079 | | | | Ext'd PBA | 1080 4) | | | |--------------->| 1081 | | | | | 1082 5) | | | | Accept PBA, 1083 | | | | Multicast Group join 1084 | | | | and P-t-P status setup 1085 | | | | | 1086 | | | |==Bi-Dir Tunnel=| 1087 | | | | | 1088 | | | | (S,G) Data | 1089 |<-------------------------------------------------| 1090 | | | | | 1091 ~ ~ ~ ~ ~ 1092 ~ ~ ~ ~ ~ 1094 Figure 4a. Reactive handover (steps 1 to 5) 1096 The sequence of messages is the following: 1098 1) At certain time, the MN1 perceives a better radio link and 1099 decides to attach at a new MAG, nMAG, in a handover process (as it 1100 is a reactive case, the pMAG is not aware of the detachment 1101 process). Then, the nMAG triggers a registration process by 1102 sending a PBU message (with flag S set to 1) to the LMA. 1104 2) Prior to acknowledge the received PBU message, the LMA checks 1105 the status of the A flag for this MN. Due that the flag A=1, the 1106 LMA interrogates the pMAG about if there is any active multicast 1107 subscription for the MN1, by sending a Subscription Query message. 1109 3) The pMAG answers the LMA with a Subscription Response message 1110 including the IP addresses of the existing subscriptions (the pair 1111 (S,G) in this case). 1113 4) After processing the pMAG answer, the LMA acknowledges (with 1114 flag S set to 1) the PBU message, including the multicast 1115 subscription information within the new TLV-encoded option "Active 1116 Multicast Subscription". The nMAG then process the extended PBA 1117 message. 1119 5) The nMAG processes the PBA message, and it proceeds to set up 1120 the multicast status of the point-to-point link between the nMAG 1121 and the MN1, and to join the content identified by (S,G) on behalf 1122 of the MN1 in case the nMAG is not receiving already such content. 1123 (The bidirectional tunnel is also set up between the nMAG and the 1124 LMA if it has not been established before by another MN 1125 connection). At this moment, the multicast content can be served 1126 to the MN1. The unicast traffic for the MN1 can be forwarded as 1127 well. 1129 +-----+ +-----+ +----+ +-----+ +----+ 1130 | MN1 | | MN2 | |pMAG| | LMA | |nMAG| 1131 +-----+ +-----+ +----+ +-----+ +----+ 1132 | | | | | 1133 ~ ~ ~ ~ ~ 1134 ~ ~ ~ ~ ~ 1135 | | | | | 1136 | | | | MN2 Attached Event 1137 | | | | | 1138 | | | | PBU | 1139 6) | | | |<---------------| 1140 | | | LMA decision | 1141 | | | | PBA | 1142 7) | | | |--------------->| 1143 | | | | | 1144 8) | | | | Accept PBA 1145 | | | | | 1147 Figure 4b. Reactive handover (steps 6 to 8) 1149 6) In parallel, the MN2 perceives a better radio link and decides 1150 to attach also to the nMAG in a reactive handover process as well 1151 (the pMAG is not aware of this detachment process either). Then, 1152 the nMAG triggers a registration process by sending a PBU message 1153 (with flag S set to 1) to the LMA. 1155 7) Prior to acknowledge the received PBU message, the LMA checks 1156 the status of the A flag for this MN. Due that the flag A=0, the 1157 LMA does not interrogate the pMAG, and acknowledges the PBU 1158 message (with flag S set to 0). The nMAG then processes PBA 1159 message. 1161 8) The nMAG is now ready to forward the unicast traffic to the 1162 MN2. 1164 4.2.2.3. Further considerations for the reactive handover signaling 1166 A handover event is managed independently by the pMAG and nMAG. It is 1167 not a synchronized process. In a reactive handover, the LMA will 1168 receive a registration PBU from nMAG before a de-registration PBU 1169 from pMAG, if any. 1171 In the message flows detailed above, it could be the case that the 1172 LMA receives a de-registration PBU from pMAG just after sending the 1173 Subscription Query message, but before receiving the Subscription 1174 Response message. That de-registration PBU message from pMAG will 1175 carry the multicast subscription information required to assist the 1176 MN in the handover, so such valuable information should be kept by 1177 the LMA. Furthermore, it is possible that once the Subscription Query 1178 message arrives to pMAG, the pMAG could have already removed the 1179 multicast related information for the MN. 1181 In order to avoid losing the multicast subscription information sent 1182 in the de-registration PBU message, the LMA should store it, and 1183 include it in the PBA message towards the nMAG in case the 1184 Subscription Response message from the pMAG does not contain 1185 multicast subscription information for the MN. 1187 4.2.3. LMA decision process 1189 A key point of the solution proposed in this document resides on the 1190 LMA decision of interrogating the pMAG about a potential active 1191 subscription of the MN entering the nMAG. Several variables take 1192 place, and it is required to define a mechanism for assisting the LMA 1193 in its decision process. 1195 Basically two flags will be used. One flag, the named "multicast 1196 Signaling" or S flag, is used to signal the multicast capabilities of 1197 the MAGs and the transport of the multicast subscription information 1198 within the PBU/PBA messages. The other one, the named "multicast 1199 Activity" or A flag, is used to register on the LMA whether the MN is 1200 maintaining an active multicast subscription or not. 1202 The following sections summarize the use of these flags on the LMA 1203 decision process. 1205 4.2.3.1. LMA processing of S flag on reception of PBU messages 1207 4.2.3.1.1. Proactive handover 1209 In the event of proactive handover, the pMAG has previously informed 1210 the LMA about any potential subscription information currently active 1211 in the MN. The actions to be carried out by the LMA once it receives 1212 the PBU message from the nMAG are summarized in the table below. 1214 +---------+---------+------------------------+----------------------+ 1215 |multicast|multicast| | | 1216 |signaling|activity | Meaning | LMA action | 1217 | flag S | flag A | | | 1218 +---------+---------+------------------------+----------------------+ 1219 | | |- Multicast not | | 1220 | | A=0 | supported by nMAG |- MN registration as | 1221 | | |- No active subscription| in [1] (S=0 in PBA) | 1222 | | | by MN | | 1223 | S=0 +---------+------------------------+----------------------+ 1224 | | |- Multicast not |- LMA stores multicast| 1225 | | A=1 | supported by nMAG | subscription info | 1226 | | |- Active subscription |- MN registration as | 1227 | | | by MN | in [1] (S=0 in PBA) | 1228 +---------+---------+------------------------+----------------------+ 1229 | | |- Multicast supported by| | 1230 | | A=0 | nMAG |- MN registration as | 1231 | | |- No active subscription| in [1] (S=0 in PBA) | 1232 | | | by MN | | 1233 | S=1 +---------+------------------------+----------------------+ 1234 | | | |- LMA stores multicast| 1235 | | |- Multicast supported by| subscription info | 1236 | | A=1 | nMAG |- MN registration | 1237 | | |- Active subscription | conveys multicast | 1238 | | | by MN | subscription info | 1239 | | | | (S=1 in PBA) | 1240 +---------+---------+------------------------+----------------------+ 1242 4.2.3.1.2. Reactive handover 1244 In the event of reactive handover, the LMA is not aware about any 1245 potential subscription information currently active in the MN. The 1246 actions to be carried out by the LMA once it receives the PBU message 1247 from the nMAG are summarized in the table below. 1249 +---------+---------+-------------------------+---------------------+ 1250 |multicast|multicast| | | 1251 |signaling|activity | Meaning | LMA action | 1252 | flag S | flag A | | | 1253 +---------+---------+-------------------------+---------------------+ 1254 | | |- Multicast not supported| | 1255 | | A=0 | by nMAG |- MN registration as | 1256 | | |- No active subscription | in [1] (S=0 in PBA)| 1257 | | | by MN | | 1258 | S=0 +---------+-------------------------+---------------------+ 1259 | | |- Multicast not supported|- LMA does not | 1260 | | A=1 | by nMAG | interrogate pMAG | 1261 | | |- Active subscription |- MN registration as | 1262 | | | by MN | in [1] (S=0 in PBA)| 1263 +---------+---------+-------------------------+---------------------+ 1264 | | |- Multicast supported by |- LMA does not | 1265 | | A=0 | nMAG | interrogate pMAG | 1266 | | |- No active subscription |- MN registration as | 1267 | | | by MN | in [1] (S=0 in PBA)| 1268 | +---------+-------------------------+---------------------+ 1269 | | | |- LMA interrogates | 1270 | S=1 | | | pMAG to obtain | 1271 | | |- Multicast supported by | multicast | 1272 | | A=1 | nMAG | subscription | 1273 | | |- Active subscription |- MN registration | 1274 | | | by MN | conveys multicast | 1275 | | | | subscription info | 1276 | | | | (S=1 in PBA) | 1277 +---------+---------+-------------------------+---------------------+ 1279 4.2.3.2. LMA set-up of S flag in PBA messages 1281 Once the LMA decision process is finished, the LMA builds the PBA 1282 message to complete the registration process triggered by the nMAG. 1283 The value of the S flag in the PBA message will be set according to 1284 the data specified in the table below. 1286 +---------------+-------------+-------------------------------+ 1287 | S flag | S flag | | 1288 | received in | sent in | Meaning | 1289 | PBU message | PBA message | | 1290 +---------------+-------------+-------------------------------+ 1291 | | | | 1292 | S=0 | S=0 | No further meaning | 1293 | | | | 1294 | (multicast +-------------+-------------------------------+ 1295 | not supported | | | 1296 | by nMAG) | S=1 | N/A | 1297 | | | | 1298 +-------------- +-------------+-------------------------------+ 1299 | | | | 1300 | | S=0 | No active subscription on MN | 1301 | | | | 1302 | +-------------+-------------------------------+ 1303 | S=1 | | - (S,G) info available: | 1304 | (multicast is | | Multicast subscription info | 1305 | supported by | | is conveyed in the PBA | 1306 | nMAG) | | message | 1307 | | S=1 | - (S,G) info not available: | 1308 | | | (IP addresses set to 0) | 1309 | | | It has to be requested by | 1310 | | | using the Subscription Query| 1311 | | | message. | 1312 +---------------+-------------+-------------------------------+ 1314 4.2.4. Prevention of large delays of the binding acknowledgement for 1315 unicast traffic 1317 According to the message sequences described for the reactive 1318 handover case, in case the LMA has to request the multicast 1319 subscription information from the pMAG, the binding request sent by 1320 the nMAG is maintained on-hold till the LMA receives, processes and 1321 includes the multicast subscription information into the extended PBA 1322 message. As consequence, the unicast traffic may then suffer an extra 1323 delay motivated by the multicast-related signaling. During that time, 1324 the unicast traffic with destination the MN being registered by the 1325 nMAG must be buffered or discarded by the LMA. 1327 In order to avoid any potential large delay in the forwarding of 1328 unicast traffic arriving at the LMA towards the MN, a mechanism 1329 should be implemented to decouple multicast from unicast traffic 1330 reception by the MN. 1332 The figure 5 shows this mechanism: 1334 +-----+ +----+ +-----+ +----+ 1335 | MN | |pMAG| | LMA | |nMAG| 1336 +-----+ +----+ +-----+ +----+ 1337 1) | |==Bi-Dir Tunnel=| | 1338 | unicast data | | | 1339 |<-v-v-v-v-v-v-v-| | | 1340 | | | | 1341 | Multicast Data | | | 1342 |<---------------| | | 1343 | | | MN1 Attached Event 1344 | | | PBU | 1345 2) | | |<---------------| 1346 | | Subscr Query | | 1347 3) | |<---------------| | 1348 | | | | 1349 4) | | | 1350 | | /// | 1351 | | /// | 1352 5) | | | 1353 | | | | 1354 | | | Ext'd PBA | 1355 | | |--------------->| 1356 | | | | 1357 | | | Accept PBA 1358 | | | | 1359 | | |==Bi-Dir Tunnel=| 1360 | | | | 1361 | | | Unicast Data | 1362 |<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-| 1363 | | | | 1364 | | | Subscr Query | 1365 6) | | |<---------------| 1366 | | Subscr Resp | | 1367 7) | |--------------->| | 1368 | | | | 1369 | | (Multicast Subscription | 1370 | | info forwarding) | 1371 | | | | 1372 | | | Subscr Resp | 1373 8) | | |--------------->| 1374 | | | | 1375 | | | Multicast Group join 1376 | | | and P-t-P status setup 1377 | | Multicast Data | | 1378 |<-------------------------------------------------| 1379 | | | | 1381 Figure 5. Decoupling of unicast and multicast signaling 1383 The sequence of messages is the following: 1385 1) An MN is attached to the pMAG. The MN is a multicast-enabled 1386 node, and it is receiving both unicast and multicast traffic 1387 simultaneously. 1389 2) Some time later, the MN perceives a better radio link and 1390 decides to attach at a new MAG, nMAG, in a handover process (as a 1391 reactive case, the pMAG is not aware of the detachment process). 1392 Then, the nMAG triggers a registration process by sending a PBU 1393 message (with flag S set to 1) to the LMA. 1395 3) Prior to acknowledge the received PBU message, the LMA decides 1396 to interrogate the pMAG about if there is any active multicast 1397 subscription for the MN, by sending a Subscription Query message. 1398 The LMA decision is based on the checking of flag A when the 1399 reactive handover manages the multicast activity indication. 1401 4) Immediately after sending the Subscription Query message, the 1402 LMA starts the timer "PBA timer", which determines the maximum 1403 waiting time before the PBA is sent to avoid any potential large 1404 delay in the forwarding of unicast traffic towards the MN. 1406 5) In case the "PBA timer" expires, the LMA acknowledges the PBU 1407 message, by sending the PBA message with flag S=1, and the "Active 1408 Multicast Subscription" mobility option with the (S,G) IP 1409 addresses set to 0. The nMAG then processes the extended PBA 1410 message. Such acknowledgement will allow the MN to receive the 1411 unicast traffic from that time on. (The bidirectional tunnel is 1412 also set up between the nMAG and the LMA if it has not been 1413 established before). 1415 6) In parallel, the nMAG sends a Subscription Query message to the 1416 LMA requesting the multicast-subscription details yet unknown for 1417 the MN. 1419 7) The pMAG answers the Subscription Query message originally sent 1420 by the LMA, including the IP addresses of the existing 1421 subscriptions (the pair (S,G) in this case). 1423 8) After processing the pMAG answer, the LMA sends a Subscription 1424 Response message to the nMAG, including the multicast subscription 1425 information within the new TLV-encoded option "Active Multicast 1426 Subscription". The nMAG processes the PBA message, and it proceeds 1427 to set up the multicast status of the point-to-point link between 1428 the nMAG and the MN, and to join the content identified by (S,G) 1429 on behalf of the MN in case the nMAG is not receiving already such 1430 content. (The bidirectional tunnel is also set up between the nMAG 1431 and the LMA if it has not been established before). At this 1432 moment, the multicast content can also be served to the MN. 1434 5. Co-existence with PMIPv6 multicast architectural evolutions 1436 Along this document, it has been considered that the LMA entity is in 1437 charge of delivering both unicast and multicast traffic to a certain 1438 MN through the bi-directional tunnels connecting to the MAG where the 1439 MN is attached, as specified in the base solution defined in [4]. 1440 However, the solution described in this memo is not only applicable 1441 to the base solution, but also it can be applied to other solutions 1442 envisioned as possible architectural evolutions to solve the tunnel 1443 convergence problem affecting the base solution, as those stated in 1444 [6]. 1446 The Multicast Tree Mobility Anchor (MTMA) solution in [6] makes use 1447 of a separate entity to serve multicast traffic through distinct 1448 tunnels connected to the MAGs. The tunnels for multicast traffic 1449 could not be set up in advance if they are dynamical in nature. 1451 When the "multicast activity" flag is also present in the MN's policy 1452 store, the nMAG knows in advance the multicast activity of the 1453 incoming MN. Consequently, the nMAG can trigger the multicast tunnel 1454 set up in parallel to the registration process, including the 1455 acquisition of the active multicast subscription details (the IP 1456 addresses of the source and the content), saving time on serving the 1457 multicast flow to the incoming MN. The concrete procedure for 1458 multicast tunnel establishment is out of the scope of this document. 1460 6. Benefits of layer-2 triggers for fast handover 1462 As stated before, the global performance of the multicast handover 1463 can be improved in the case that layer-2 triggers are supported by 1464 the underlying radio technology. In [7], a procedure which allows to 1465 buffer at the pMAG and forward to the nMAG the traffic with 1466 destination the MN during the handover duration is defined. This 1467 forwarding can be beneficial for either strict real-time services or 1468 for networks with long handover duration. By forwarding the traffic 1469 to the MN, the disruption of the multicast traffic reception is 1470 minimized. 1472 The solution in [7] avoids packet loss during the handover. Even so, 1473 using the proposal in this memo is still useful, because reducing the 1474 time required to set up multicast traffic delivery in the nMAG 1475 minimizes the buffering needed at the pMAG. 1477 In any case, because the feature in [7] is dependent on the 1478 capabilities of both the underlying radio technology and the layer-2 1479 triggering functionalities supported by the MN, and that not all the 1480 multicast applications could take benefit of it, that functionality 1481 could be seen as optional for multicast handover optimization. 1483 7. Security Considerations 1485 TBD. 1487 8. IANA Considerations 1489 This document defines the new following elements which values should 1490 be allocated: 1492 o Mobility Header types: the Subscription Query and Subscription 1493 Response, and the Multicast Activity Indication and Multicast 1494 Activity Indication Acknowledge mobility header types. 1496 o Mobility options: the Active Multicast Subscription mobility 1497 option. 1499 o Flags: the multicast Signaling (S), the multicast Information 1500 (I), and the multicast Active (A) flags. 1502 9. Contributors 1504 Dirk Von Hugo (Telekom Innovation Laboratories, Dirk.von- 1505 Hugo@telekom.de) has largely contributed to this document. 1507 10. Acknowledgments 1509 The authors would like to thank (in alphabetical order) Hitoshi 1510 Asaeda, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt and Stig 1511 Venaas for their valuable comments and discussions on the Multimob 1512 mailing list. The authors are also grateful with Hitoshi Asaeda and 1513 Behcet Sarikaya for their review of this document. 1515 The research of Carlos J. Bernardos leading to these results has 1516 received funding from the European Community's Seventh Framework 1517 Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL 1518 project), being also partially supported by the Ministry of Science 1519 and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 1520 13992-C02-01). 1522 The research of Ignacio Soto has also received funding from the 1523 Spanish MICINN through the I-MOVING project (TEC2010-18907). 1525 11 References 1527 11.1 Normative References 1529 [1] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury, and B. 1530 Patil, "Proxy Mobile IPv6", RFC 5213, Augurst 2008. 1532 [2] S. Deering, W. Fenner, B. Haberman, "Multicast Listener 1533 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1535 [3] D. Johnson, C. Perkins, and J. Arkko, "Mobility Support in 1536 IPv6", RFC 3775, June 2004. 1538 11.2 Informative References 1540 [4] T.C. Schmidt, M. Waehlisch, and S. Krishnan, "A Minimal 1541 Deployment Option for Multicast Listeners in PMIPv6 Domains", 1542 RFC6224, April 2011. 1544 [5] D. von Hugo, H. Asaeda, B. Sarikaya, and P. Seite, "Evaluation 1545 of further issues on Multicast Mobility: Potential future work 1546 for WG MultiMob", draft-von-hugo-multimob-future-work-02, (work 1547 in progress), June 2010. 1549 [6] J.C. Zuniga, L.M. Contreras, C.J. Bernardos, S. Jeon, and Y. 1550 Kim, "Multicast Mobility Routing Optimizations for Proxy Mobile 1551 IPv6", draft-ietf-multimob-pmipv6-ropt-00, (work in progress), 1552 March 2012. 1554 [7] H. Yokota, Chowdhury, K., Koodli, R., Patil, B., and F. Xia, 1555 "Fast Handovers for Proxy Mobile IPv6", RFC 5949, September 1556 2010 1558 [8] H. Asaeda, H. Liu, and Q. Wu, "Tuning the Behavior of IGMP and 1559 MLD for Routers in Mobile and Wireless Networks", draft-ietf- 1560 multimob-igmp-mld-tuning-05, (work in progress), March 2012. 1562 [9] R. Vida and L. Costa, "Multicast Listener Discovery Version 2 1563 (MLDv2) for IPv6", RFC3810, June 2004. 1565 Authors' Addresses 1567 Luis M. Contreras 1568 Telefonica I+D 1569 Email: lmcm@tid.es 1571 Carlos J. Bernardos 1572 Universidad Carlos III de Madrid 1573 Email: cjbc@it.uc3m.es 1575 Ignacio Soto 1576 Universidad Politecnica de Madrid 1577 Email: isoto@dit.upm.es