idnits 2.17.1 draft-ietf-multimob-handover-optimization-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 26, 2013) is 3767 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. 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: June 29, 2014 I. Soto 6 UC3M 7 December 26, 2013 9 PMIPv6 multicast handover optimization by the Subscription Information 10 Acquisition through the LMA (SIAL) 11 draft-ietf-multimob-handover-optimization-07 13 Abstract 15 This document specifies an experimental multicast handover 16 optimization mechanism for Proxy Mobile IPv6 to accelerate the 17 delivery of multicast traffic to mobile nodes after handovers. The 18 mechanism is based on speeding up the acquisition of mobile nodes' 19 multicast context by the mobile access gateways. To do that, 20 extensions to the current Proxy Mobile IPv6 protocol are proposed. 21 These extensions are not only applicable to the base solution for 22 multicast support in Proxy Mobile IPv6, but they can also be applied 23 to other solutions developed to avoid the tunnel convergence problem. 24 Furthermore, these extensions are also independent of the role played 25 by the mobile access gateway within the multicast network (either 26 acting as multicast listener discovery 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 June 29, 2014. 45 Copyright Notice 47 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Handover optimization 64 requirements . . . . . . . . . . . . . . . . . . . . . . 5 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 4. Proxy Mobile IPv6 extensions . . . . . . . . . . . . . . . . 8 68 4.1. Active Multicast Subscription mobility option . . . . . . 8 69 4.1.1. Option application rules . . . . . . . . . . . . . . 8 70 4.1.2. Option format . . . . . . . . . . . . . . . . . . . . 8 71 4.1.3. Backward compatibility with MLDv1 . . . . . . . . . . 9 72 4.2. Multicast Signaling flag on PBU/PBA message headers . . . 10 73 4.2.1. Flag application rules . . . . . . . . . . . . . . . 10 74 4.2.1.1. Registration process . . . . . . . . . . . . . . 10 75 4.2.1.2. De-registration process . . . . . . . . . . . . . 11 76 4.2.2. New format of conventional PBU/PBA messages . . . . . 12 77 4.2.2.1. Proxy Binding Update message . . . . . . . . . . 12 78 4.2.2.2. Proxy Binding Acknowledgement Message . . . . . . 12 79 4.3. Messages for active multicast subscription query . . . . 13 80 4.3.1. Subscription Query message . . . . . . . . . . . . . 13 81 4.3.1.1. Message application rules . . . . . . . . . . . . 13 82 4.3.1.2. Message format . . . . . . . . . . . . . . . . . 13 83 4.3.2. Subscription Response message . . . . . . . . . . . . 14 84 4.3.2.1. Message application rules . . . . . . . . . . . . 14 85 4.3.2.2. Message format . . . . . . . . . . . . . . . . . 14 86 4.4. New PBA timer in the LMA . . . . . . . . . . . . . . . . 16 87 5. Handover signaling procedures . . . . . . . . . . . . . . . . 16 88 5.1. Handover of proactive type . . . . . . . . . . . . . . . 16 89 5.1.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 16 90 5.1.2. Message flow description . . . . . . . . . . . . . . 17 91 5.2. Handover of reactive type . . . . . . . . . . . . . . . . 19 92 5.2.1. Rationale . . . . . . . . . . . . . . . . . . . . . . 20 93 5.2.2. Message flow description . . . . . . . . . . . . . . 20 94 5.2.3. Further considerations for the reactive handover 95 signaling . . . . . . . . . . . . . . . . . . . . . . 22 96 5.3. Prevention of large delays of the binding 97 acknowledgement for unicast traffic . . . . . . . . . . . 23 98 6. IPv4 support . . . . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. Active Multicast Subscription for IPv4 . . . . . . . . . 26 100 6.2. Signaling procedures for IPv4 support . . . . . . . . . . 27 101 6.3. Binding Cache extensions for IPv4 support . . . . . . . . 28 102 7. Co-existence with PMIPv6 multicast architectural 103 evolutions . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 106 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 30 107 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 108 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 12.1. Normative References . . . . . . . . . . . . . . . . . . 31 110 12.2. Informative References . . . . . . . . . . . . . . . . . 32 111 Appendix A. Performance comparison with base solution . . . . . 32 112 A.1. Delay characterization of the base solution . . . . . . . 33 113 A.2. Delay characterization of SIAL . . . . . . . . . . . . . 33 114 A.3. Performance comparison . . . . . . . . . . . . . . . . . 34 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 117 1. Introduction 119 The base solution for providing continuous multicast service delivery 120 in Proxy Mobile IPv6 (PMIPv6) domains is described in [RFC6224]. It 121 specifies the basic functionality needed in the Proxy Mobile IPv6 122 [RFC5213] entities to provide a multicast service, so continuous 123 delivery of multicast traffic is supported by obtaining, after each 124 handover, the on-going multicast subscription information directly 125 from the Mobile Node (MN). When a mobile node attaches to a new 126 Mobile Access Gateway (MAG), the mobile node is queried by the mobile 127 access gateway through a Multicast Listener Discovery (MLD) General 128 Query, which is sent just after any new link is set up, to get 129 knowledge of any existing subscription, as specified in [RFC2710] and 130 [RFC3810]. 132 However, the base solution needs to be improved to meet some 133 performance requirements, especially those referring to the user 134 perceived service quality, which is seriously affected by the 135 disruption of multicast content forwarding to the mobile node during 136 handovers. 138 A mobile node with an active multicast subscription, moving from one 139 point of attachment to another within a Proxy Mobile IPv6 domain, 140 experiences a certain delay until it resumes receiving again the 141 multicast content that it was receiving at the previous location. 142 Such delay causes a gap in the content reception. Two different 143 actions can help mitigate such reception gap. One of them is to 144 buffer at the previous mobile access gateway a copy of the multicast 145 traffic destined to the mobile node and forward it to the new mobile 146 access gateway, in order to deliver that traffic to the mobile node. 147 The other possible (complementary) action is to reduce the time 148 needed by the new mobile access gateway to get knowledge of the 149 active multicast subscription of the mobile node (i.e., the multicast 150 context), so the new mobile access gateway can subscribe to the 151 multicast group(s) on behalf of the mobile node as soon as possible. 153 While the first mechanism could potentially be accomplished by using 154 some adaptation of [RFC5949] to multicast traffic (despite being only 155 applicable in the case the underlying radio access technology 156 supports layer-2 triggers, thus requiring additional support on the 157 mobile node), there is no generic standard solution for the 158 accelerated acquisition of the on-going multicast subscription of the 159 mobile node. 161 The approach followed by the base solution [RFC6224] to get knowledge 162 of an existing multicast subscription relies on the behavior of the 163 IGMP/MLD protocols. Both protocols send multicast membership query 164 messages when a new link is up. The response to such a message 165 reports any existing multicast subscriptions by the mobile node. 166 While this is a straightforward approach, the mobile access gateway 167 can incur in a non-negligible delay in receiving the corresponding 168 MLD Report message. This delay is caused by the time needed for the 169 detection of the attachment in the new link and the re-establishment 170 of the data plane after the handover, the radio transfer delays 171 associated with the signaling to the mobile node, and the MLD query 172 response interval time required by this procedure (whose default 173 value is 10 seconds as defined in [RFC2710] and [RFC3810], or between 174 5 and 10 seconds as considered in the best case wireless link 175 scenario in [RFC6636]). 177 This document extends the Proxy Mobile IPv6 signaling protocol 178 defined in the base protocol [RFC5213] by including a new multicast 179 information option to update Proxy Mobile IPv6 entities during the 180 registration and de-registration processes, and new messages to 181 trigger the transfer of multicast information. No extension is 182 required in any of the multicast-related protocols in use (IGMP/MLD 183 or PIM protocols). Furthermore, this specification does not 184 substitute the standard procedures defined in [RFC6224] (e.g., the 185 mobile access gateway continues sending an MLD Query to the entering 186 mobile node as soon as the point-to-point link is set up), but 187 complements them for accelerating the acquisition of the multicast 188 content by the mobile access gateway associated to the new point-of- 189 attachment. 191 This document provides a signaling method internal to the network to 192 speed up the subscription information acquisition by the mobile 193 access gateway, in order to accelerate the multicast delivery to the 194 mobile node after having completed a handover. By doing so, the 195 knowledge by the mobile access gateway of the currently active 196 multicast subscription becomes independent of the underlying radio 197 technology dynamics and relaxes the requirement of a rapid response 198 from the mobile node in processing IGMP/MLD control messages. Issues 199 like radio framing, radio access contention, channel reliability, 200 MN's capabilities (i.e., layer-2 triggering support), IGMP/MLD timers 201 optimization for wireless environments, etc., will not impact on the 202 observed multicast performance during handovers. 204 The mechanisms described in this document can also be applied to the 205 solutions defined in [RFC7028]. Furthermore, it is also independent 206 of the role played by the mobile access gateway within the multicast 207 network (either acting as MLD proxy or multicast router). 209 1.1. Handover optimization requirements 211 A basic solution for providing support of multicast in a network- 212 based mobility management environment has been specified in [RFC6224] 213 without introducing changes on the original PMIPv6 specification 214 [RFC5213]. The focus of the present document is on improving the 215 efficiency of the base solution regarding handover performance. 217 One of the critical aspects of the base solution is the expected 218 delay incurred by the mobile access gateway (where the mobile node is 219 being attached to) to be informed about the on-going multicast 220 subscription of the entering MN, mainly due to the fact that the 221 mechanisms provided in the base solution relay on the original MLD 222 procedures, with long timing interactions not conceived for mobile 223 environments. Then, the requirements to be covered by a handover 224 optimization solution can be established in the following manner: 226 o The solution MUST be applicable to any kind of MN (that is, not 227 requiring any particular functionality such as for example layer-2 228 trigger capabilities), in such a way that any type of mobile node 229 in a PMIPv6 domain being served with multicast traffic can benefit 230 from the optimized solution. 232 o The solution MUST NOT impact existing multicast protocols. 234 o The solution MUST optimize the handover performance with respect 235 to the performance achieved with the base solution for any kind of 236 handover process (i.e., for proactive and reactive handovers). 238 o The solution SHOULD minimize the number and extent of additional 239 support (i.e., capabilities) required in the network, aiming at an 240 easier deployment. 242 o The solution MUST NOT impact deployments of legacy implementations 243 of [RFC5213] and [RFC6224]. 245 The present specification addresses all these requirements, as 246 described in the following sections. 248 2. Terminology 250 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 251 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 252 document are to be interpreted as described in RFC2119 [RFC2119]. 254 This document uses the terminology referring to PMIPv6 components as 255 defined in [RFC5213]. 257 Additionally, the following terms are defined and used in this 258 document. 260 pMAG: The previous MAG or pMAG is the mobile access gateway where 261 the MN was initially registered before a handover event. 263 nMAG: The new MAG or nMAG is the mobile access gateway where the MN 264 is registered at the end of the handover event. 266 Reactive Handover: A reactive handover is a handover event in which 267 the Local Mobility Anchor (LMA) receives the mobile node 268 registration from the nMAG without having previously received the 269 MN de-registration from the pMAG. 271 Proactive handover: A proactive handover is a handover event where 272 the mobile node is firstly de-registered on the local mobility 273 anchor by the pMAG, and later on it is registered by the nMAG as 274 consequence of changing the point of attachment. 276 Multicast Membership Context: In this document, multicast membership 277 context makes reference to the information relative to the 278 currently active multicast subscription of an MN in a handover 279 event which is transferred between the PMIPv6 entities to support 280 the handover optimization. 282 3. Overview 284 The local mobility anchor is a key element within the PMIPv6 285 infrastructure, which traces the mobile node reachability along the 286 PMIPv6 domain. Therefore the LMA is the best element to maintain the 287 MNs' multicast subscription information up-to-date and to forward it 288 to the rest of PMIPv6 entities (i.e., to the mobility access 289 gateways) as needed when MNs move within the domain. The LMA has 290 timely knowledge of the MNs' location, especially during handover 291 events, and it is therefore able to quickly provide information to 292 the new point of attachment (e.g., by querying the previous one). 293 Figure 1 summarizes the main idea of the optimization. 295 +------+ 296 | pMAG | | 297 +------+ | 298 / | 299 / | 300 / | 301 / | 302 -*-*-*-*- / (MN) 303 ( ) / | 304 ( ) +-----+ +------+ | 305 ( Internet )--| LMA |------| nMAG | v 306 ( ) +-----+ +------+ 307 ( ) 308 -*-*-*-*- Registration 309 <-------------- 311 Registration Ack 312 & Multicast Context 313 --------------> 315 Figure 1: High level description of the solution 317 The local mobility anchor only obtains the detailed subscription 318 information or multicast context during a handover event. There is 319 no need of continuously informing the LMA about MNs' multicast state 320 while the mobile nodes remain attached to the same mobile access 321 gateway. Such a continuous updating procedure would significantly 322 increase the signaling load within the PMIPv6 domain without a clear 323 benefit. The multicast context is only critical during handovers, 324 neither after nor before. Indicating the active subscription while 325 the handover is ongoing guarantees that such information will be up- 326 to-date and ready to be transferred to the new MAG where the mobile 327 node has just attached. This solution therefore defines the 328 Subscription Information Acquisition through the LMA (SIAL) as the 329 procedure to inform the new MAG about the multicast subscriptions 330 maintained by the entering MN. 332 To be able to transfer the multicast subscription information between 333 Proxy Mobile IPv6 entities during a handover, this document extends 334 the PMIPv6 protocol in several ways. First of all, a new mobility 335 option is defined to carry the multicast context of the current 336 subscription. Furthermore, additional messages are defined to manage 337 the interchange of the multicast information among PMIPv6 entities. 338 Finally, some flags are defined to govern the process. 340 4. Proxy Mobile IPv6 extensions 342 This section outlines the extensions proposed to the PMIPv6 protocol 343 specified in [RFC5213]. 345 4.1. Active Multicast Subscription mobility option 347 4.1.1. Option application rules 349 A new TLV-encoded mobility option, "Active Multicast Subscription" 350 option is defined for use with the Proxy Binding Update (PBU) and 351 Proxy Binding Acknowledge (PBA) messages exchanged between a local 352 mobility anchor and a mobility access gateway to transfer the 353 multicast subscription information. This option is used for 354 exchanging the multicast membership context. This information is 355 carried by directly using the format defined in the original MLD 356 specifications. There can be multiple "Active Multicast 357 Subscription" options present in the message, one for each active 358 subscription maintained by the mobile node when the handover is 359 taking place (i.e., one per multicast membership context). 361 This new option is also used for the same purposes by the new 362 Subscription Response message defined later in this document. 364 MLDv2 [RFC3810] is the primary objective for the definition of the 365 option format. MLDv1 [RFC2710] is also considered for backward 366 compatibility. 368 4.1.2. Option format 370 The format of this new option is as follows: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Type | Length | MLD Type | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 + Multicast Membership Context + 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 The alignment requirement of this option is 8n+1. 384 Type: 386 To be defined by IANA {IANA-1}, for indication of an IPv6 Active 387 Multicast Subscription option. 389 Length: 391 8-bit unsigned integer indicating the length of the option in 392 octets, excluding the type and length fields. 394 MLD type: 396 Field used to identify the IPv6 multicast membership protocol in 397 use, and the corresponding format of the next Multicast Membership 398 Context information field. This field maps the type codification 399 used in the original MLD specifications for the Report message. 400 For MLDv2, the MLD Type value is 143, as specified in [RFC3810]. 402 Multicast Membership Context: 404 Multicast subscription information corresponding to a single 405 subscribed multicast address. For MLDv2, the format of this field 406 follows the Multicast Address Record format as defined in 407 [RFC3810]. 409 4.1.3. Backward compatibility with MLDv1 411 The following values are adopted when MLDv1 is used. 413 MLD type: 415 For MLDv1, the MLD Type value is 131, as specified in [RFC2710]. 417 Multicast Membership Context: 419 For MLDv1, the relevant information for multicast context is 420 simply given, according to [RFC2710], by the multicast address of 421 the subscribed content. 423 In consequence, the Multicast Membership Context is defined as a 424 4-octet reserved field and the Multicast Address of the subscribed 425 content as in [RFC2710], as shown next. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | | 433 * * 434 | | 435 * Multicast Address * 436 | | 437 * * 438 | | 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 4.2. Multicast Signaling flag on PBU/PBA message headers 443 4.2.1. Flag application rules 445 A new flag S {IANA-2} is added in both the PBU and PBA message 446 headers to advertise the mobile access gateway and the local mobility 447 anchor capabilities of processing multicast- related signaling for 448 the MN that caused the message. 450 This flag governs the multicast-related signaling between the LMA and 451 the MAG. As a general rule, the value of the flag in the PBA message 452 is a copy of the value received in the PBU message. Specific rules 453 are described in next sub-sections. 455 4.2.1.1. Registration process 457 During handover, the entities involved in this process are the nMAG 458 and the LMA. These rules also apply for the initial binding 459 registration process. 461 o PBU message 463 * S=0, it indicates that the MAG sending the PBU message does not 464 accept multicast-related signaling for the MN being attached. 465 This can be used to discriminate PMIPv6 nodes which are not 466 multicast enabled, for backward compatibility reasons. 468 * S=1, it indicates that the MAG sending the PBU message accepts 469 multicast-related signaling for the MN being attached. 470 Depending on the type of handover (reactive or proactive) the 471 LMA takes some actions, described later in this document. 473 o PBA message 475 * If S=0 in the corresponding PBU message, the value of the flag 476 in the PBA message MUST be a copy of the value received in the 477 PBU message (thus S=0), without any further meaning. 479 * If S=1 in the corresponding PBU message, two sub-cases are 480 possible: 482 + S=1 and "Active Multicast Subscription" mobility option in 483 the PBA message. When the MN maintains an active multicast 484 session, if the LMA is able to provide the multicast 485 subscription information during registration, the PBA 486 message MUST include the "Active Multicast Subscription" 487 mobility option. If the LMA is not able to provide such 488 information during registration, the PBA message MUST NOT 489 include the "Active Multicast Subscription" mobility option. 490 This case is useful to decouple unicast and multicast 491 signaling for an MN being registered at nMAG. A way for 492 obtaining later active multicast-subscription information is 493 described later in this document. 495 + S=0 in the PBA message if the MN does not maintain an active 496 multicast subscription (note that for backward compatibility 497 reasons an LMA not supporting multicast related signaling 498 would always send S=0). 500 4.2.1.2. De-registration process 502 During handover, the entities involved in this process are the pMAG 503 and the LMA. These rules apply for the binding de-registration 504 process 506 o PBU message 508 * S=0, it indicates that the MN has no active multicast session 509 (note that for backward compatibility reasons a pMAG not 510 supporting multicast related signaling would always send S=0). 512 * S=1, it indicates that the MN has an active multicast session, 513 and the multicast context MUST be transported in the "Active 514 Multicast Subscription" mobility option. 516 o PBA message 518 * The value of the flag in the PBA message SHOULD be 0, without 519 any further meaning (note that for backward compatibility 520 reasons an LMA not supporting multicast related signaling would 521 always send S=0). 523 4.2.2. New format of conventional PBU/PBA messages 525 4.2.2.1. Proxy Binding Update message 527 As result of the new defined flag, the PBU message format is updated 528 as follows: 530 0 1 2 3 531 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 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Sequence # | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |A|H|L|K|M|R|P|S| Reserved | Lifetime | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 | | 538 . . 539 . Mobility options . 540 . . 541 | | 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 4.2.2.2. Proxy Binding Acknowledgement Message 546 As result of the new defined flag, the PBA message format is updated 547 as follows: 549 0 1 2 3 550 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 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Status |K|R|P|S| Rsrvd | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Sequence # | Lifetime | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | | 557 . . 558 . Mobility options . 559 . . 560 | | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 4.3. Messages for active multicast subscription query 565 A new pair of messages is defined for querying entities about the 566 active multicast subscription of the MN when the handover is of 567 reactive type. 569 These messages are sent using the Mobility Header as defined in 570 [RFC6275]. 572 4.3.1. Subscription Query message 574 4.3.1.1. Message application rules 576 The Subscription Query message {IANA-3} is sent by the LMA towards 577 the pMAG to query it about any existing multicast subscriptions of 578 the MN which is being registered by the nMAG. This message is 579 generated in case that the handover is of reactive type. 581 Additionally, this message is sent by the nMAG towards the LMA to 582 query it about the existing multicast subscriptions of the MN when 583 the LMA acknowledges the PBU sent by the nMAG but the multicast 584 context is not provided (namely, when the PBU message has set the 585 flag S to 1, and the PBA message has set the flag S to 1 but the 586 multicast context is missing). 588 4.3.1.2. Message format 590 The Subscription Query message has the following format. 592 0 1 2 3 593 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 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 595 | Sequence # | Reserved | 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | | 598 . . 599 . Mobility options . 600 . . 601 | | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 Sequence Number: 606 The Sequence Number field establishes the order of the messages 607 sent in the Subscription Query / Subscription Response dialogue 608 between the LMA and the MAG for a certain MN. The initial 609 Sequence Number MUST be determined by the entity which creates the 610 message (either LMA or MAG, depending on the scenario), which is 611 responsible for managing this counter. 613 This Sequence Number comparison MUST be performed modulo 2**8, 614 i.e., the number is a free running counter represented modulo 256. 615 A Sequence Number in a received Subscription Query message is 616 considered less than or equal to the last received number if its 617 value lies in the range of the last received number and the 618 preceding 128 values, inclusive. For example, if the last 619 received sequence number was 15, then messages with sequence 620 numbers 0 through 15, as well as 143 through 255, would be 621 considered less than or equal. 623 Reserved: 625 This field is unused for now. The value MUST be initialized to 0. 627 Mobility options: 629 This message carries one or more TLV-encoded mobility options. 630 The valid mobility options for this message are the following: 632 * Mobile Node Identifier option [RFC4283] (mandatory). 634 * Home Network Prefix option [RFC5213] (optional). 636 There can be one or more instances of the Home Network Prefix 637 option, but only one instance of the Mobile Node Identifier 638 option. 640 4.3.2. Subscription Response message 642 4.3.2.1. Message application rules 644 The Subscription Response message {IANA-4} is sent by the pMAG 645 towards the LMA, or by the LMA towards the nMAG, to answer a 646 previously received Subscription Query message, as described above. 648 4.3.2.2. Message format 650 The Subscription Response message has the following format. 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Sequence # |I| Reserved | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | | 658 . . 659 . Mobility options . 660 . . 661 | | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Sequence Number: 666 The value of the Sequence Number field in the Subscriber Response 667 message MUST be a copy of the Sequence Number received in the 668 Subscription Query message. 670 Multicast Information (I): 672 The multicast Information flag I specifies if there is multicast 673 subscription information available for the MN or not. The meaning 674 is the following: 676 I=0: there is no multicast subscription information available 677 for the MN identified by the Mobile Node Identifier option in 678 this message. 680 I=1: there is multicast subscription information available for 681 the MN identified by the Mobile Node Identifier option in this 682 message. The multicast subscription information MUST be 683 carried on one or more instances of the Active Multicast 684 Subscription option in this message (one instance for each 685 active subscription). 687 Reserved: 689 This field is unused for now. The value MUST be initialized to 0. 691 Mobility options: 693 This message carries one or more TLV-encoded mobility options. 694 The valid mobility options for this message are the following: 696 * Mobile Node Identifier option [RFC4283] (mandatory). 698 * Active Multicast Subscription option (mandatory) only when flag 699 I=1; it MUST NOT be present in any other case. 701 * Home Network Prefix option [RFC5213] (optional). 703 There can be one or more instances of the Home Network Prefix 704 option (in all cases) and the Active Multicast Subscription option 705 (only when I=1), but only one instance of the Mobile Node 706 Identifier option. 708 4.4. New PBA timer in the LMA 710 A new timer named "PBA timer" is used in the LMA to define the 711 maximum waiting time before the PBA message is sent to the nMAG in 712 case the multicast subscription information relative to the MN is not 713 yet available. The aim of this timer is to prevent potential large 714 delays in the forwarding of unicast traffic towards the MN being 715 registered at the nMAG. This timer allows decoupling the unicast 716 signaling from the multicast one in the SIAL solution. 718 This timer SHOULD be upper bounded by the constant defined in 719 [RFC6275] INIT_BINDACK_TIMEOUT, whose default value is 1 s. This 720 constant sets the time when the nMAG will retry the MN registration 721 by sending again the PBU message. The "PBA timer" has to be set to a 722 value that ensures that the nMAG does not enter the retry mode. 723 Experimental experience is needed on how to set up the PBA timer, and 724 therefore it is RECOMMENDED to set the "PBA timer" to zero, except 725 for experimental purposes. 727 5. Handover signaling procedures 729 As the MN moves from one access gateway to another, the mobility- 730 related signaling due to the handover event is carried out 731 independently by the pMAG and the nMAG. That signaling process is 732 not synchronized and, thus, two scenarios need to be considered 733 depending on the order in which the LMA receives notification of the 734 MN registration and de-registration in the nMAG and the pMAG 735 respectively. 737 5.1. Handover of proactive type 739 5.1.1. Rationale 741 In the proactive case, the MN is firstly de-registered by the pMAG, 742 and later on it is registered by the nMAG as consequence of changing 743 the point of attachment. 745 Only for those MNs which maintain an active multicast subscription, 746 the pMAG includes the "Active Multicast Subscription" mobility option 747 carrying the multicast context of the MN at that moment as part of 748 the PBU message (with flag S set to 1). 750 The local mobility anchor stores that information in the 751 corresponding binding cache. If later on the MN attaches to a nMAG, 752 this information is sent (using the same TLV option) to the nMAG as 753 part of the PBA confirmation of the registration process (if the PBU 754 message sent by the nMAG has the flag S set to 1). On the other 755 hand, if no further registration happens, the multicast information 756 is removed together with the rest of binding database for that MN. 758 After receiving the multicast context, the nMAG can subscribe to the 759 multicast flow(s) on behalf of the MN in case there is no other MN 760 already receiving it at the nMAG. The multicast status can be also 761 set in advance for the point-to-point link towards the MN. 763 Note that the SIAL solution described here does not prevent 764 benefiting from extended support in the mobile node/network that 765 facilitates the proactive mode operation of the solution, e.g., based 766 on layer-2 capabilities. 768 5.1.2. Message flow description 770 Figure 2 summarizes this process. 772 +-----+ +----+ +-----+ +----+ 773 | MN | |pMAG| | LMA | |nMAG| 774 +-----+ +----+ +-----+ +----+ 775 | | | | 776 | |==Bi-Dir Tunnel=| | 777 | Multicast Data | | | 778 |<---------------| | | 779 | | | | 780 1) MN Detached | | | 781 | MN Detached Event | | 782 | | | | 783 | |Ext'd DeReg PBU | | 784 2) | |--------------->| | 785 | | | | 786 3) | | Accept PBU | 787 | |(Multicast Subscription info stored) 788 | | | | 789 | | PBA | | 790 4) | |<---------------| | 791 | | | | 792 5) MN Attached | | | 793 | | | MN Attached Event 794 | | | | 795 | | | PBU | 796 6) | | |<---------------| 797 | | | | 798 | | | Ext'd PBA | 799 7) | | |--------------->| 800 | | | | 801 8) | | | Accept PBA, 802 | | | Multicast Group join 803 | | | and P-t-P status setup 804 | | | | 805 | | |==Bi-Dir Tunnel=| 806 | | | | 807 | | | Multicast Data | 808 |<-------------------------------------------------| 809 | | | | 810 | | | | 812 Figure 2: Proactive handover 814 The message flow is as follows: 816 1. A registered MN is receiving a multicast content which has been 817 previously subscribed to by sending a standard MLD report from 818 the mobile node to the currently serving mobile access gateway, 819 pMAG. The pMAG keeps the multicast state of the point-to-point 820 link with the MN. 822 2. The MN initiates a handover process (e.g., because of better 823 radio conditions) over a radio access controlled by a new MAG. 824 As a consequence, pMAG determines a detachment event 825 corresponding to this mobile node, and updates the attachment 826 status of this MN to the local mobility anchor by sending an 827 extended Proxy Binding Update message, including the "Active 828 Multicast Subscription", which contains the multicast context of 829 the active multicast subscriptions in the moment of handover. 831 3. The LMA processes the PBU message. Additionally, the LMA stores 832 in the Binding Cache the information regarding the on-going 833 multicast subscription(s) when the detachment is initiated. This 834 information is kept until a new registration of the MN is 835 completed by another MAG, or until the Binding Cache expiration, 836 according to [RFC5213]. 838 4. The local mobility anchor acknowledges to the pMAG the previous 839 PBU message. 841 5. As a result of the handover process, the mobile node attaches to 842 another mobility access gateway, called nMAG. 844 6. The nMAG triggers a registration process by sending a PBU message 845 (with flag S set to 1) to the local mobility anchor. 847 7. After the analysis of the PBU message, the LMA sends an extended 848 PBA including the "Active Multicast Subscription" option, which 849 contains the multicast context of the active subscriptions in the 850 moment of handover. 852 8. The nMAG processes the PBA message following all the standard 853 procedures described in [RFC5213]. Additionally, with the new 854 information relative to multicast subscription, the nMAG sets up 855 the multicast status of the point-to-point link between the nMAG 856 and the MN, and joins the content identified by (S,G) on behalf 857 of the MN in case the nMAG is not receiving already such content 858 due to a previous subscription ordered by another MN attached to 859 it. From that instant, the multicast content is served to the 860 MN. 862 5.2. Handover of reactive type 863 5.2.1. Rationale 865 In the reactive case, the LMA receives the mobile node registration 866 from the nMAG without having previously received the MN de- 867 registration from the pMAG. 869 As the nMAG is not aware of any active multicast subscription of the 870 mobile node, the nMAG starts a conventional registration process, by 871 sending a normal PBU message (with flag S set to 1) towards the local 872 mobility anchor. 874 In the reactive handover case, after MN registration at the nMAG, the 875 local mobility anchor SHOULD generically query the pMAG for 876 retrieving the multicast context of the on-going multicast 877 subscription of the mobile node. However, the LMA may know in 878 advance if the pMAG supports multicast signaling based on the value 879 of the flag S received during the MN registration in pMAG. 880 Specifically, in case the pMAG does not support multicast signaling 881 (e.g., the S flag value received from pMAG at the time of registering 882 the mobile node was 0), the LMA MAY decide not to query pMAG even in 883 the case of receiving an nMAG indication of supporting multicast 884 signaling. 886 Once the multicast subscription information is retrieved from the 887 pMAG, the LMA encapsulates it in the PBA message by using the TLV 888 option "Active Multicast Subscription", and forwards the PBA message 889 to the nMAG. Then, the nMAG can subscribe the multicast flow on 890 behalf of the MN, if there is no other mobile node receiving it 891 already at the nMAG. The multicast status can be also set in advance 892 for the point- to-point link towards the mobile node. 894 5.2.2. Message flow description 896 Figure 3 summarizes this process. 898 +-----+ +----+ +-----+ +----+ 899 | MN | |pMAG| | LMA | |nMAG| 900 +-----+ +----+ +-----+ +----+ 901 | | | | 902 | | | MN Attached Event 903 | | | | 904 | | | PBU | 905 1) | | |<---------------| 906 | | | | 907 | | Subscr Query | | 908 2) | |<---------------| | 909 | | | | 910 | | Subscr Resp | | 911 3) | |--------------->| | 912 | | | | 913 | | (Multicast Subscription | 914 | | info forwarding) | 915 | | | | 916 | | | Ext'd PBA | 917 4) | | |--------------->| 918 | | | | 919 5) | | | Accept PBA, 920 | | | Multicast Group join 921 | | | and P-t-P status setup 922 | | | | 923 | | |==Bi-Dir Tunnel=| 924 | | | | 925 | | | (S,G) Data | 926 |<-------------------------------------------------| 927 | | | | 928 | | | | 930 Figure 3: Reactive handover 932 We next take as starting point the situation where an MN is attached 933 to the pMAG, being multicast-enabled and maintaining an active 934 multicast subscription at this moment. 936 The sequence of messages for the handover of the mobile node is the 937 following (as depicted in Figure 3): 939 1. At certain time, the MN initiates a handover process (e.g., 940 because of better radio conditions) over a radio access 941 controlled by a new MAG. Then, the nMAG triggers a registration 942 process by sending a PBU message (with flag S set to 1) to the 943 local mobility anchor. As it is a reactive case, the pMAG is not 944 aware of the detachment process. 946 2. Prior to acknowledging the received PBU message, the LMA queries 947 the pMAG about if there is any active multicast subscription for 948 the MN, by sending a Subscription Query message. 950 3. The pMAG answers the LMA with a Subscription Response message 951 including the multicast context of the existing subscriptions. 953 4. After processing the pMAG answer, the LMA acknowledges (with flag 954 S set to 1) the PBU message, including the multicast subscription 955 information within the "Active Multicast Subscription" option. 956 The nMAG then processes the extended PBA message. 958 5. The nMAG processes the PBA message, and it proceeds to set up the 959 multicast status of the point-to-point link between the nMAG and 960 the mobile node, and to join the content identified by (S,G) on 961 behalf of the MN in case the nMAG is not receiving already such 962 content. The bidirectional tunnel is also set up between the 963 nMAG and the local mobility anchor if it has not been established 964 before by another MN connection. At this moment, the multicast 965 content can be served to the MN. The unicast traffic for the 966 mobile node can be forwarded as well. 968 5.2.3. Further considerations for the reactive handover signaling 970 A handover event is managed independently by the pMAG and nMAG. It 971 is not a synchronized process. In a reactive handover, the LMA 972 receives a registration PBU from nMAG before a de-registration PBU is 973 received from pMAG. 975 In the message flows detailed above, it could be the case that the 976 LMA receives a de-registration PBU from pMAG just after sending the 977 Subscription Query message, but before receiving the Subscription 978 Response message. That de-registration PBU message from pMAG carries 979 the multicast subscription information required to assist the MN in 980 the handover, so such valuable information SHOULD be kept by the LMA. 981 Furthermore, it is possible that once the Subscription Query message 982 arrives to pMAG, the pMAG could have already removed the multicast 983 related information for the MN. 985 In order to avoid losing the multicast subscription information sent 986 in the de-registration PBU message, the local mobility anchor SHOULD 987 store it, and SHOULD include it in the PBA message towards the nMAG 988 in case the Subscription Response message from the pMAG does not 989 contain multicast subscription information for the mobile node. 991 5.3. Prevention of large delays of the binding acknowledgement for 992 unicast traffic 994 According to the message sequences described for the reactive 995 handover case, in case the LMA has to request the multicast 996 subscription information from the pMAG, the binding request sent by 997 the nMAG is maintained on-hold until the local mobility anchor 998 receives, processes and includes the multicast subscription 999 information into the extended PBA message. As consequence, the 1000 unicast traffic may then suffer an extra delay motivated by the 1001 multicast-related signaling. During that time, the unicast traffic 1002 with destination the MN being registered by the nMAG MAY be buffered 1003 by the local mobility anchor. 1005 In order to avoid any potential large delay in the forwarding of 1006 unicast traffic arriving at the LMA towards the MN, a mechanism 1007 SHOULD be implemented to decouple multicast from unicast traffic 1008 reception by the MN. Figure 4 shows this mechanism. 1010 +-----+ +----+ +-----+ +----+ 1011 | MN | |pMAG| | LMA | |nMAG| 1012 +-----+ +----+ +-----+ +----+ 1013 1) | |==Bi-Dir Tunnel=| | 1014 | unicast data | | | 1015 |<-v-v-v-v-v-v-v-| | | 1016 | | | | 1017 | Multicast Data | | | 1018 |<---------------| | | 1019 | | | MN Attached Event 1020 | | | PBU | 1021 2) | | |<---------------| 1022 | | Subscr Query | | 1023 3) | |<---------------| | 1024 | | | | 1025 4) | | | 1026 | | /// | 1027 | | /// | 1028 5) | | | 1029 | | | | 1030 | | | Ext'd PBA | 1031 | | |--------------->| 1032 | | | | 1033 | | | Accept PBA 1034 | | | | 1035 | | |==Bi-Dir Tunnel=| 1036 | | | | 1037 | | | Unicast Data | 1038 |<-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-v-| 1039 | | | | 1040 | | | Subscr Query | 1041 6) | | |<---------------| 1042 | | Subscr Resp | | 1043 7) | |--------------->| | 1044 | | | | 1045 | | (Multicast Subscription | 1046 | | info forwarding) | 1047 | | | | 1048 | | | Subscr Resp | 1049 8) | | |--------------->| 1050 | | | | 1051 | | | Multicast Group join 1052 | | | and P-t-P status setup 1053 | | Multicast Data | | 1054 |<-------------------------------------------------| 1055 | | | | 1057 Figure 4: Decoupling of unicast and multicast signaling 1059 The sequence of messages is the following: 1061 1. An MN is attached to the pMAG. The MN is a multicast-enabled 1062 node, and it is receiving both unicast and multicast traffic 1063 simultaneously. 1065 2. Some time later, The MN initiates a handover process (e.g., 1066 because of better radio conditions) over a radio access 1067 controlled by a new mobile access gateway. Then, the nMAG 1068 triggers a registration process by sending a PBU message (with 1069 flag S set to 1) to the local mobility anchor. As it is a 1070 reactive case, the pMAG is not aware of the detachment process. 1072 3. Prior to acknowledging the received PBU message, the LMA decides 1073 to query the pMAG about if there is any active multicast 1074 subscription for the mobile node, by sending a Subscription Query 1075 message. 1077 4. Immediately after sending the Subscription Query message, the LMA 1078 starts the timer "PBA timer", which determines the maximum 1079 waiting time before the PBA is sent to avoid any potential large 1080 delay in the forwarding of unicast traffic towards the MN. 1082 5. In case the "PBA timer" expires, the LMA acknowledges the PBU 1083 message, by sending the PBA message with flag S=1, without the 1084 multicast context information. The nMAG then processes the 1085 extended PBA message. Such acknowledgement allows the mobile 1086 node to receive the unicast traffic from that time on. The 1087 bidirectional tunnel is also set up between the nMAG and the LMA 1088 if it has not been established before. 1090 6. In parallel, the nMAG sends a Subscription Query message to the 1091 LMA requesting the multicast-subscription details yet unknown for 1092 the mobile node. 1094 7. The pMAG answers the Subscription Query message originally sent 1095 by the local mobility anchor, including the multicast context. 1097 8. After processing the pMAG answer, the LMA sends a Subscription 1098 Response message to the nMAG, including the multicast 1099 subscription information within the "Active Multicast 1100 Subscription" option. The nMAG processes the PBA message, and it 1101 proceeds to set up the multicast status of the point-to-point 1102 link between the nMAG and the mobile node, and to join the 1103 content identified by (S,G) on behalf of the MN in case the nMAG 1104 is not receiving already such content. The bidirectional tunnel 1105 is also set up between the nMAG and the LMA if it has not been 1106 established before. At this moment, the multicast content can 1107 also be served to the mobile node. 1109 The "PBA timer" in the LMA determines if the signaling flow follows 1110 Figure 3 or Figure 4 in a reactive handover. A value of 0 for the 1111 "PBA timer" guarantees that the unicast traffic does not suffer any 1112 delay (according to the Figure 4 signaling flow), because the PBA is 1113 sent immediately after the LMA receives the PBU from the nMAG. A 1114 small non-zero "PBA timer" value MAY be used to reduce the signaling 1115 load in the LMA and MAGs (as shown in the signaling flow of Figure 3 1116 if the Subscription Response message from the pMAG is received at the 1117 LMA before the "PBA timer" expires), but this has to be carefully 1118 balanced against added delay to the unicast traffic. 1120 6. IPv4 support 1122 IPv4-based mobile nodes (being either IPv4/IPv6 dual-stack, or 1123 IPv4-only enabled) can be supported in a PMIPv6 domain according to 1124 [RFC5844]. When referring to multicast membership protocols and 1125 procedures, this means that IGMP functionality has to be also 1126 supported between the PMIPv6 entities, as documented in [RFC6224], to 1127 allow the mobile access gateway requesting multicast contents to the 1128 mobility anchor on behalf of the mobile nodes attached to it. 1130 6.1. Active Multicast Subscription for IPv4 1132 The Active Multicast Subscription option defined in Section 4.1, 1133 which transports the multicast membership context of the mobile node 1134 during handover, should be compatible with IGMP-based formats. 1135 Specifically, the option format is defined for IPv4-based MNs as 1136 follows: 1138 0 1 2 3 1139 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 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | Type | Length | IGMP Type | 1142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1143 | | 1144 + Multicast Membership Context + 1145 | | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1148 IGMPv3 is the primary objective for the definition of the option 1149 format. IGMPv1 and IGMPv2 are also considered for backward 1150 compatibility. The alignment requirement of this option is 4n+1. 1152 Type: 1154 To be defined by IANA {IANA-5}, for indication of an IPv4 Active 1155 Multicast Subscription option. 1157 Length: 1159 8-bit unsigned integer indicating the length of the option in 1160 octets, excluding the type and length fields. 1162 IGMP type: 1164 Field used to identify the IPv4 multicast membership protocol in 1165 use, and the corresponding format of the next Multicast Membership 1166 Context information field. This field maps the type codification 1167 used in the original IGMP specifications for the Report message. 1169 0x12: Use of IGMPv1 multicast membership protocol. 1171 0x16: Use of IGMPv2 multicast membership protocol. 1173 0x22: Use of IGMPv3 multicast membership protocol. 1175 Multicast Membership Context: 1177 Multicast subscription information corresponding to a single 1178 subscribed multicast address. Depending on the IGMP version being 1179 used by the mobile node, the format of the Multicast Context could 1180 follow the following formats: 1182 * For IGMPv1, the Group Address format as defined in [RFC1112]. 1184 * For IGMPv2, the Group Address format as defined in [RFC2236]. 1186 * For IGMPv3, the Group Record format as defined in [RFC3376]. 1188 6.2. Signaling procedures for IPv4 support 1190 Generic signaling procedures for the support of IPv4 in PMIPv6 1191 domains have been already specified in [RFC5844]. In order to 1192 prevent errors while signaling the on-going multicast subscription 1193 for a mobile node during the handover process, the following 1194 extensions have to be considered in SIAL. 1196 o If the registration / de-registration process in a handover is for 1197 an IPv6-only MN, and the type of the received Active Multicast 1198 Subscription option indicates IPv4, then the multicast membership 1199 context received MUST be silently discarded. 1201 o If the registration / de-registration process in a handover is for 1202 an IPv4-only MN, and the type of the received Active Multicast 1203 Subscription option indicates IPv6, then the multicast membership 1204 context received MUST be silently discarded. 1206 o If the registration / de-registration process in a handover is for 1207 a dual stack MN, the received Active Multicast Subscription option 1208 (or options) MUST be accepted independently of the type 1209 indication. 1211 6.3. Binding Cache extensions for IPv4 support 1213 Additionally, since the multicast membership information is 1214 temporally stored in the mobility anchor under some circumstances 1215 (e.g., proactive handover), the Binding Cache entry for an IPv4-based 1216 multicast-enabled MN should be extended for storing the IGMP-based 1217 context formats mentioned above, including the IGMP version 1218 indicator. 1220 7. Co-existence with PMIPv6 multicast architectural evolutions 1222 Throughout this document, the base solution for multicast support in 1223 Proxy Mobile IPv6, described in [RFC6224], has been implicitly 1224 considered, i.e., both unicast and multicast traffic addressing a 1225 mobile node is delivered via the standard PMIPv6 bi-directional 1226 tunnel between LMA and MAG. While here all multicast traffic is 1227 assumed to be delivered via the local mobility anchor, the SIAL 1228 approach described in this document can be also applied to other 1229 solutions in which the multicast content is served from other 1230 entities in the PMIPv6 domain, as described in [RFC7028] to solve the 1231 tunnel convergence problem. 1233 In this case, the transfer of the multicast context would also pass 1234 through the local mobility anchor, as described here. However, the 1235 nMAG subscribes to the multicast content through the node in charge 1236 of distributing multicast according to the adopted solution for 1237 multicast distribution in the PMIPv6 domain. 1239 8. Security Considerations 1241 This proposal does not pose any additional security threats to those 1242 already identified in [RFC5213]. All the security considerations in 1243 [RFC5213] are directly applicable to this protocol. The signaling 1244 messages, Proxy Binding Update, and Proxy Binding Acknowledgement 1245 (extended with the new options defined in this document), the 1246 Subscription Query Message, and the Subscription Response Message 1247 exchanged between the mobile access gateway and the local mobility 1248 anchor, MUST be protected using end-to-end security association(s) 1249 offering integrity and data origin authentication. 1251 The mobile access gateway and the local mobility anchor MUST 1252 implement the IPsec security mechanism mandated by Proxy Mobile IPv6 1253 [RFC5213] to secure the signaling described in this document. In the 1254 following, we describe the Security Policy Database (SPD) and 1255 Security Association Database (SAD) entries necessary to protect the 1256 new signaling introduced by this specification (Subscription Query 1257 Message and Subscription Response Message). We use the same format 1258 used by [RFC4877]. The SPD and SAD entries are only example 1259 configurations. A particular mobile access gateway implementation 1260 and a local mobility anchor home agent implementation could configure 1261 different SPD and SAD entries as long as they provide the required 1262 security of the signaling messages. 1264 For the examples described in this document, a mobile access gateway 1265 with address "mag_address_1", and a local mobility anchor with 1266 address "lma_address_1" are assumed. 1268 mobile access gateway SPD-S: 1269 - IF local_address = mag_address_1 & 1270 remote_address = lma_address_1 & 1271 proto = MH & (remote_mh_type = Subscription Query | 1272 local_mh_type = Subscription Response | 1273 remote_mh_type = Multicast Activity Indication Ack.| 1274 local_mh_type = Multicast Activity Indication) 1275 Then use SA1 (OUT) and SA2 (IN) 1277 mobile access gateway SAD: 1278 - SA1(OUT, spi_a, lma_address_1, ESP, TRANSPORT): 1279 local_address = mag_address_1 & 1280 remote_address = lma_address_1 & 1281 proto = MH 1282 - SA2(IN, spi_b, mag_address_1, ESP, TRANSPORT): 1283 local_address = lma_address_1 & 1284 remote_address = mag_address_1 & 1285 proto = MH 1287 local mobility anchor SPD-S: 1288 - IF local_address = lma_address_1 & 1289 remote_address =mag_address_1 & 1290 proto = MH & (remote_mh_type = Subscription Response | 1291 local_mh_type = Subscription Query | 1292 remote_mh_type = Multicast Activity Indication | 1293 local_mh_type = Multicast Activity Indication Ack.) 1294 Then use SA2 (OUT) and SA1 (IN) 1295 local mobility anchor SAD: 1296 - SA2(OUT, spi_b, mag_address_1, ESP, TRANSPORT): 1297 local_address = lma_address_1 & 1298 remote_address = mag_address_1 & 1299 proto = MH 1300 - SA1(IN, spi_a, lma_address_1, ESP, TRANSPORT): 1301 local_address = mag_address_1 & 1302 remote_address = lma_address_1 & 1303 proto = MH 1305 While in the base solution the LMA has the knowledge of the 1306 subscribed multicast groups per MAG, in this specification the LMA is 1307 aware (during a handover process) of the multicast groups to which an 1308 MN visiting the PMIP domain is subscribed to. 1310 9. IANA Considerations 1312 This document establishes new assignments to the IANA mobility 1313 parameters registry. 1315 o Mobility Header types: the Subscription Query {IANA-3} and 1316 Subscription Response {IANA-4} mobility header types. The Type 1317 value for these Headers has been assigned from the "Mobility 1318 Header Types - for the MH Type field in the Mobility Header" 1319 registry defined in http://www.iana.org/assignments/mobility- 1320 parameters. 1322 o Mobility options: the Active Multicast Subscription mobility 1323 option for both IPv4 {IANA-5} and IPv6 {IANA-1} modes of 1324 operation. The Type value for these Mobility options has been 1325 assigned from the "Mobility Options" registry defined in http:// 1326 www.iana.org/assignments/mobility-parameters. 1328 o Flags: this document reserves a new multicast Signaling flag (S) 1329 {IANA-2}. This Flag has been reserved at the "Binding Update 1330 Flags" and "Binding Acknowledgment Flags" registries defined in 1331 http://www.iana.org/assignments/mobility-parameters. 1333 10. Contributors 1335 Dirk Von Hugo (Telekom Innovation Laboratories, Dirk.von- 1336 Hugo@telekom.de) extensively contributed to this document. 1338 11. Acknowledgments 1340 The authors would like to thank (in alphabetical order) Hitoshi 1341 Asaeda, Sergio Figueiredo, Georgios Karagiannis, Marco Liebsch, 1342 Behcet Sarikaya, Thomas C. Schmidt and Stig Venaas for their 1343 valuable comments and discussions on the Multimob mailing list. The 1344 authors are also grateful with Hitoshi Asaeda, Akbar Rahman, Behcet 1345 Sarikaya and Stig Venaas for their reviews of this document. 1347 The research of Carlos J. Bernardos leading to these results has 1348 received funding from the European Community's Seventh Framework 1349 Programme (FP7-ICT-2009-5) under grant agreement n. 258053 (MEDIEVAL 1350 project), being also partially supported by the Ministry of Science 1351 and Innovation (MICINN) of Spain under the QUARTET project (TIN2009- 1352 13992-C02-01). 1354 The research of Ignacio Soto has also received funding from the 1355 Spanish MICINN through the I-MOVING project (TEC2010-18907). 1357 12. References 1359 12.1. Normative References 1361 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1362 RFC 1112, August 1989. 1364 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1365 Requirement Levels", BCP 14, RFC 2119, March 1997. 1367 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 1368 2", RFC 2236, November 1997. 1370 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 1371 Listener Discovery (MLD) for IPv6", RFC 2710, October 1372 1999. 1374 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1375 Thyagarajan, "Internet Group Management Protocol, Version 1376 3", RFC 3376, October 2002. 1378 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1379 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1381 [RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1382 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 1383 (MIPv6)", RFC 4283, November 2005. 1385 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1386 IKEv2 and the Revised IPsec Architecture", RFC 4877, April 1387 2007. 1389 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1390 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1392 [RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy 1393 Mobile IPv6", RFC 5844, May 2010. 1395 [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support 1396 in IPv6", RFC 6275, July 2011. 1398 12.2. Informative References 1400 [Papagiannaki] 1401 Papagiannaki, K., Moon, S., Fraliegh, C., Thiran, P., and 1402 C. Diot, "Measurement and Analysis of Single-Hop Delay on 1403 an IP Backbone Network", IEEE Journal on Selected Areas in 1404 Communications, vol.21, no.6 , August 2003. 1406 [RFC5949] Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F. 1407 Xia, "Fast Handovers for Proxy Mobile IPv6", RFC 5949, 1408 September 2010. 1410 [RFC6224] Schmidt, T., Waehlisch, M., and S. Krishnan, "Base 1411 Deployment for Multicast Listener Support in Proxy Mobile 1412 IPv6 (PMIPv6) Domains", RFC 6224, April 2011. 1414 [RFC6636] Asaeda, H., Liu, H., and Q. Wu, "Tuning the Behavior of 1415 the Internet Group Management Protocol (IGMP) and 1416 Multicast Listener Discovery (MLD) for Routers in Mobile 1417 and Wireless Networks", RFC 6636, May 2012. 1419 [RFC7028] Zuniga, JC., Contreras, LM., Bernardos, CJ., Jeon, S., and 1420 Y. Kim, "Multicast Mobility Routing Optimizations for 1421 Proxy Mobile IPv6", RFC 7028, September 2013. 1423 [Verizon] "LTE: The Future of Mobile Broadband Technology", Verizon 1424 White Paper (http://opennetwork.verizonwireless.com/pdfs/ 1425 VZW_LTE_White_Paper_12-10.pdf) , 2010. 1427 [Y.1541] "Network performance objectives for IP-based services", 1428 ITU-T Recommendation Y.1541 , December 2011. 1430 Appendix A. Performance comparison with base solution 1432 This informative annex briefly analyzes and compares the performance 1433 improvement provided by the fast handover extensions specified in 1434 this document with the base multicast solution defined in [RFC6224]. 1435 The main aim is to determine the potential delay reduction in the 1436 acquisition of the multicast subscription information by the nMAG 1437 during the MN handover. To do that, the analysis focuses on the 1438 delay additional to the unicast handover due to the multicast 1439 operation in both cases. 1441 Different delay components have to be taken into account for this 1442 comparison. Since the interaction between the actors during the 1443 handover process (MN, pMAG, nMAG, LMA) is different for each of the 1444 solutions, then different sources of delay can be expected for each 1445 of them. 1447 A.1. Delay characterization of the base solution 1449 The base solution relies on the standard MLD procedures to obtain the 1450 multicast subscription information directly from the MN. Once the 1451 nMAG completes the configuration of point-to-point link to the 1452 attaching MN (the configuration of this link as downstream interface 1453 of an MLD proxy instance can run in parallel), it immediately sends 1454 an MLD General Query towards the MN for getting knowledge of any 1455 active multicast subscription by the MN. When the MN receives the 1456 MLD Query, the MN provides information about the active memberships 1457 it maintains in the form of an MLD Report message. After successful 1458 transmission of this information via the wireless point of attachment 1459 to nMAG the corresponding MLD proxy instance at the nMAG sets up the 1460 multicast status of the downstream interface. According to this 1461 process, the delay is originated on the MAG-MN communication. 1463 The delay components to be considered for the base solution are the 1464 following: 1466 o D_bh, which is the unidirectional (one way) delay encountered in 1467 the transmission path between the nMAG and the wireless point of 1468 attachment. 1470 o D_radio, which is the unidirectional delay due to the transfer of 1471 MLD control messages over the radio channel (user plane) between 1472 the wireless point of attachment and the MN, for the MLD Query and 1473 Report messages. 1475 o D_mld, which is the delay incurred by the MN to answer the MLD 1476 Query. 1478 The total observed delay can be then formulated as: 1480 D_base = 2 x (D_bh + D_radio) + D_mld 1482 A.2. Delay characterization of SIAL 1484 As described in this document, it is possible to distinguish two 1485 scenarios depending on the order in which the LMA receives the 1486 notifications of the MN registration and de-registration in the nMAG 1487 and the pMAG respectively. 1489 In the proactive case, the MN is firstly de-registered by the pMAG, 1490 and later on it is registered by the nMAG. As specified in this 1491 document, the LMA stores the multicast subscription information, 1492 which is be provided to the nMAG during the MN registration process. 1493 Since the registration process necessarily happens before the MLD 1494 Query and Report process described in the base solution, the 1495 proactive case is inherently faster than the base solution. In fact, 1496 since the multicast subscription information is acquired properly 1497 during the registration process, the delay incurred is null. 1499 In the reactive case, the LMA receives the MN registration from the 1500 nMAG without having previously received the MN de-registration from 1501 the pMAG. In case the MN maintains an active subscription, the LMA 1502 queries the pMAG to retrieve the multicast subscription information, 1503 which is forwarded to the nMAG. According to this process, the delay 1504 is originated on the MAG-LMA communication. 1506 The delay components to be considered for the base solution are the 1507 following: 1509 o D_net, which is the unidirectional delay found in the network path 1510 between the LMA and the MAG. 1512 The total observed delay can be then formulated as: 1514 D_sial = 2 x D_net 1516 A.3. Performance comparison 1518 The performance of the base solution is highly dependent on the radio 1519 technology used by the MN to attach to the PMIPv6-Domain. Different 1520 radio technologies have distinct properties in terms of radio 1521 framing, radio access contention or collision avoidance, channel 1522 reliability, etc. 1524 New radio access technologies, such as the one specified in new Long 1525 Term Evolution (LTE) standards intend to reduce the latency in order 1526 to provide high speed communications. Even though, typical one-way 1527 latencies in the LTE radio access will stay around 15 ms [Verizon]. 1529 The backhaul delay characterization becomes problematic. In a real 1530 network there are several solutions for the backhaul connection in 1531 terms of network topology (ring, star, point-to-point, etc) and 1532 technology (optical fiber, microwave transmission, xDSL-based 1533 accesses, etc), all of them having distinct properties in terms of 1534 performance, reliability and delay. These solutions commonly coexist 1535 in a real mobile network, in such a way that an MN changing the point 1536 of attachment can pass smoothly from one solution to another. A 1537 value of D_bh=5 ms can be established as typical value for the 1538 backhaul latency in modern networks. 1540 Finally, the MLD induced delay is intrinsic to the MLD protocol 1541 specification. A host receiving an MLD Query message waits a random 1542 time in the range (0, Maximum Response Delay) to send the MLD Report 1543 message. The default value of the Maximum Response Delay 1544 (configurable through the Query Response Interval in MLD) is 10 s in 1545 [RFC2710], or 5 s in the best case described in [RFC6636]. Then, in 1546 average, it can be expected a potential delay of 5 or 2,5 s, 1547 respectively. 1549 As we have seen, D_base is, on average, greater than 2,5 sec with the 1550 best case of the values of Query Response Interval in MLD that are 1551 recommended in [RFC6636]. That means that the handover delay of the 1552 base solution is on the order of seconds while in the solution 1553 presented in this specification it is on the order of milliseconds 1554 (as it is shown below). To improve the performance of the base 1555 solution we could further reduce the value of Query Response Interval 1556 but the implications of doing so would need to be carefully analyzed. 1557 Even if we assume that Query Response Interval is 0 sec, D_base would 1558 be of around 2 x (5 ms + 15 ms) = 40 ms for last generation systems. 1559 Note that this calculation does not take into account the necessary 1560 time to re-establish the data plane after the handover to make 1561 possible the MLD Query reception. The expected delay will get much 1562 worse for older generation systems (e.g., 3G-based radio systems can 1563 suffer radio delays in the order of hundreds of ms). 1565 For the SIAL case, the delay in the MAG-LMA communication will be 1566 derived from the network diameter (i.e., the number of hops found 1567 between the MAG and the LMA in the PMIPv6-Domain). This is largely 1568 influenced by the internal network planning. An administrative 1569 domain can typically have in the order of 5 hops from access to the 1570 interconnection gateway providing connectivity to other networks. 1571 Even if the LMA plays a central role topologically in the PMIPv6 1572 domain, such number of hops seems reasonable in a common nation-wide 1573 network. Each hop in the path between MAG and LMA will add a certain 1574 delay, which can be estimated to be around 1 ms in the best case 1575 [Papagiannaki] and 3 ms in the worst case [Y.1541]. With this in 1576 mind, a total delay D_sial of around 2 x 5 x 3 ms = 30 ms can be 1577 expected in the worst case. 1579 Then, as conclusion, in a typical deployment, it can be stated that 1580 SIAL proposal, even for the worst-case consideration, will perform 1581 better than the best case situation for the base solution, which 1582 consists of the last generation radio technology, LTE. For any other 1583 radio technology the base solution will show even larger deviations 1584 from the delay achievable with the SIAL solution. 1586 Authors' Addresses 1588 Luis M. Contreras 1589 Telefonica I+D 1590 Ronda de la Comunicacion, s/n 1591 Sur-3 building, 3rd floor 1592 Madrid 28050 1593 Spain 1595 Email: lmcm@tid.es 1597 Carlos J. Bernardos 1598 Universidad Carlos III de Madrid 1599 Av. Universidad, 30 1600 Leganes, Madrid 28911 1601 Spain 1603 Phone: +34 91624 6236 1604 Email: cjbc@it.uc3m.es 1605 URI: http://www.it.uc3m.es/cjbc/ 1607 Ignacio Soto 1608 Universidad Carlos III de Madrid 1609 Av. Universidad, 30 1610 Leganes, Madrid 28911 1611 Spain 1613 Email: isoto@it.uc3m.es