idnits 2.17.1 draft-ietf-multimob-fast-handover-03.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 (October 22, 2012) is 4203 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-multimob-pmipv6-ropt-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MULTIMOB Working Group LM. Contreras 3 Internet-Draft Telefonica I+D 4 Intended status: Experimental CJ. Bernardos 5 Expires: April 25, 2013 I. Soto 6 UC3M 7 October 22, 2012 9 PMIPv6 multicast handover optimization by the Subscription Information 10 Acquisition through the LMA (SIAL) 11 draft-ietf-multimob-fast-handover-03 13 Abstract 15 This document specifies a multicast handover optimization mechanism 16 for Proxy Mobile IPv6 to accelerate the delivery of multicast traffic 17 to mobile nodes after handovers. The mechanism is based on speeding 18 up the acquisition of mobile nodes' multicast context by the mobile 19 access gateways. To do that, extensions to the current Proxy Mobile 20 IPv6 protocol are proposed. These extensions are not only applicable 21 to the base solution for multicast support in Proxy Mobile IPv6, but 22 they can also be applied to other solutions being developed to avoid 23 the tunnel convergence problem. Furthermore, they are also 24 independent of the role played by the mobile access gateway within 25 the multicast network (either acting as multicast listener discovery 26 proxy or multicast router). 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 25, 2013. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. PMIPv6 extensions . . . . . . . . . . . . . . . . . . . . . . 8 66 4.1. New mobility option . . . . . . . . . . . . . . . . . . . 8 67 4.1.1. Active Multicast Subscription mobility option . . . . 8 68 4.1.1.1. Option application rules . . . . . . . . . . . . . 8 69 4.1.1.2. Option format . . . . . . . . . . . . . . . . . . 8 70 4.2. New flags . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2.1. Multicast Signaling flag on PBU/PBA message headers . 9 72 4.2.1.1. Flag application rules . . . . . . . . . . . . . . 9 73 4.2.1.1.1. Registration process . . . . . . . . . . . . . 9 74 4.2.1.1.2. De-registration process . . . . . . . . . . . 10 75 4.2.1.2. New format of conventional PBU/PBA messages . . . 11 76 4.2.1.2.1. Proxy Binding Update message . . . . . . . . . 11 77 4.2.1.2.2. Proxy Binding Acknowledgement Message . . . . 11 78 4.2.2. Multicast Active flag in the LMA Binding Cache and 79 (optionally) on the MN's policy store . . . . . . . . 11 80 4.2.2.1. Flag application rules . . . . . . . . . . . . . . 11 81 4.3. New messages . . . . . . . . . . . . . . . . . . . . . . . 12 82 4.3.1. Messages for active multicast subscription 83 interrogation . . . . . . . . . . . . . . . . . . . . 12 84 4.3.1.1. Subscription Query message . . . . . . . . . . . . 13 85 4.3.1.1.1. Message application rules . . . . . . . . . . 13 86 4.3.1.1.2. Message format . . . . . . . . . . . . . . . . 13 87 4.3.1.2. Subscription Response message . . . . . . . . . . 14 88 4.3.1.2.1. Message application rules . . . . . . . . . . 14 89 4.3.1.2.2. Message format . . . . . . . . . . . . . . . . 14 90 4.3.2. Messages for active multicast subscription 91 indication . . . . . . . . . . . . . . . . . . . . . . 15 92 4.3.2.1. Multicast Activity Indication message . . . . . . 15 93 4.3.2.1.1. Message application rules . . . . . . . . . . 16 94 4.3.2.1.2. Message format . . . . . . . . . . . . . . . . 16 95 4.3.2.2. Multicast Activity Indication Acknowledge 96 message . . . . . . . . . . . . . . . . . . . . . 17 98 4.3.2.2.1. Message application rules . . . . . . . . . . 17 99 4.3.2.2.2. Message format . . . . . . . . . . . . . . . . 17 100 4.4. New PBA timer in the LMA . . . . . . . . . . . . . . . . . 18 101 5. Signaling processes description . . . . . . . . . . . . . . . 18 102 5.1. Multicast Activity signaling . . . . . . . . . . . . . . . 18 103 5.1.1. Multicast Activity set to ON (A=1) . . . . . . . . . . 19 104 5.1.2. Multicast Activity set to OFF (A=0) . . . . . . . . . 20 105 5.2. Handover signaling procedures . . . . . . . . . . . . . . 20 106 5.2.1. Handover of proactive type . . . . . . . . . . . . . . 21 107 5.2.1.1. Rationale . . . . . . . . . . . . . . . . . . . . 21 108 5.2.1.2. Message flow description . . . . . . . . . . . . . 21 109 5.2.2. Handover of reactive type . . . . . . . . . . . . . . 23 110 5.2.2.1. Rationale . . . . . . . . . . . . . . . . . . . . 23 111 5.2.2.2. Message flow description . . . . . . . . . . . . . 24 112 5.2.2.3. Further considerations for the reactive 113 handover signaling . . . . . . . . . . . . . . . . 27 114 5.2.3. LMA decision process . . . . . . . . . . . . . . . . . 28 115 5.2.3.1. LMA processing of S flag on reception of PBU 116 messages . . . . . . . . . . . . . . . . . . . . . 28 117 5.2.3.1.1. Proactive handover . . . . . . . . . . . . . . 28 118 5.2.3.1.2. Reactive handover . . . . . . . . . . . . . . 29 119 5.2.3.2. LMA set-up of S flag in PBA messages . . . . . . . 30 120 5.2.4. Prevention of large delays of the binding 121 acknowledgement for unicast traffic . . . . . . . . . 31 122 6. Co-existence with PMIPv6 multicast architectural evolutions . 34 123 7. Security Considerations . . . . . . . . . . . . . . . . . . . 34 124 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 125 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36 126 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 127 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 128 11.1. Normative References . . . . . . . . . . . . . . . . . . . 37 129 11.2. Informative References . . . . . . . . . . . . . . . . . . 37 130 Appendix A. Performance comparison with base solution . . . . . . 38 131 A.1. Delay characterization of the base solution . . . . . . . 38 132 A.2. Delay characterization of the SIAL solution . . . . . . . 39 133 A.3. Performance comparison . . . . . . . . . . . . . . . . . . 40 134 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 41 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 137 1. Introduction 139 The base solution describing how continuous multicast service 140 delivery can be provided in Proxy Mobile IPv6 domains is described in 141 RFC 6224 [RFC6224]. This solution specifies the basic functionality 142 needed in the Proxy Mobile IPv6 [RFC5213] entities to provide a 143 multicast service, and supports the continuous delivery of multicast 144 traffic by obtaining, after a handover, the on-going multicast 145 subscription information directly from the mobile node. When a 146 mobile node attaches to a new mobile access gateway, the mobile node 147 is interrogated by the mobile access gateway through a multicast 148 listener discovery General Query, which is sent just after any new 149 link is set up, to get knowledge of any existing subscription, as 150 specified in [RFC2710]. 152 However, as highlighted by [I-D.von-hugo-multimob-future-work], the 153 base solution needs to be improved to meet some performance 154 requirements, especially those referred to the user perceived service 155 quality, which is seriously affected by the disruption of multicast 156 content forwarding to the mobile node during handovers. 158 A mobile node with an active multicast subscription, moving from one 159 point of attachment to another within a Proxy Mobile IPv6 domain, 160 experiences a certain delay until it resumes receiving again the 161 multicast content that it was receiving at the previous location. 162 Such delay causes a gap in the content reception. Two different 163 actions can help to mitigate such reception gap. One of them is to 164 buffer at the previous mobile access gateway the traffic with 165 destination at the mobile node and forward it to the new mobile 166 access gateway, in order to deliver that traffic to the mobile node. 167 The other possible (complementary) action is to reduce the time 168 needed by the new mobile access gateway to get knowledge of the 169 active multicast subscription of the mobile node (i.e., the multicast 170 context), so the new mobile access gateway can subscribe to the 171 multicast group(s) on behalf of the mobile node as soon as possible. 173 While the first mechanism could potentially be accomplished by using 174 some adaptation of [RFC5949] to multicast traffic (despite being only 175 applicable in the case the underlying radio access technology 176 supports layer-2 triggers, thus requiring additional support on the 177 mobile node), there is no a generic standard solution for the 178 accelerated acquisition of the on-going multicast subscription of the 179 mobile node. 181 The approach followed by the base solution [RFC6224] to get knowledge 182 of an existing multicast subscription relies on the behavior of the 183 IGMP/MLD protocols. Both protocols send multicast membership 184 interrogation messages when a new link is up. The response to such a 185 message reports any existing multicast subscription by the mobile 186 node. While this is a straightforward approach, it also causes that 187 the mobile access gateway can incur in a non-negligible delay in 188 receiving the corresponding MLD Report message. This delay is caused 189 by the time needed for the detection of the attachment in the new 190 link and the re-establishment of the data plane after the handover, 191 the radio transfer delays associated with the signaling to the mobile 192 node, and the MLD query response interval time required by this 193 procedure (whose default value is 10 seconds as defined in [RFC2710], 194 or between 5 and 10 seconds as considered in the best case wireless 195 link scenario in [RFC6636]). 197 This document extends the Proxy Mobile IPv6 signaling protocol 198 defined in the base protocol [RFC5213] by including a new multicast 199 information option to update Proxy Mobile IPv6 entities during the 200 registration and de-registration processes, and new messages to 201 trigger the transfer of multicast information. No extension is 202 required in any of the multicast-related protocols in use (IGMP/MLD 203 or PIM protocols). This document provides a signaling method 204 internal to the network to speed up the subscription information 205 acquisition by the mobile access gateway, in order to accelerate the 206 multicast delivery to the mobile node after having completed a 207 handover. By doing so, the knowledge by the mobile access gateway of 208 the currently active multicast subscription becomes independent of 209 the underlying radio technology dynamics and relaxes the requirement 210 of a rapid response from the mobile node in processing MLD control 211 messages. Issues like radio framing, radio access contention, 212 channel reliability, MN's capabilities (i.e., layer-2 triggering 213 support), IGMP/MLD timers optimization for wireless environments, 214 etc, will not impact on the observed multicast performance during 215 handovers. 217 The solution described in this document can also be applied to the 218 solutions described in [I-D.ietf-multimob-pmipv6-ropt]. Furthermore, 219 it is also independent of the role played by the mobile access 220 gateway within the multicast network (either acting as MLD proxy or 221 multicast router). 223 2. Terminology 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in RFC2119 [RFC2119]. 229 This document uses the terminology referring to PMIPv6 components as 230 defined in [RFC5213]. 232 Additionally, the following terms are defined. 234 pMAG: The previous MAG or pMAG is the MAG where the MN is initially 235 registered in a handover event. 237 nMAG: The new MAG or nMAG is the MAG where the MN is registered at 238 the end of the handover event. 240 Reactive Handover: A reactive handover is a handover event in which 241 the LMA receives the MN registration from the nMAG without having 242 previously received the MN de-registration from the pMAG. 244 Proactive handover: A proactive handover is a handover event where 245 the MN is firstly de-registered on the LMA by the pMAG, and later 246 on it is registered by the nMAG as consequence of changing the 247 point of attachment. 249 Multicast context: Along this document, multicast context makes 250 reference to the information relative to the currently active 251 multicast subscription of a MN in a handover event which is 252 transferred between the PMIPv6 entities to support the handover 253 optimization. The information comprising the multicast context is 254 transferred by using the Multicast Address record format as 255 defined in [RFC3810]. 257 3. Overview 259 The LMA is a key element within the PMIPv6 infrastructure, which 260 traces the MN reachability along the PMIPv6 domain. Therefore the 261 LMA is the best element to maintain the MNs' multicast subscription 262 information updated and to forward it to the rest of PMIPv6 entities 263 (i.e., to the MAGs) as needed when MNs move within the domain. The 264 LMA has timely knowledge of the MNs' location, especially during 265 handover events, and it is therefore able to quickly provide 266 information to the new one point of attachment (querying the previous 267 one if required). Figure 1 shows this idea. 269 +------+ 270 | pMAG | | 271 +------+ | 272 / | 273 / | 274 / | 275 / | 276 -*-*-*-*- / (MN) 277 ( ) / | 278 ( ) +-----+ +------+ | 279 ( Internet )--| LMA |------| nMAG | v 280 ( ) +-----+ +------+ 281 ( ) 282 -*-*-*-*- Registration 283 <-------------- 285 Registration Ack 286 & Multicast Context 287 --------------> 289 Figure 1: High level solution description 291 The LMA only obtains the detailed subscription information or 292 multicast context during a handover event. There is no need of 293 continuously informing the LMA about MNs' multicast state while the 294 mobile nodes remain attached to the same mobile access gateway. Such 295 a continuous updating procedure would significantly increase the 296 signaling load within the PMIPv6 domain without a clear benefit. The 297 multicast context is only critical during handovers, neither after 298 nor before. Indicating the active subscription while the handover is 299 ongoing guarantees that such information will be up-to-date, ready to 300 be transferred to the new MAG where the MN has just attached. 301 However it should be noted that some signaling is needed to 302 differientate what MNs are maintaining active subscriptions in order 303 to restrict the optimization procedure to them in case of handover. 305 To be able to transfer the multicast subscription information between 306 PMIPv6 entities during a handover, this document extends the PMIPv6 307 protocol in several ways. First of all, a new mobility option is 308 defined to carry the multicast context of the current subscription. 309 Furthermore, additional messages are defined to manage the 310 interchange of the multicast information among PMIPv6 entities. 311 Finally, some flags are defined to govern the process. 313 Next sections provide the details of these Proxy Mobile IPv6 protocol 314 extensions. 316 4. PMIPv6 extensions 318 This section outlines the extensions proposed to the PMIPv6 protocol 319 specified in [RFC5213]. 321 4.1. New mobility option 323 4.1.1. Active Multicast Subscription mobility option 325 4.1.1.1. Option application rules 327 A new TLV-encoded mobility option, "Active Multicast Subscription" 328 option is defined for use with the PBU (Proxy Binding Update) and PBA 329 (Proxy Binding Acknowledge) messages exchanged between an LMA and a 330 MAG to transfer the multicast subscription information. This option 331 is used for exchanging the multicast context. This information is 332 carried by using directly the Multicast Address Record format defined 333 in [RFC3810]. There can be multiple "Active Multicast Subscription" 334 options present in the message, one for each active subscription 335 maintained by the MN when the handover is taking place (i.e., one per 336 Multicast Address Record). 338 This new option will be also used, with the same aim, by the new 339 message Subscription Response described later in this document. 341 4.1.1.2. Option format 343 The format of this new option is as follows: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Type | Length | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | | 351 + Multicast Address Record + 352 | | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 Type: 357 To be defined by IANA. 359 Length: 361 8-bit unsigned integer indicating the length of the option in 362 octects, excluding the type and length fields. 364 Multicast Address Record: 366 Multicast subscription information corresponding to a single 367 subscribed multicast address as defined in [RFC3810]. 369 4.2. New flags 371 Two new flags are defined and used to handle the forwarding of 372 multicast subscription information. 374 4.2.1. Multicast Signaling flag on PBU/PBA message headers 376 4.2.1.1. Flag application rules 378 A new flag S is added in both PBU and PBA message headers to advise 379 about the MAG and the LMA capabilities of processing multicast- 380 related signaling for the MN that caused the message. 382 This flag will govern the multicast-related signaling between the LMA 383 and the MAG. As a general rule, the value of the flag in the PBA 384 message SHOULD be a copy of the value received in the PBU message. 385 Specific rules are described in next sub-sections. 387 4.2.1.1.1. Registration process 389 During handover, the entities involved in this process are the nMAG 390 and the LMA. These rules also apply for the Initial Binding 391 registration process. 393 o PBU message 395 * S=0, it indicates that the MAG sending the PBU message does not 396 accept multicast-related signaling for the MN being attached. 397 This can be used to discriminate PMIPv6 nodes which are not 398 multicast enabled, for backward compatibility reasons. 400 * S=1, it indicates that the MAG sending the PBU message accepts 401 multicast-related signaling for the MN being attached. 402 Depending on the type of handover (reactive or proactive) the 403 LMA will take some actions, described later in this document. 405 o PBA message 407 * If S=0 in the corresponding PBU message, the value of the flag 408 in the PBA message SHOULD be a copy of the value received in 409 the PBU message (thus S=0), without any further meaning. 411 * If S=1 in the corresponding PBU message, two sub-cases can 412 happen 414 + S=1 and "Active Multicast Subscription" mobility option in 415 the PBA message. When the MN maintains an active multicast 416 session, if the LMA is able to provide the multicast 417 subscription information during registration, the PBA 418 message will include the "Active Multicast Subscription" 419 mobility option. If the LMA is not able to provide such 420 information during registration, the PBA message will not 421 include the "Active Multicast Subscription" mobility option. 422 This case is useful to decouple unicast and multicast 423 signaling for an MN being registered at nMAG. A way for 424 obtaining later active multicast-subscription information is 425 described later in this document. 427 + S=0 in the PBA message if the MN does not maintain an active 428 multicast subscription (note that for backward compatibility 429 reasons an LMA not supporting multicast related signaling 430 would always send S=0). 432 4.2.1.1.2. De-registration process 434 During handover, the entities involved in this process are the pMAG 435 and the LMA. These rules apply for the Binding De-registration 436 process 438 o PBU message 440 * S=0, it indicates that the MN has no active multicast session 441 (note that for backward compatibility reasons a pMAG not 442 supporting multicast related signaling would always send S=0). 444 * S=1, it indicates that the MN has an active multicast session, 445 and the multicast context is transported in the "Active 446 Multicast Subscription" mobility option. 448 o PBA message 450 * The value of the flag in the PBA message SHOULD be 0, without 451 any further meaning (note that for backward compatibility 452 reasons an LMA not supporting multicast related signaling would 453 always send S=0). 455 4.2.1.2. New format of conventional PBU/PBA messages 457 4.2.1.2.1. Proxy Binding Update message 459 As result of the new defined flag, the PBU message results as 460 follows: 462 0 1 2 3 463 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 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Sequence # | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 |A|H|L|K|M|R|P|S| Reserved | Lifetime | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | | 470 . . 471 . Mobility options . 472 . . 473 | | 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 476 4.2.1.2.2. Proxy Binding Acknowledgement Message 478 As result of the new defined flag, the PBA message results as 479 follows: 481 0 1 2 3 482 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 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Status |K|R|P|S| Rsrvd | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Sequence # | Lifetime | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 | | 489 . . 490 . Mobility options . 491 . . 492 | | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 495 4.2.2. Multicast Active flag in the LMA Binding Cache and (optionally) 496 on the MN's policy store 498 4.2.2.1. Flag application rules 500 A new flag A is added in the LMA Binding Cache to retain the 501 knowledge that the registered MN maintains or not an active multicast 502 subscription. The basic use of this flag is to restrict the 503 interrogation of the pMAG only to the cases in which the MN certainly 504 is maintaining an active subscription. The algorithm which is 505 followed by the LMA to interrogate or not the pMAG (after receiving a 506 PBU message from the nMAG) is as follows: 508 o Flag S=0 & flag A=0: this situation represents the case where the 509 nMAG does not support multicast-related signaling for the MN being 510 registered, and, additionally, the LMA is not aware of any active 511 multicast subscription on-going. Then, the LMA does not 512 interrogate the pMAG, and registers the MN as attached to the nMAG 513 as usual. 515 o Flag S=0 & flag A=1: this situation represents the case where the 516 nMAG does not support multicast-related signaling for the MN being 517 registered, but the LMA is aware of one or more on-going MN's 518 active multicast subscriptions. Due to the fact that multicast 519 signaling is not supported by the nMAG for that MN, the LMA does 520 not interrogate the pMAG, and registers the MN as attached to the 521 nMAG as usual. 523 o Flag S=1 & flag A=0: this situation represents the case where the 524 nMAG supports multicast-related signaling for the MN being 525 registered, but the LMA is not aware of any active multicast 526 subscription. Then, the LMA does not interrogate the pMAG, and 527 registers the MN as attached to the nMAG as usual. 529 o Flag S=1 & flag A=1: this situation represents the case where the 530 nMAG supports multicast-related signaling for the MN being 531 registered, and, additionally, the LMA is aware of one or more on- 532 going MN's active multicast subscriptions. Then, the LMA 533 interrogates the pMAG to obtain the multicast context details 534 previously to complete the registration of the MN attached to the 535 nMAG. 537 The flag A SHOULD be initialized to the value 0. 539 Optionally, this flag can be also added to the MN's policy store, and 540 dynamically updated by the LMA to signal that the MN has (or not) an 541 active multicast subscription. By introducing this flag in the MN's 542 policy profile, the nMAG can know in advance the existence of an 543 active multicast session by the incoming MN. 545 4.3. New messages 547 4.3.1. Messages for active multicast subscription interrogation 549 A new pair of messages is defined for interrogating entities about 550 the active multicast subscription of the MN when the handover is of 551 reactive type. 553 These messages are sent using the Mobility Header as defined in 554 [RFC6275]. 556 4.3.1.1. Subscription Query message 558 4.3.1.1.1. Message application rules 560 The Subscription Query message is sent by the LMA towards the pMAG to 561 interrogate it about any existing multicast subscription of the MN 562 which is being registered by the nMAG. This message is generated in 563 case that the handover is of reactive type. 565 Additionally, this message is sent by the nMAG towards the LMA to 566 interrogate it about the existing multicast subscription of the MN 567 when the LMA acknowledges the PBU sent by the nMAG but the multicast 568 context is not provided (in detail, when the PBU messages has set the 569 flag S to 1, and the PBA message has set the flag S to 1 but the 570 multicast context is missing). 572 4.3.1.1.2. Message format 574 The Subscription Query message has the following format. 576 0 1 2 3 577 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 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Sequence # | Reserved | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | | 582 . . 583 . Mobility options . 584 . . 585 | | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Sequence Number: 590 The Sequence Number field establishes the order of the messages 591 sent in the Subscription Query / Subscription Response dialogue 592 between the LMA and the MAG for a certain MN. The initial 593 Sequence Number will be determined by the entity which creates the 594 message (either LMA or MAG, depending on the scenario), which will 595 be responsible of managing this counter. 597 Reserved: 599 This field is unused for now. The value MUST be initialized to 0. 601 Mobility options: 603 This message will carry one or more TLV-encoded mobility options. 604 The valid mobility options for this message are the following: 606 * Mobile Node Identifier option (mandatory) 608 * Home Network Prefix option (optional) 610 There can be one or more instances of the Home Network Prefix 611 option, but only one instance of the Mobile Node Identifier 612 option. 614 4.3.1.2. Subscription Response message 616 4.3.1.2.1. Message application rules 618 The Subscription Response message is sent by the pMAG towards the 619 LMA, or by the LMA towards the nMAG, to answer a previously received 620 Subscription Query message, as described above. 622 4.3.1.2.2. Message format 624 The Subscription Response message has the following format. 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Sequence # |I| Reserved | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | | 632 . . 633 . Mobility options . 634 . . 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Sequence Number: 640 The value of the Sequence Number field in the Subscriber Response 641 message MUST be a copy of the Sequence Number received in the 642 Subscription Query message. 644 Multicast Information (I): 646 The multicast Information flag I specifies if there is multicast 647 subscription information available for the MN or not. The meaning 648 is the following: 650 I=0: there is no multicast subscription information available 651 for the MN identified by the Mobile Node Identifier option in 652 this message. 654 I=1: there is multicast subscription information available for 655 the MN identified by the Mobile Node Identifier option in this 656 message. The multicast subscription information is carried on 657 one or more instances of the Active Multicast Subscription 658 option in this message (one instance for each active 659 subscription). 661 Reserved: 663 This field is unused for now. The value MUST be initialized to 0. 665 Mobility options: 667 This message will carry one or more TLV-encoded mobility options. 668 The valid mobility options for this message are the following: 670 * Mobile Node Identifier option (mandatory) 672 * Active Multicast Subscription option (mandatory) only when flag 673 I=1, not present in any other case 675 * Home Network Prefix option (optional) 677 There can be one or more instances of the Home Network Prefix 678 option (in all cases) and the Active Multicast Subscription option 679 (only when I=1), but only one instance of the Mobile Node 680 Identifier option. 682 4.3.2. Messages for active multicast subscription indication 684 A new pair of messages is defined for setting up and down the 685 optional A flag defined above. 687 These messages are sent using the Mobility Header as defined in 688 [RFC6275]. 690 4.3.2.1. Multicast Activity Indication message 691 4.3.2.1.1. Message application rules 693 The Multicast Activity Indication message is sent by a MAG towards 694 the LMA to set to 1 or 0 the A flag either to indicate the start or 695 the complete cease of any multicast subscription by the MN. Through 696 the use of this message, the LMA becomes aware that one or more 697 multicast flows are being forwarded to a MN. This information is 698 useful for the LMA during a handover to discriminate if the pMAG 699 needs to be asked or not about multicast information corresponding to 700 the MN being registered at the nMAG, in case that the handover is of 701 reactive type. 703 4.3.2.1.2. Message format 705 The Multicast Activity Indication message has the following format. 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Sequence # |A| Reserved | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 . . 714 . Mobility options . 715 . . 716 | | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 Sequence Number: 721 The Sequence Number field establishes the order of the messages 722 sent in the Activity Indication / Activity Indication Ack dialogue 723 between the MAG and the LMA for a certain MN. The initial 724 Sequence Number will be determined by the MAG, which will be 725 responsible of managing this counter. 727 Activity indicator (A): 729 The Activity indicator flag A specifies if the MN multicast 730 activity is on, that is, if the MN maintains one or more active 731 multicast subscriptions at the MAG. The meaning is the following: 733 A=0: the multicast activity of the MN (identified by the Mobile 734 Node Identifier option in this message) is OFF. 736 A=1: the multicast activity of the MN (identified by the Mobile 737 Node Identifier option in this message) is ON. 739 Reserved: 741 This field is unused for now. The value MUST be initialized to 0. 743 Mobility options: 745 This message will carry one or more TLV-encoded mobility options. 746 The valid mobility options for this message are the following: 748 * Mobile Node Identifier option (mandatory) 750 * Home Network Prefix option (optional) 752 There can be one or more instances of the Home Network Prefix 753 option, but only one instance of the Mobile Node Identifier 754 option. 756 4.3.2.2. Multicast Activity Indication Acknowledge message 758 4.3.2.2.1. Message application rules 760 The Multicast Activity Indication Acknowledge message is sent by the 761 LMA towards a MAG to confirm the reception of a previously sent 762 Multicast Activity Indication message. 764 4.3.2.2.2. Message format 766 The Multicast Activity Indication message has the following format. 768 0 1 2 3 769 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 770 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 771 | Sequence # | Reserved | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | | 774 . . 775 . Mobility options . 776 . . 777 | | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 Sequence Number: 782 The value of the Sequence Number field in the Activity Indication 783 Ack message MUST be a copy of the Sequence Number received in the 784 Activity Indication message. 786 Reserved: 788 This field is unused for now. The value MUST be initialized to 0. 790 Mobility options: 792 This message will carry one or more TLV-encoded mobility options. 793 The valid mobility options for this message are the following: 795 * Mobile Node Identifier option (mandatory) 797 * Home Network Prefix option (optional) 799 There can be one or more instances of the Home Network Prefix 800 option, but only one instance of the Mobile Node Identifier 801 option. 803 4.4. New PBA timer in the LMA 805 A new timer named "PBA timer" is used in the LMA to define the 806 maximum waiting time before the PBA message is sent to the nMAG in 807 case the multicast subscription information relative to the MN is not 808 yet available. The aim of this timer is to prevent potential large 809 delays in the forwarding of unicast traffic towards the MN being 810 registered at the nMAG. This timer allows decoupling the unicast 811 signaling from the multicast one. 813 This timer SHOULD be upper bounded by the constant defined in 814 [RFC6275] INIT_BINDACK_TIMEOUT, whose default value is 1 s. This 815 constant sets the time when the nMAG will retry the MN registration 816 by sending again the PBU message. The "PBA timer" has to ensure that 817 the nMAG does not enter the retry mode. 819 5. Signaling processes description 821 A number of new signaling processes are introduced with this 822 solution. Next sections describe these new processes in detail. 824 5.1. Multicast Activity signaling 826 This solution makes use of the flag A to keep track of existing 827 multicast activity in a certain MN. The idea behind this is to 828 define a mechanism which helps the LMA to decide whether to 829 interrogate or not the pMAG about potential subscription information. 831 This signaling message is used to allow the LMA to distinguish among 832 MNs with on-going multicast subscription, and MN without active 833 multicast status. This differentiation further allows to apply the 834 optimization procedure only to those MNs with active multicast 835 subscription (no actions are taken for MN without active multicast 836 subscription). 838 5.1.1. Multicast Activity set to ON (A=1) 840 Figure 2 summarizes this process. 842 +-----+ +-----+ +-----+ 843 | MN1 | | MAG | | LMA | 844 +-----+ +-----+ +-----+ 845 | | | 846 1) | |==Bi-Dir Tunnel=| 847 | | | 848 | unicast data | | 849 |<-v-v-v-v-v-v-v-| | 850 | | | 851 | MLD Rep(S,G) | | 852 |--------------->| Act Ind(start) | 853 2) | |--------------->| 854 | (S,G) Data | (flag A = 1) 855 |<---------------| Act Ind Ack | 856 | |<---------------| 857 | | | 859 Figure 2: Multicast Activity set to ON 861 The sequence of messages is the following: 863 1. An MN, named MN1, is attached to the MAG. The MN is a multicast- 864 enabled node, and it is only receiving unicast traffic as usual 865 in PMIPv6 domains, with no multicast subscription yet. At some 866 point in time, the MN1 requests to the MAG to be subscribed to 867 the content identified by the IP addresses (S,G), by sending a 868 standard MLD report from the MN to the MAG. The MAG will keep 869 the multicast status state of the point-to-point link with the 870 MN. In case the MAG has not already subscribed to the multicast 871 flow (S,G) it joins the content on behalf of MN. Multicast flow 872 (S,G) is subsequently forwarded by the MAG to the MN1. 874 2. Due to this initial multicast subscription for the MN1, the MAG 875 triggers the multicast Activity Indication message towards the 876 LMA, to indicate that the MN1 multicast activity is ON. The LMA 877 will set the flag A to 1. Afterwards, the LMA sends an Activity 878 Indication Ack message to the MAG to acknowledge the previous 879 indication. 881 5.1.2. Multicast Activity set to OFF (A=0) 883 Figure 3 presents the corresponding flow. 885 +-----+ +-----+ +-----+ 886 | MN1 | | MAG | | LMA | 887 +-----+ +-----+ +-----+ 888 | | | 889 | MLD Done(S,G) | | 890 1) |---------------->X stops fwrding | 891 | | | 892 | | Act Ind(stop) | 893 2) | |--------------->| 894 | | (flag A = 0) 895 | | Act Ind Ack | 896 | |<---------------| 897 | | | 899 Figure 3: Multicast Activity set to OFF 901 The message flow is as follows: 903 1. Some time later, the MN1 decides to totally stop all the active 904 multicast subscriptions that it maintains. The MN1 will send an 905 MLD Done message to the MAG to request the cease of the multicast 906 traffic delivery. As a consequence, the MAG will stop all the 907 multicast traffic forwarding to the MN1. 909 2. After removing the active subscriptions for the MN1, the MAG 910 sends a multicast Activity Indication message to the LMA 911 indicating that the MN1 multicast activity is OFF. The LMA will 912 set the flag A to 0, its default value. Afterwards, the LMA 913 sends an Activity Indication Ack message to the MAG to 914 acknowledge the previous indication. 916 5.2. Handover signaling procedures 918 As the MN moves from one access gateway to another, the mobility- 919 related signaling due to the handover event is carried out 920 independently by the pMAG and the nMAG. That signaling process is 921 not synchronized and, thus, two scenarios need to be considered 922 depending on the order in which the LMA receives notification of the 923 MN registration and de-registration in the nMAG and the pMAG 924 respectively. 926 5.2.1. Handover of proactive type 928 5.2.1.1. Rationale 930 In the proactive case, the MN is firstly de-registered by the pMAG, 931 and later on it is registered by the nMAG as consequence of changing 932 the point of attachment. 934 Only for those MNs which maintain an active multicast subscription, 935 the pMAG will include, as part of the PBU message (with flag S set to 936 1), the new TLV-encoded mobility option "Active Multicast 937 Subscription" carrying the multicast context of the MN at that 938 moment. 940 The LMA will store that information in the corresponding binding 941 cache. If, later on, the MN attaches to a nMAG, this information 942 will be sent (using the same TLV option) to the nMAG as part of the 943 PBA confirmation of the registration process (the PBU message sent by 944 the nMAG SHOULD set the flag S to 1). On the other hand, if no 945 further registration happens, the multicast information will be 946 removed together with the rest of binding database for that MN. 948 After receiving the multicast context, the nMAG can subscribe to the 949 multicast flow(s) on behalf of the MN if there is no other MN 950 receiving it already at the nMAG. The multicast status can be also 951 set in advance for the point-to-point link towards the MN. 953 Note that the solution described here does not prevent benefiting 954 from extended support in the mobile node/network that facilitates the 955 proactive mode operation of the solution, e.g., based on layer-2 956 capabilities. 958 5.2.1.2. Message flow description 960 Figure 4 summarizes this process. 962 +-----+ +----+ +-----+ +----+ 963 | MN | |pMAG| | LMA | |nMAG| 964 +-----+ +----+ +-----+ +----+ 965 | | | | 966 | |==Bi-Dir Tunnel=| | 967 | Multicast Data | | | 968 |<---------------| | | 969 | | | | 970 1) MN Detached | | | 971 | MN Detached Event | | 972 | | | | 973 | |Ext'd DeReg PBU | | 974 2) | |--------------->| | 975 | | | | 976 3) | | Accept PBU | 977 | |(Multicast Subscription info stored) 978 | | | | 979 | | PBA | | 980 4) | |<---------------| | 981 | | | | 982 5) MN Attached | | | 983 | | | MN Attached Event 984 | | | | 985 | | | PBU | 986 6) | | |<---------------| 987 | | | | 988 | | | Ext'd PBA | 989 7) | | |--------------->| 990 | | | | 991 8) | | | Accept PBA, 992 | | | Multicast Group join 993 | | | and P-t-P status setup 994 | | | | 995 | | |==Bi-Dir Tunnel=| 996 | | | | 997 | | | Multicast Data | 998 |<-------------------------------------------------| 999 | | | | 1000 | | | | 1002 Figure 4: Proactive handover 1004 The message flow is as follows: 1006 1. A registered MN is receiving a multicast content which has been 1007 previously subscribed to by sending a standard MLD report from 1008 the MN to the currently serving MAG, pMAG. The pMAG keeps the 1009 multicast status state of the point-to-point link with the MN. 1011 2. The MN perceives a better radio link and decides to initiate a 1012 handover process over a radio access controlled by a new MAG, 1013 nMAG. As a consequence, pMAG determines a detach event 1014 corresponding to this MN, and updates the attachment status of 1015 this MN to the LMA by sending an extended Proxy Binding Update 1016 message, including a new TLV-encoded option, named "Active 1017 Multicast Subscription", which contains the multicast context of 1018 the active multicast subscriptions in the moment of handover. 1020 3. The LMA processes the PBU message. Additionally, the LMA stores 1021 in the Binding Cache the information regarding the on-going 1022 multicast subscription(s) when the detachment is initiated. This 1023 information will be kept until a new registration of the MN is 1024 completed by another MAG, or till the Binding Cache expiration, 1025 according to [RFC5213]. 1027 4. The LMA acknowledges to the pMAG the previous PBU message. 1029 5. As a result of the handover process, the MN attaches to another 1030 MAG, called nMAG. 1032 6. The nMAG triggers a registration process by sending a PBU message 1033 (with flag S set to 1) to the LMA. 1035 7. After the analysis of the PBU message, the LMA sends an extended 1036 PBA including the new "Active Multicast Subscription" option, 1037 which contains the multicast context of the active subscriptions 1038 in the moment of handover. 1040 8. The nMAG processes the PBA message following all the standard 1041 procedures described in [RFC5213]. Additionally, with the new 1042 information relative to multicast subscription, the nMAG will set 1043 up the multicast status of the point-to-point link between the 1044 nMAG and the MN, and will join the content identified by (S,G) on 1045 behalf of the MN in case the nMAG is not receiving already such 1046 content due to a previous subscription ordered by another MN 1047 attached to it. From that instant, the multicast content is 1048 served to the MN. 1050 5.2.2. Handover of reactive type 1052 5.2.2.1. Rationale 1054 In the reactive case, the LMA receives the MN registration from the 1055 nMAG without having previously received the MN de-registration from 1056 the pMAG. 1058 As the nMAG is not aware of any active multicast subscription of the 1059 MN, the nMAG will start a conventional registration process, by 1060 sending a normal PBU message (with flag S set to 1) towards the LMA. 1062 After receiving the PBU message from the nMAG, the LMA will take the 1063 decision of interrogating or not the pMAG regarding any existing 1064 multicast subscription for that MN. This decision is taken following 1065 a procedure that is described later in section Section 5.2.3. 1067 Once the multicast subscription information is retrieved from the 1068 pMAG, the LMA encapsulates it in the PBA message by using the TLV 1069 option "Active Multicast Subscription", and forwards the PBA message 1070 to the nMAG. Then, the nMAG can subscribe the multicast flow on 1071 behalf of the MN, if there is no other MN receiving it already at the 1072 nMAG. The multicast status can be also set in advance for the point- 1073 to-point link towards the MN. 1075 5.2.2.2. Message flow description 1077 Figure 5 and Figure 6 summarize this process. 1079 +-----+ +-----+ +----+ +-----+ +----+ 1080 | MN1 | | MN2 | |pMAG| | LMA | |nMAG| 1081 +-----+ +-----+ +----+ +-----+ +----+ 1082 | | | | | 1083 | | | | MN1 Attached Event 1084 | | | | | 1085 | | | | PBU | 1086 1) | | | |<---------------| 1087 | | | LMA decision | 1088 | | | | | 1089 | | | Subscr Query | | 1090 2) | | |<---------------| | 1091 | | | | | 1092 | | | Subscr Resp | | 1093 3) | | |--------------->| | 1094 | | | | | 1095 | | | (Multicast Subscription | 1096 | | | info forwarding) | 1097 | | | | | 1098 | | | | Ext'd PBA | 1099 4) | | | |--------------->| 1100 | | | | | 1101 5) | | | | Accept PBA, 1102 | | | | Multicast Group join 1103 | | | | and P-t-P status setup 1104 | | | | | 1105 | | | |==Bi-Dir Tunnel=| 1106 | | | | | 1107 | | | | (S,G) Data | 1108 |<-------------------------------------------------| 1109 | | | | | 1110 ~ ~ ~ ~ ~ 1111 ~ ~ ~ ~ ~ 1113 Figure 5: Reactive handover (steps 1 to 5) 1115 Consider as starting point the situation where a couple of MNs, named 1116 MN1 and MN2, are attached to the pMAG, both MNs being multicast- 1117 enabled nodes, but only MN1 maintains an active multicast 1118 subscription at this moment. As consequence, the value of the A flag 1119 in the LMA is set to 1 for MN1, and set to 0 for MN2. 1121 The sequence of messages for the handover of MN1 and MN2 is the 1122 following (as depicted in Figure 5): 1124 1. At certain time, the MN1 perceives a better radio link and 1125 decides to attach at a new MAG, nMAG, in a handover process (as 1126 it is a reactive case, the pMAG is not aware of the detachment 1127 process). Then, the nMAG triggers a registration process by 1128 sending a PBU message (with flag S set to 1) to the LMA. 1130 2. Prior to acknowledge the received PBU message, the LMA checks the 1131 status of the A flag for this MN. Due that the flag A=1, the LMA 1132 interrogates the pMAG about if there is any active multicast 1133 subscription for the MN1, by sending a Subscription Query 1134 message. 1136 3. The pMAG answers the LMA with a Subscription Response message 1137 including the multicast context of the existing subscriptions. 1139 4. After processing the pMAG answer, the LMA acknowledges (with flag 1140 S set to 1) the PBU message, including the multicast subscription 1141 information within the new TLV-encoded option "Active Multicast 1142 Subscription". The nMAG then processes the extended PBA message. 1144 5. The nMAG processes the PBA message, and it proceeds to set up the 1145 multicast status of the point-to-point link between the nMAG and 1146 the MN1, and to join the content identified by (S,G) on behalf of 1147 the MN1 in case the nMAG is not receiving already such content. 1148 (The bidirectional tunnel is also set up between the nMAG and the 1149 LMA if it has not been established before by another MN 1150 connection). At this moment, the multicast content can be served 1151 to the MN1. The unicast traffic for the MN1 can be forwarded as 1152 well. 1154 +-----+ +-----+ +----+ +-----+ +----+ 1155 | MN1 | | MN2 | |pMAG| | LMA | |nMAG| 1156 +-----+ +-----+ +----+ +-----+ +----+ 1157 | | | | | 1158 ~ ~ ~ ~ ~ 1159 ~ ~ ~ ~ ~ 1160 | | | | | 1161 | | | | MN2 Attached Event 1162 | | | | | 1163 | | | | PBU | 1164 6) | | | |<---------------| 1165 | | | LMA decision | 1166 | | | | PBA | 1167 7) | | | |--------------->| 1168 | | | | | 1169 8) | | | | Accept PBA 1170 | | | | | 1172 Figure 6: Reactive handover (steps 6 to 8) 1174 6. In parallel, the MN2 perceives a better radio link and decides to 1175 attach also to the nMAG in a reactive handover process as well 1176 (the pMAG is not aware of this detachment process either). Then, 1177 the nMAG triggers a registration process by sending a PBU message 1178 (with flag S set to 1) to the LMA. 1180 7. Prior to acknowledge the received PBU message, the LMA checks the 1181 status of the A flag for this MN. Due that the flag A=0, the LMA 1182 does not interrogate the pMAG, and acknowledges the PBU message 1183 (with flag S set to 0). The nMAG then processes PBA message. 1185 8. The nMAG is now ready to forward the unicast traffic to the MN2. 1187 5.2.2.3. Further considerations for the reactive handover signaling 1189 A handover event is managed independently by the pMAG and nMAG. It 1190 is not a synchronized process. In a reactive handover, the LMA will 1191 receive a registration PBU from nMAG before a de-registration PBU 1192 from pMAG, if any. 1194 In the message flows detailed above, it could be the case that the 1195 LMA receives a de-registration PBU from pMAG just after sending the 1196 Subscription Query message, but before receiving the Subscription 1197 Response message. That de-registration PBU message from pMAG will 1198 carry the multicast subscription information required to assist the 1199 MN in the handover, so such valuable information SHOULD be kept by 1200 the LMA. Furthermore, it is possible that once the Subscription 1201 Query message arrives to pMAG, the pMAG could have already removed 1202 the multicast related information for the MN. 1204 In order to avoid losing the multicast subscription information sent 1205 in the de-registration PBU message, the LMA SHOULD store it, and 1206 include it in the PBA message towards the nMAG in case the 1207 Subscription Response message from the pMAG does not contain 1208 multicast subscription information for the MN. 1210 5.2.3. LMA decision process 1212 A key point of the solution proposed in this document resides on the 1213 LMA decision of interrogating the pMAG about a potential active 1214 subscription of the MN entering the nMAG. Several variables take 1215 place, and it is required to define a mechanism for assisting the LMA 1216 in its decision process. 1218 Basically two flags will be used. One flag, the named "multicast 1219 Signaling" or S flag, is used to signal the multicast capabilities of 1220 the MAGs and the transport of the multicast subscription information 1221 within the PBU/PBA messages. The other one, the named "multicast 1222 Activity" or A flag, is used to register on the LMA whether the MN is 1223 maintaining an active multicast subscription or not. 1225 The following sections summarize the use of these flags on the LMA 1226 decision process. 1228 5.2.3.1. LMA processing of S flag on reception of PBU messages 1230 5.2.3.1.1. Proactive handover 1232 In the event of proactive handover, the pMAG has previously informed 1233 the LMA about any potential subscription information currently active 1234 in the MN. The actions to be carried out by the LMA once it receives 1235 the PBU message from the nMAG are summarized in the table below. 1237 +---------+---------+------------------------+----------------------+ 1238 |multicast|multicast| | | 1239 |signaling|activity | Meaning | LMA action | 1240 | flag S | flag A | | | 1241 | in PBU | in LMA | | | 1242 +---------+---------+------------------------+----------------------+ 1243 | | |- Multicast not | | 1244 | | A=0 | supported by nMAG |- MN registration as | 1245 | | |- No active subscription| in RFC 5213 | 1246 | | | by MN | (S=0 in PBA) | 1247 | S=0 +---------+------------------------+----------------------+ 1248 | | |- Multicast not |- LMA stores multicast| 1249 | | A=1 | supported by nMAG | subscription info | 1250 | | |- Active subscription |- MN registration as | 1251 | | | by MN | in RFC 5213 | 1252 | | | | (S=0 in PBA) | 1253 +---------+---------+------------------------+----------------------+ 1254 | | |- Multicast supported by| | 1255 | | A=0 | nMAG |- MN registration as | 1256 | | |- No active subscription| in RFC 5213 | 1257 | | | by MN | (S=0 in PBA) | 1258 | S=1 +---------+------------------------+----------------------+ 1259 | | | |- LMA stores multicast| 1260 | | |- Multicast supported by| subscription info | 1261 | | A=1 | nMAG |- MN registration | 1262 | | |- Active subscription | conveys multicast | 1263 | | | by MN | subscription info | 1264 | | | | (S=1 in PBA) | 1265 +---------+---------+------------------------+----------------------+ 1267 Figure 7: Flag processing on LMA for proactive handover 1269 5.2.3.1.2. Reactive handover 1271 In the event of reactive handover, the LMA is not aware about any 1272 potential subscription information currently active in the MN. The 1273 actions to be carried out by the LMA once it receives the PBU message 1274 from the nMAG are summarized in the table below. 1276 +---------+---------+------------------------+----------------------+ 1277 |multicast|multicast| | | 1278 |signaling|activity | Meaning | LMA action | 1279 | flag S | flag A | | | 1280 | in PBU | in LMA | | | 1281 +---------+---------+------------------------+----------------------+ 1282 | | |- Multicast not supported| | 1283 | | A=0 | by nMAG |- MN registration as | 1284 | | |- No active subscription | in RFC 5213 | 1285 | | | by MN | (S=0 in PBA) | 1286 | S=0 +---------+-------------------------+---------------------+ 1287 | | |- Multicast not supported|- LMA does not | 1288 | | A=1 | by nMAG | interrogate pMAG | 1289 | | |- Active subscription |- MN registration as | 1290 | | | by MN | in RFC 5213 | 1291 | | | | (S=0 in PBA) | 1292 +---------+---------+-------------------------+---------------------+ 1293 | | |- Multicast supported by |- LMA does not | 1294 | | A=0 | nMAG | interrogate pMAG | 1295 | | |- No active subscription |- MN registration as | 1296 | | | by MN | in RFC 5213 | 1297 | | | | (S=0 in PBA) | 1298 | +---------+-------------------------+---------------------+ 1299 | | | |- LMA interrogates | 1300 | S=1 | | | pMAG to obtain | 1301 | | |- Multicast supported by | multicast | 1302 | | A=1 | nMAG | subscription | 1303 | | |- Active subscription |- MN registration | 1304 | | | by MN | conveys multicast | 1305 | | | | subscription info | 1306 | | | | (S=1 in PBA) | 1307 +---------+---------+-------------------------+---------------------+ 1309 Figure 8: Flag processing on LMA for reactive handover 1311 5.2.3.2. LMA set-up of S flag in PBA messages 1313 Once the LMA decision process is finished, the LMA builds the PBA 1314 message to complete the registration process triggered by the nMAG. 1315 The value of the S flag in the PBA message will be set according to 1316 the data specified in the table below. 1318 +---------------+-------------+-------------------------------+ 1319 | S flag | S flag | | 1320 | received in | sent in | Meaning | 1321 | PBU message | PBA message | | 1322 +---------------+-------------+-------------------------------+ 1323 | | | | 1324 | S=0 | S=0 | No further meaning | 1325 | | | | 1326 | (multicast +-------------+-------------------------------+ 1327 | not supported | | | 1328 | by nMAG) | S=1 | N/A | 1329 | | | | 1330 +-------------- +-------------+-------------------------------+ 1331 | | | | 1332 | | S=0 | No active subscription on MN | 1333 | | | | 1334 | +-------------+-------------------------------+ 1335 | S=1 | | - Mcast context available: | 1336 | (multicast is | | Multicast subscription info | 1337 | supported by | | is conveyed in the PBA | 1338 | nMAG) | | message | 1339 | | S=1 | - Mcast context not available:| 1340 | | | It has to be requested by | 1341 | | | using the Subscription Query| 1342 | | | message. | 1343 +---------------+-------------+-------------------------------+ 1345 Figure 9: S flag configuration in PBA messages 1347 5.2.4. Prevention of large delays of the binding acknowledgement for 1348 unicast traffic 1350 According to the message sequences described for the reactive 1351 handover case, in case the LMA has to request the multicast 1352 subscription information from the pMAG, the binding request sent by 1353 the nMAG is maintained on-hold till the LMA receives, processes and 1354 includes the multicast subscription information into the extended PBA 1355 message. As consequence, the unicast traffic may then suffer an 1356 extra delay motivated by the multicast-related signaling. During 1357 that time, the unicast traffic with destination the MN being 1358 registered by the nMAG MUST be buffered or discarded by the LMA. 1360 In order to avoid any potential large delay in the forwarding of 1361 unicast traffic arriving at the LMA towards the MN, a mechanism 1362 SHOULD be implemented to decouple multicast from unicast traffic 1363 reception by the MN. 1365 Figure 10 shows this mechanism: 1367 +-----+ +----+ +-----+ +----+ 1368 | MN | |pMAG| | LMA | |nMAG| 1369 +-----+ +----+ +-----+ +----+ 1370 1) | |==Bi-Dir Tunnel=| | 1371 | unicast data | | | 1372 |<-v-v-v-v-v-v-v-| | | 1373 | | | | 1374 | Multicast Data | | | 1375 |<---------------| | | 1376 | | | MN1 Attached Event 1377 | | | PBU | 1378 2) | | |<---------------| 1379 | | Subscr Query | | 1380 3) | |<---------------| | 1381 | | | | 1382 4) | | | 1383 | | /// | 1384 | | /// | 1385 5) | | | 1386 | | | | 1387 | | | Ext'd PBA | 1388 | | |--------------->| 1389 | | | | 1390 | | | Accept PBA 1391 | | | | 1392 | | |==Bi-Dir Tunnel=| 1393 | | | | 1394 | | | Unicast Data | 1395 |<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-| 1396 | | | | 1397 | | | Subscr Query | 1398 6) | | |<---------------| 1399 | | Subscr Resp | | 1400 7) | |--------------->| | 1401 | | | | 1402 | | (Multicast Subscription | 1403 | | info forwarding) | 1404 | | | | 1405 | | | Subscr Resp | 1406 8) | | |--------------->| 1407 | | | | 1408 | | | Multicast Group join 1409 | | | and P-t-P status setup 1410 | | Multicast Data | | 1411 |<-------------------------------------------------| 1412 | | | | 1414 Figure 10: Decoupling of unicast and multicast signaling 1416 The sequence of messages is the following: 1418 1. An MN is attached to the pMAG. The MN is a multicast-enabled 1419 node, and it is receiving both unicast and multicast traffic 1420 simultaneously. 1422 2. Some time later, the MN perceives a better radio link and decides 1423 to attach at a new MAG, nMAG, in a handover process (as a 1424 reactive case, the pMAG is not aware of the detachment process). 1425 Then, the nMAG triggers a registration process by sending a PBU 1426 message (with flag S set to 1) to the LMA. 1428 3. Prior to acknowledge the received PBU message, the LMA decides to 1429 interrogate the pMAG about if there is any active multicast 1430 subscription for the MN, by sending a Subscription Query message. 1431 The LMA decision is based on the checking of flag A when the 1432 reactive handover manages the multicast activity indication. 1434 4. Immediately after sending the Subscription Query message, the LMA 1435 starts the timer "PBA timer", which determines the maximum 1436 waiting time before the PBA is sent to avoid any potential large 1437 delay in the forwarding of unicast traffic towards the MN. 1439 5. In case the "PBA timer" expires, the LMA acknowledges the PBU 1440 message, by sending the PBA message with flag S=1, without the 1441 multicast context information. The nMAG then processes the 1442 extended PBA message. Such acknowledgement will allow the MN to 1443 receive the unicast traffic from that time on. The bidirectional 1444 tunnel is also set up between the nMAG and the LMA if it has not 1445 been established before. 1447 6. In parallel, the nMAG sends a Subscription Query message to the 1448 LMA requesting the multicast-subscription details yet unknown for 1449 the MN. 1451 7. The pMAG answers the Subscription Query message originally sent 1452 by the LMA, including the multicast context. 1454 8. After processing the pMAG answer, the LMA sends a Subscription 1455 Response message to the nMAG, including the multicast 1456 subscription information within the new TLV-encoded option 1457 "Active Multicast Subscription". The nMAG processes the PBA 1458 message, and it proceeds to set up the multicast status of the 1459 point-to-point link between the nMAG and the MN, and to join the 1460 content identified by (S,G) on behalf of the MN in case the nMAG 1461 is not receiving already such content. The bidirectional tunnel 1462 is also set up between the nMAG and the LMA if it has not been 1463 established before. At this moment, the multicast content can 1464 also be served to the MN. 1466 6. Co-existence with PMIPv6 multicast architectural evolutions 1468 Along this document, it has been considered that the LMA entity is in 1469 charge of delivering both unicast and multicast traffic to a certain 1470 MN through the bi-directional tunnels connecting to the MAG where the 1471 MN is attached, as specified in the base solution defined in 1472 [RFC6224]. However, the solution described in this memo is not only 1473 applicable to the base solution, but it can also be applied to the 1474 solutions described in [I-D.ietf-multimob-pmipv6-ropt] to solve the 1475 tunnel convergence problem. 1477 The Multicast Tree Mobility Anchor (MTMA) solution in 1478 [I-D.ietf-multimob-pmipv6-ropt] makes use of a separate entity to 1479 serve multicast traffic through distinct tunnels connected to the 1480 MAGs. The tunnels for multicast traffic could not be set up in 1481 advance if they are dynamical in nature. 1483 When the "multicast activity" flag is also present in the MN's policy 1484 store, the nMAG knows in advance the multicast activity of the 1485 incoming MN. Consequently, the nMAG can trigger the multicast tunnel 1486 set up in parallel to the registration process, including the 1487 acquisition of the active multicast subscription details (the 1488 multicast context), saving time on serving the multicast flow to the 1489 incoming MN. The concrete procedure for multicast tunnel 1490 establishment is out of the scope of this document. 1492 7. Security Considerations 1494 This proposal does not pose any additional security threats to those 1495 already identified in [RFC5213]. All the security considerations in 1496 [RFC5213] are directly applicable to this protocol. The signaling 1497 messages, Proxy Binding Update, and Proxy Binding Acknowledgement 1498 (extended with the new options defined in this document), the 1499 Subscription Query Message, the Subscription Response Message, the 1500 Multicast Activity Indication and the Multicast Activity Indication 1501 Acknowledge, exchanged between the mobile access gateway and the 1502 local mobility anchor, MUST be protected using end-to-end security 1503 association(s) offering integrity and data origin authentication. 1505 The mobile access gateway and the local mobility anchor MUST 1506 implement the IPsec security mechanism mandated by Proxy Mobile IPv6 1507 [RFC5213] to secure the signaling described in this document. In the 1508 following, we describe the Security Policy Database (SPD) and 1509 Security Association Database (SAD) entries necessary to protect the 1510 new signaling introduced by this specification (Subscription Query 1511 Message, Subscription Response Message, Multicast Activity Indication 1512 and Multicast Activity Indication Acknowledge). We use the same 1513 format used by [RFC4877]. The SPD and SAD entries are only example 1514 configurations. A particular mobile access gateway implementation 1515 and a local mobility anchor home agent implementation could configure 1516 different SPD and SAD entries as long as they provide the required 1517 security of the signaling messages. 1519 For the examples described in this document, a mobile access gateway 1520 with address "mag_address_1", and a local mobility anchor with 1521 address "lma_address_1" are assumed. 1523 mobile access gateway SPD-S: 1524 - IF local_address = mag_address_1 & 1525 remote_address = lma_address_1 & 1526 proto = MH & (remote_mh_type = Subscription Query | 1527 local_mh_type = Subscription Response | 1528 remote_mh_type = Multicast Activity Indication Ack.| 1529 local_mh_type = Multicast Activity Indication) 1530 Then use SA1 (OUT) and SA2 (IN) 1532 mobile access gateway SAD: 1533 - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): 1534 local_address = mag_address_1 & 1535 remote_address = lma_address_1 & 1536 proto = MH 1537 - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): 1538 local_address = lma_address_1 & 1539 remote_address = mag_address_1 & 1540 proto = MH 1542 local mobility anchor SPD-S: 1543 - IF local_address = lma_address_1 & 1544 remote_address =mag_address_1 & 1545 proto = MH & (remote_mh_type = Subscription Response | 1546 local_mh_type = Subscription Query | 1547 remote_mh_type = Multicast Activity Indication | 1548 local_mh_type = Multicast Activity Indication Ack.) 1549 Then use SA2 (OUT) and SA1 (IN) 1551 local mobility anchor SAD: 1552 - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): 1553 local_address = lma_address_1 & 1554 remote_address = mag_address_1 & 1555 proto = MH 1556 - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): 1557 local_address = mag_address_1 & 1558 remote_address = lma_address_1 & 1559 proto = MH 1561 8. IANA Considerations 1563 This document defines the new following elements which values to be 1564 allocated by IANA: 1566 o Mobility Header types: the Subscription Query and Subscription 1567 Response, and the Multicast Activity Indication and Multicast 1568 Activity Indication Acknowledge mobility header types. 1570 o Mobility options: the Active Multicast Subscription mobility 1571 option. 1573 o Flags: the multicast Signaling (S), the multicast Information (I), 1574 and the multicast Active (A) flags. 1576 9. Contributors 1578 Dirk Von Hugo (Telekom Innovation Laboratories, 1579 Dirk.von-Hugo@telekom.de) extensively contributed to this document. 1581 10. Acknowledgments 1583 The authors would like to thank (in alphabetical order) Hitoshi 1584 Asaeda, Marco Liebsch, Behcet Sarikaya, Thomas C. Schmidt and Stig 1585 Venaas for their valuable comments and discussions on the Multimob 1586 mailing list. The authors are also grateful with Hitoshi Asaeda, 1587 Akbar Rahman and Behcet Sarikaya for their review of this document. 1589 The research of Carlos J. Bernardos leading to these results has 1590 received funding from the European Community's Seventh Framework 1591 Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL 1592 project), being also partially supported by the Ministry of Science 1593 and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 1594 13992-C02-01). 1596 The research of Ignacio Soto has also received funding from the 1597 Spanish MICINN through the I-MOVING project (TEC2010-18907). 1599 11. References 1600 11.1. Normative References 1602 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1603 Requirement Levels", BCP 14, RFC 2119, March 1997. 1605 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1606 Listener Discovery (MLD) for IPv6", RFC 2710, 1607 October 1999. 1609 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1610 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1611 April 2007. 1613 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1614 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1616 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1617 in IPv6", RFC 6275, July 2011. 1619 11.2. Informative References 1621 [I-D.ietf-multimob-pmipv6-ropt] 1622 Zuniga, J., Contreras, L., Bernardos, C., Jeon, S., and Y. 1623 Kim, "Multicast Mobility Routing Optimizations for Proxy 1624 Mobile IPv6", draft-ietf-multimob-pmipv6-ropt-01 (work in 1625 progress), September 2012. 1627 [I-D.von-hugo-multimob-future-work] 1628 Hugo, D., Asaeda, H., Sarikaya, B., and P. Seite, 1629 "Evaluation of further issues on Multicast Mobility: 1630 Potential future work for WG MultiMob", 1631 draft-von-hugo-multimob-future-work-02 (work in progress), 1632 June 2010. 1634 [Papagiannaki, et al.] 1635 Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and 1636 C. Diot, "Measurement and Analysis of Single-Hop Delay on 1637 an IP Backbone Network", IEEE Journal on Selected Areas in 1638 Communications, vol.21, no.6, August , 2003. 1640 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1641 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1643 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 1644 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 1645 September 2010. 1647 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1648 Deployment for Multicast Listener Support in Proxy Mobile 1649 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1651 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1652 the Internet Group Management Protocol (IGMP) and 1653 Multicast Listener Discovery (MLD) for Routers in Mobile 1654 and Wireless Networks", RFC 6636, May 2012. 1656 [Verizon] "LTE: The Future of Mobile Broadband Technology", Verizon 1657 White Paper (http://opennetwork.verizonwireless.com/pdfs/ 1658 VZW_LTE_White_Paper_12-10.pdf) , 2010. 1660 [Y.1541] "Network performance objectives for IP-based services", 1661 ITU-T Recommendation Y.1541, December , 2011. 1663 Appendix A. Performance comparison with base solution 1665 This appendix briefly analyzes and compares the performance 1666 improvement provided by the fast handover extensions specified in 1667 this document with the base multicast solution defined in [RFC6224]. 1668 The main aim is to determine the potential delay reduction in the 1669 acquisition of the multicast subscription information by the nMAG 1670 during the MN handover. To do that, the analysis will focus on the 1671 delay additional to the unicast handover due to the multicast 1672 operation in both cases. 1674 Different delay components have to be taken into account for this 1675 comparison. Since the interaction between the actors during the 1676 handover process (MN, pMAG, nMAG, LMA) is different for each of the 1677 solutions, then different sources of delay can be expected for each 1678 of them. 1680 A.1. Delay characterization of the base solution 1682 The base solution relies on the standard MLD procedures to obtain the 1683 multicast subscription information directly from the MN. Once the 1684 nMAG completes the configuration of point-to-point link to the 1685 attaching MN (the configuration of this link as downstream interface 1686 of an MLD proxy instance can run in parallel), it immediately sends 1687 an MLD General Query towards the MN for getting knowledge of any 1688 active multicast subscription by the MN. When the MN receives the 1689 MLD Query, the MN provides information about the active memberships 1690 it maintains in the form of an MLD Report message. After successful 1691 transmission of this information via the wireless point of attachment 1692 to nMAG the corresponding MLD proxy instance at the nMAG will set up 1693 the multicast status of the downstream interface. According to this 1694 process, the delay is originated on the MAG-MN communication. 1696 The delay components to be considered for the base solution are the 1697 following: 1699 o D_bh, which is the unidirectional (one way) delay encountered in 1700 the transmission path between the nMAG and the wireless point of 1701 attachment 1703 o D_radio, which is the unidirectional delay due to the transfer of 1704 MLD control messages over the radio channel (user plane) between 1705 the wireless point of attachment and the MN, for the MLD Query and 1706 Report messages. 1708 o D_mld, which is the delay incurred by the MN to answer the MLD 1709 Query. 1711 The total observed delay can be then formulated as: 1713 D_base = 2 x (D_bh + D_radio) + D_mld 1715 A.2. Delay characterization of the SIAL solution 1717 As described in this document, it is possible to distinguish two 1718 scenarios depending on the order in which the LMA receives the 1719 notifications of the MN registration and de-registration in the nMAG 1720 and the pMAG respectively. 1722 In the proactive case, the MN is firstly de-registered by the pMAG, 1723 and later on it is registered by the nMAG. As specified in this 1724 document, the LMA will store the multicast subscription information, 1725 which will be provided to the nMAG during the MN registration 1726 process. Since the registration process necessarily happens before 1727 the MLD Query and Report process described in the base solution, the 1728 proactive case is inherently faster than the base solution. In fact, 1729 since the multicast subscription information is acquired properly 1730 during the registration process, the delay incurred is null. 1732 In the reactive case, the LMA receives the MN registration from the 1733 nMAG without having previously received the MN de-registration from 1734 the pMAG. In case the MN maintains an active subscription, the LMA 1735 will interrogate the pMAG to retrieve the multicast subscription 1736 information, which is forwarded to the nMAG. According to this 1737 process, the delay is originated on the MAG-LMA communication. 1739 The delay components to be considered for the base solution are the 1740 following: 1742 o D_net, which is the unidirectional delay found in the network path 1743 between the LMA and the MAG. 1745 The total observed delay can be then formulated as: 1747 D_sial = 2 x D_net 1749 A.3. Performance comparison 1751 The performance of the base solution is highly dependent on the radio 1752 technology used by the MN to attach to the PMIPv6-Domain. Different 1753 radio technologies have distinct properties in terms of radio 1754 framing, radio access contention or collision avoidance, channel 1755 reliability, etc. 1757 New radio access technologies, such as the one specified in new Long 1758 Term Evolution (LTE) standards intend to reduce the latency in order 1759 to provide high speed communications. Even though, typical one-way 1760 latencies in the LTE radio access will stay around 15 ms [Verizon]. 1762 The backhaul delay characterization becomes problematic. In a real 1763 network there are several solutions for the backhaul connection in 1764 terms of network topology (ring, star, point-to-point, etc) and 1765 technology (optical fiber, microwave transmission, xDSL-based 1766 accesses, etc), all of them having distinct properties in terms of 1767 performance, reliability and delay. These solutions commonly coexist 1768 in a real mobile network, in such a way that an MN changing the point 1769 of attachment can pass smoothly from one solution to another. A 1770 value of D_bh=5 ms can be established as typical value for the 1771 backhaul latency in modern networks. 1773 Finally, the MLD induced delay is intrinsic to the MLD protocol 1774 specification. A host receiving an MLD Query message will wait a 1775 random time in the range (0, Maximum Response Delay) to send the MLD 1776 Report message. The default value of the Maximum Response Delay 1777 (configurable through the Query Response Interval in MLD) is 10 s in 1778 [RFC2710], or 5 s in the best case described in [RFC6636]. Then, in 1779 average, it can be expected a potential delay of 5 or 2,5 s, 1780 respectively. 1782 As we have seen, D_base is, on average, greater than 2,5 sec with the 1783 best case of the values of Query Response Interval in MLD that are 1784 recommended in [RFC6636]. That means that the handover delay of the 1785 base solution is on the order of seconds while in the solution 1786 presented in this specification it is on the order of milliseconds 1787 (as it is shown below). To improve the performance of the base 1788 solution we could further reduce the value of Query Response Interval 1789 but the implications of doing so would need to be carefully analyzed. 1790 Even if we assume that Query Response Interval is 0 sec, D_base would 1791 be of around 2 x (5 ms + 15 ms) = 40 ms for last generation systems. 1792 Note that this calculation does not take into account the necessary 1793 time to re-establish the data plane after the handover to make 1794 possible the MLD Query reception. The expected delay will get much 1795 worse for older generation systems (e.g., 3G-based radio systems can 1796 suffer radio delays in the order of hundreds of ms). 1798 For the SIAL case, the delay in the MAG-LMA communication will be 1799 derived from the network diameter (i.e., the number of hops found 1800 between the MAG and the LMA in the PMIPv6-Domain). This is largely 1801 influenced by the internal network planning. An administrative 1802 domain can typically have in the order of 5 hops from access to the 1803 interconnection gateway providing connectivity to other networks. 1804 Even if the LMA plays a central role topologically in the PMIPv6 1805 domain, such number of hops seems reasonable in a common nation-wide 1806 network. Each hop in the path between MAG and LMA will add a certain 1807 delay, which can be estimated to be around 1 ms in the best case 1808 [Papagiannaki, et al.] and 3 ms in the worst case [Y.1541]. With 1809 this in mind, a total delay D_sial of around 2 x 5 x 3 ms = 30 ms can 1810 be expected in the worst case. 1812 Then, as conclusion, in a typical deployment, it can be stated that 1813 SIAL proposal, even for the worst-case consideration, will perform 1814 better than the best case situation for the base solution, which 1815 consists of the last generation radio technology, LTE. For any other 1816 radio technology the base solution will show even larger deviation 1817 from the delay achievable with the SIAL proposal. 1819 Appendix B. Change Log 1821 The following changes has been made from -00 version. 1823 1. Multicast Address Record format defined in [RFC3810] has been 1824 adopted for transfering multicast subscrition information in the 1825 Active Multicast Subscription mobility option. 1827 The following changes has been made from -01 version. 1829 1. A new appendix has been created to include a performance 1830 comparison between this proposal and the base solution. 1832 2. Comments from Akbar Rahman review has been addressed. 1834 The following changes has been made from -02 version. 1836 1. Minor editorial corrections. 1838 Authors' Addresses 1840 Luis M. Contreras 1841 Telefonica I+D 1842 Don Ramon de la Cruz, 82-84 1843 Madrid 28006 1844 Spain 1846 Email: lmcm@tid.es 1848 Carlos J. Bernardos 1849 Universidad Carlos III de Madrid 1850 Av. Universidad, 30 1851 Leganes, Madrid 28911 1852 Spain 1854 Phone: +34 91624 6236 1855 Email: cjbc@it.uc3m.es 1856 URI: http://www.it.uc3m.es/cjbc/ 1858 Ignacio Soto 1859 Universidad Carlos III de Madrid 1860 Av. Universidad, 30 1861 Leganes, Madrid 28911 1862 Spain 1864 Email: isoto@it.uc3m.es