idnits 2.17.1 draft-schmidt-waehlisch-mhmipv6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 788 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2005) is 6736 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '4' on line 564 looks like a reference -- Missing reference section? '6' on line 599 looks like a reference -- Missing reference section? '2' on line 110 looks like a reference -- Missing reference section? '3' on line 130 looks like a reference -- Missing reference section? '5' on line 131 looks like a reference -- Missing reference section? '7' on line 140 looks like a reference -- Missing reference section? '11' on line 151 looks like a reference -- Missing reference section? '9' on line 418 looks like a reference -- Missing reference section? '10' on line 418 looks like a reference -- Missing reference section? '8' on line 173 looks like a reference -- Missing reference section? '14' on line 338 looks like a reference Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Thomas C. Schmidt 3 HAW Hamburg 4 Matthias Waehlisch 5 Expires: May 2006 FHTW Berlin 6 November 2005 8 Seamless Multicast Handover in a 9 Hierarchical Mobile IPv6 Environment (M-HMIPv6) 10 12 IPR Statement 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79[1]. 19 Status of this Memo 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document extends the Hierarchical Mobile IPv6 Internet Draft to 39 include the reception and transmission of Any Source Multicast 40 traffic at the Mobile Node. It introduces handover mechanisms for 41 IPv6 mobile multicast listeners and mobile multicast senders. 42 Operations are based on a Mobile IPv6 environment with local mobility 43 anchor points. These local anchor points are conformal with a 44 Hierarchical Mobile IPv6 proxy infrastructure. Handover latencies in 45 the proposed scheme remain bound to link switching delays with 46 respect to these local proxy points. Thus the M-HMIPv6 achieves 47 seamless mobility, even though no bicasting of multicast streams is 48 used. Multicast listeners in addition encounter the option to 49 optimize multicast routing by turning to a direct data reception. 50 The mechanisms described in this document do not rely on assumptions 51 of any specific multicast routing protocol in use. The M-HMIPv6 52 protocol operations utilize the existing HMIPv6, MIPv6 and MLDv2 53 messages under minor extensions. 55 Table of Contents 57 1. Terminology....................................................3 59 2. Introduction...................................................3 61 3. Overview of M-HMIPv6...........................................4 62 3.1 Operations of a multicast listener.........................5 63 3.2 Operations of a multicast sender...........................5 65 4. Multicast specific extensions of MIPv6, HMIPv6 and MLDv2.......6 66 4.1 M-HMIPv6 flag in MAP option message........................6 67 4.2 Use of Home Address Destination Option in mobile multicast.7 68 4.3 Binding Cache processing at Correspondent Node.............7 69 4.4 Home Agent Multicast Membership control....................7 70 4.5 Router attendance control in MLD...........................8 72 5. Protocol Details...............................................9 73 5.1 Operations of all Mobile Nodes............................10 74 5.2 Mobile multicast listener.................................10 75 5.2.1 Operations of the Mobile Node........................10 76 5.2.2 Operations of the MAP................................11 77 5.2.3 Buffering............................................12 78 5.3 Mobile multicast source...................................12 79 5.3.1 Operations of the Mobile Node........................12 80 5.3.2 Operations of the MAP................................13 81 5.3.3 Tree initialization procedure........................13 82 5.3.4 Buffering............................................14 83 5.4 Protocol Timer............................................14 85 6. Security Considerations.......................................14 87 7. IANA Considerations...........................................14 89 8. References....................................................15 91 Acknowledgments..................................................16 93 Author's Addresses...............................................16 94 A. A Note on Tunneling...........................................16 96 Copyright Notice.................................................17 98 Disclaimer of Validity...........................................17 100 Acknowledgement..................................................17 102 1. Terminology 104 The terminology used in this document remains conformal to the 105 definitions in MIPv6 [4] and HMIPv6 [6]. 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC-2119 [2]. 111 2. Introduction 113 Multicast-based packet distribution plays an important role in real- 114 time applications, as it provides the only efficient, scalable scheme 115 for group communication. However, any source multicasting itself 116 conceals complex mechanisms for group membership management and 117 routing, which both are of slow convergence. To achieve seamless 118 mobility here is one of the most challenging and demanded 119 developments in IP networks today. 121 In multimedia conference scenarios each member commonly operates as 122 receiver and as sender for multicast based group communication. 123 In addition, real-time communication such as voice or video over IP 124 places severe temporal requirement on mobility protocols: Seamless 125 handover scenarios need to limit disruptions or delay to less than 126 100 ms. Jitter disturbances are not to exceed 50 ms. Note that 100 ms 127 is about the duration of a spoken syllable in real-time audio 128 traffic. 130 The fundamental approach to deal with mobility in IPv6 [3] is stated 131 in the Mobile IPv6 RFCs [4,5]. MIPv6 operates address changes on the 132 IP layer transparent to the transport layer as a device moves from 133 one network to the other. MIPv6 involves roundtrip messages for 134 location updates directly with the MNs Home Agent and the 135 Correspondent Node. As these nodes can be far away, MIPv6 may exhibit 136 slow handover performance. The Hierarchical Mobility Management 137 (HMIPv6) Internet Draft [6] introduces a proxy architecture of 138 Mobility Anchor Points (MAPs) to reduce communication delays with 139 respect to the HA. In addition the Fast Handover for Mobile IPv6 140 Internet Draft [7] proposes predictive delay hiding techniques to 141 further reduce handover times in unicast data. 143 MIPv6 only roughly treats multicast mobility, in a pure remote 144 subscription approach or through bi-directional tunneling via the 145 Home Agent. It thereby suffers from slow handovers and inefficient, 146 triangular forwarding. It is the issue of this document to extend the 147 improved HMIPv6 mobility infrastructure by mechanisms of sending and 148 receiving multicast traffic for the MN. Local MAPs serve as temporary 149 multicast relays to hide partly movement, partly handoff latency of 150 the MN. The multicast support through a MAP infrastructure may 151 significantly reduce the attained handover frequencies [11]. Handover 152 procedures between MAPs solely built on MIPv6 and HMIPv6 signaling 153 are described within this draft. They are designed to limit any 154 disruption or disturbance to the time scale needed for reconnecting 155 to neighboring MAPs. An additional option in multicast data delivery 156 allows for turning to optimal routing, after a receiver handover has 157 been completed. Minor MLD [9,10] extensions are required to operate 158 this optimization option. All mechanisms remain transparent to any 159 specific multicast routing protocol in use. 161 3. Overview of M-HMIPv6 163 This multicast mobility scheme is built on a HMIPv6 environment. 164 HMIPv6 introduces Mobility Anchor Points as proxy elements, which may 165 be best viewed as functions on regional routers. For implementing 166 multicast mobility it is advantageous, but not necessary, that these 167 regional routers provide multicast routing functionality. 169 In M-HMIPv6 a mobile multicast node uses its local MAP as anchor 170 point for multicast communication. All multicast traffic is directed 171 through this MAP using the Regional Care-of Address RCoA as multicast 172 subscriber or source address. Traffic forwarding between MN and its 173 MAP is done using a bi-directional tunnel [8]. 175 If a MN changes location within its MAP domain, it only registers its 176 new LCoA with the MAP as defined in [6]. This does not affect 177 multicast routing trees. When entering a new MAP domain a MN will be 178 eager to sustain multicast connectivity via its previously 179 established MAP. Eventually it will learn of M-HMIPv6 support through 180 router advertisements with MAP option messages, and will then perform 181 a reactive handover. Multicast handover procedures will occur only if 182 the MN changes into a new M-HMIPv6 enabled MAP domain and will then 183 transfer multicast traffic from the previous to the current MAP. 185 An M-HMIPv6-aware MN SHOULD use the MAP for multicast communication. 186 However, the MN MAY prefer to use its HA as a multicast anchor point, 187 e.g. in visited networks within its home site. A mobile node, which 188 is not M-HMIPv6 aware, will not use its MAP as a multicast anchor 189 point, but will use the MIPv6 tunnel through the HA instead. In this 190 sense M-HMIPv6 is simply a smooth extension of HMIPv6, which itself 191 smoothly extends MIPv6. 193 3.1 Operations of a multicast listener 195 To join a multicast group away from home the MN tunnels the MLD 196 [9,10] listener report to its current MAP using RCoA as source 197 address. The MAP records the group address in its Binding Cache in 198 order to forward multicast packets to the MN and to subscribe for and 199 preserve MNs multicast group membership. 201 When changing its MAP domain, the MN submits a Binding Update with 202 its new LCoA to the previous MAP in addition to regular HMIPv6 203 handover signaling. On its reception the previous MAP redirects 204 multicast packet forwarding to the MN's new LCoA. 206 If multicast support is advertised in the new domain the MN 207 immediately SHOULD join the multicast group through the new MAP. Once 208 multicast group traffic arrives the MN SHOULD send a Binding Update 209 with zero lifetime to its previous MAP to eliminate its Binding Cache 210 entry and end packet forwarding. 212 3.2 Operations of a multicast sender 214 In a foreign MAP domain a MN initiates multicast-based communication 215 by sending packets through its MAP using RCoA as its source address. 216 As receivers are aware of source addresses and as the mobile RCoA 217 address may change, a Home Address Destination Option MUST be 218 included (s. section 4.2). By transmitting multicast packets along 219 this path a routing tree originating at the MAP will be constructed. 220 Local movement of the MN within a MAP domain thereby remains 221 transparent to multicast routing. 223 Sending MCast Traffic to receivers 224 MAP-Domain1 /------------------------------------> 225 +-------+ 226 /-----| MAP1 |-----\ 227 |/----+-------+----\| 228 || || 229 || || 230 +-----+ || 231 | AR1 | || 232 +-----+ || 233 || || 234 || || 235 |\-----+-----+ || || 236 \------| MN | || || 237 +-----+ || || 238 || || Movement 239 || || 240 MAP-Domain2 || || 241 +-----+-----/| \/ 242 /------| MN |------/ 243 |/-----+-----+ 244 || 245 || 246 +-----+ 247 | AR2 | 248 +-----+ 249 || 250 || 251 |\----+-------+ 252 \-----| MAP2 | 253 +-------+ Sending MCast Traffic to receivers 254 \------------------------------------> 256 Figure 1: Intra-MAP-domain Handover for mobile multicast senders 258 Upon arrival in a new MAP domain the MN submits a Binding Update with 259 its new LCoA to the previously established multicast-forwarding MAP 260 and continues its multicast delivery via this previous MAP (s. figure 261 1). If multicast support is advertised in the new domain the MN 262 immediately initiates a new multicast routing tree with the new RCoA 263 as source address anchored at its current MAP. The routing tree 264 SHOULD be initiated via the tree initialization procedure described 265 in section 5.3.3. Alternatively, bi-casting of data streams MAY be 266 used. 268 The handover procedure completes after a predefined timeout is 269 reached: The mobile multicast source continues to deliver data only 270 via its new MAP and stops forwarding through its previous MAP. 272 4. Multicast specific extensions of MIPv6, HMIPv6 and MLDv2 274 4.1 M-HMIPv6 flag in MAP option message 276 M-HMIPv6 support is advertised within the MAP option message as used 277 for router advertisements according to HMIPv6 [6]. For this purpose 278 an appropriate flag is added in the following way 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 | Type | Length | Dist | Pref |*|M| Reserved | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Valid Lifetime | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | | 288 + + 289 | | 290 + Global IP Address for MAP + 291 | | 292 + + 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Flags: 298 * Used by HMIPv6 299 M When set indicates that M-HMIPv6 is supported by 300 the current MAP 302 4.2 Use of Home Address Destination Option in mobile multicast 304 Multicast applications normally are aware of source addresses, which 305 MUST NOT change during ongoing communication. A mobile multicast 306 sender therefore MUST include a home address destination option as 307 defined in [4]. This requirement deviates from MIPv6 multicast 308 scheme. 310 4.3 Binding Cache processing at Correspondent Node 312 A Correspondent Node receiving multicast packets with Home Address 313 Option in general need not have a Binding Cache Entry for the home 314 address included. A CN therefore SHALL NOT verify multicast packets 315 with respect to its Binding Cache. This requirement deviates from 316 MIPv6 unicast scheme. 318 4.4 Home Agent Multicast Membership control 320 To provide multicast connectivity to a mobile multicast listener away 321 from home, a HA needs to take care of the local multicast group 322 management. This essentially can be done by either supplying full 323 multicast routing functionalities at the HA, or by a proxy agent 324 function. 326 In the first case it suffices for the HA to observe MNs group 327 membership at the (tunnel) interface. For a multicast proxy function 328 a HA must answer MLD queries according to group membership states of 329 the MN. This is an extension of the specifications in [4]. 331 4.5 Router attendance control in MLD 333 To enable route optimization at a mobile multicast listener away from 334 home, a specific multicast router (e.g. MAP) MAY terminate its packet 335 forwarding to the MN. However, to preserve its ability to restart 336 fast packet forwarding, it may be desirable for this router to remain 337 part of the multicast delivery tree. To support such router 338 attendance control (see [14] for preliminary ideas), a minor code 339 extension of the Multicast Listener Discovery Protocol [9,10] is 340 proposed. 342 A multicast router (e.g. it encounters low link resources in a 343 multilinked environment) MAY submit an MLD Listener Query for one or 344 several multicast groups with an attendance code field in place. 345 Activating the attendance code field will initiate multicast 346 receivers to actively search for an alternate multicast subscription. 347 The attendance code field in MLD Listener Query attains the following 348 form: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type = 130 | Code | Checksum | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Maximum Response Code | Reserved | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | | 358 . . 359 . . 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Type Multicast Listener Query (Type = decimal 130) 365 Code 366 0: Query on actively forwarded multicast groups 367 1: Query on multicast groups intended for attendance 369 The corresponding attendance code field in MLDv2 Listener Report 370 attains the following form: 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 = 143 | Code | Checksum | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Reserved |Nr of Mcast Address Records (M)| 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | | 380 . . 381 . ... . 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Type Version 2 Multicast Listener Report Message 386 (Type = decimal 143) 388 Code 389 0: Report on multicast address records, 390 requested for active forwarding 391 1: Report on multicast address records, 392 requested for attendance 394 On reception of an attendance coded router query a multicast listener 395 SHOULD attempt to receive multicast data through an alternate 396 interface. After initiation of the attendance coded report the 397 multicast router MUST continue to deliver multicast data. It also 398 MUST continue to submit (possibly attendance coded) Listener Queries 399 according to the rules in [9,10]. If in return of a query (with or 400 without attendance code) a router does only receive Listener Reports 401 containing an attendance code, the router SHOULD stop to forward the 402 specific group traffic onto the corresponding link, but sustain 403 membership in the appropriate multicast delivery tree. After a 404 multicast router has turned into attendance mode, it MUST continue to 405 query onto the 'attended' groups. These queries MUST carry the 406 attendance code field. 408 If a multicast listener has succeeded to receive multicast traffic 409 for one or several groups via a new interface (as reaction on 410 attendance coded router query or on its own initiative), it MAY wish 411 to preserve fast forwarding capabilities on the previous link. To do 412 so a listener MAY submit an MLDv2 Listener Report for the groups in 413 common, containing an attendance code. After such termination of 414 multicast forwarding, any receiver MAY re-initiate multicast 415 forwarding for any desired multicast group under 'attendance' on such 416 link by submitting an MLDv2 Listener Report without the attendance 417 code. Attendance coded router queries MUST be answered according to 418 the rules in [9,10], either with or without attendance code. 420 5. Protocol Details 422 This section describes M-HMIPv6 operations as are to be performed for 423 multicast traffic in addition to the MIPv6 and HMIPv6 protocols. Two 424 perspectives need a general distinction: Multicast processing of a 425 mobile listener and a mobile sender. 427 Mobility Anchor Points as defined in [6] attain the role of multicast 428 mobility anchor points (M-MAPs) for mobile group members in M-HMIPv6. 429 All multicast traffic is directed through M-MAPs using RCoA 430 consistently as identifier with respect to the multicast routing 431 tree. M-MAPs may be viewed as HA proxies for multicast streams, just 432 as MAPs in the unicast case. 434 5.1 Operations of all Mobile Nodes 436 Being at home the MN may either use its Home Agent or, a possibly 437 distinct, regional M-MAP as multicast anchor point. Away from home 438 the MN will learn about regional M-MAPs through router advertisements 439 (s. section 4.1). A MN SHOULD register with the regional M-MAP having 440 the highest preference value. If M-HMIPv6 is not supported regionally 441 the MN first SHOULD attempt to employ a previously established M-MAP 442 relation, second register with its HA. 444 M-MAP presence is advertised via router advertisements with MAP 445 option message as described in section 4.1. 447 5.2 Mobile multicast listener 449 Any node on a multicast enabled network may remotely subscribe to 450 multicast group membership by using its link-local address in MLD 451 membership reports. In doing so a MN cannot expect to experience a 452 smooth handover performance while changing from one network to 453 another. 455 A MN utilizing an HMIPv6 MAP infrastructure can be regarded as eager 456 for decreased handover delays and therefore SHOULD use the M-HMIPv6 457 M-MAP functionality for other than link locally scoped multicast 458 reception. 460 5.2.1 Operations of the Mobile Node 462 A mobile multicast listener registers with its local M-MAP (or HA), 463 where both communicate via a bi-directional tunnel. The MN submits 464 its MLD group membership listener report through this tunnel and 465 answers membership queries of the anchor point. 467 When a Mobile Node changes its network, it performs a Binding Update 468 with its previous M-MAP and re-establishes the tunnel at its new 469 LCoA. Thereafter it continues to receive multicast group traffic. 471 On entering a new M-MAP domain a MN - in addition to the above BU - 472 registers with the new M-MAP and establishes a bi-directional tunnel. 473 It immediately sends a MLD listener report through the newly 474 available connection, one for each group/flow to be handed over. Once 475 multicast group traffic arrives from the new M-MAP, the MN SHOULD 476 submit a BU with zero lifetime to its previous M-MAP and terminate 477 the corresponding tunnel. If previous binding of the MN had been with 478 the HA, the MN MUST NOT terminate its binding, but SHOULD tunnel an 479 MLD listener done message instead. 481 Note that a MN SHOULD preserve a previously established M-MAP 482 relation until a new multicast forwarding is completely established. 483 In the case of rapid movement this may lead to a previous multicast 484 anchor point persisting through several hops. 486 As an optional extension to optimize routing a MN MAY be enabled to 487 directly subscribe to multicast groups in its visited subnet. This 488 remote subscription SHOULD be performed, if triggered by M-MAP MLD 489 listener queries marked with attendance code as described in section 490 4.5. It MAY be performed on MN's own reasons, the recognition of slow 491 handover frequencies or significant M-MAP distance, for instance. 493 To optimize routing for a specific multicast group the MN undertakes 494 a regular MLD subscription at its link local interface using its 495 LCoA. After receiving multicast data on this link local interface, 496 the MN MUST tunnel an MLD listener report to its M-MAP with 497 attendance code as described in section 4.5. On further MLD listener 498 queries of its M-MAP the MN MUST reply with listener reports. These 499 reports SHOULD carry the attendance code as long as the MN receives 500 multicast streams locally. 502 5.2.2 Operations of the MAP 504 M-MAP operations for multicast listener support are completely analog 505 to Home Agent functions as described in [4] and section 4.4. An M-MAP 506 receiving a HMIPv6 BU from a MN will establish a bi-directional 507 tunnel. On reception of a tunneled MLD listener report it will 509 o record multicast group membership in its Binding Cache; 510 o observe and maintain multicast group membership on its specific 511 tunnel interface; 512 o inquire on MNs current group membership as described in [4]; 513 o forward multicast group traffic to the MN (see [4] on 514 multicast packet forwarding rules). 516 The M-MAP may control multicast group membership either as a 517 multicast router or as a multicast proxy agent (s. section 4.4). 519 As an optional extension to optimize routing the M-MAP MAY be enabled 520 to direct MNs do directly subscribe to multicast groups within their 521 visited subnets by using the MLD attendance extensions described in 522 section 4.5. The M-MAP MAY decide to initiate remote subscriptions of 523 MNs by tunneling MLD queries with attendance code. This decision 524 could be based on the number of attached MNs subscribed to the same 525 multicast groups or link capacities or forwarding load, for instance. 526 If the M-MAP itself acts as a multicast router, it will operate 527 exactly as described in section 4.5 for each tunnel interface 528 associated with a MN. Otherwise the M-MAP will intercept MLD queries 529 from multicast routers to add attendance codes. Similar it will 530 intercept listener reports from its attached MNs to remove attendance 531 codes. 533 Regardless of its own queries the M-MAP must continue to deliver 534 multicast streams to any attached MN, which reports on group 535 membership without attendance code. 537 5.2.3 Buffering 539 Some L2 technologies imply a noticeable offline period for a MN 540 during handover. To compensate for possible packet loss, buffering 541 mechanisms are needed. In M-HMIPv6 M-MAPs may provide automatic 542 replay buffers at the tunnel entry points, to be played out after a 543 MN's Binding Update occurred. 545 5.3 Mobile multicast source 547 A multicast source sending with its link-local address is immobile 548 with respect to multicast application persistence. A mobile multicast 549 sender MAY tunnel multicast traffic through its HA, using its home 550 address as source address [4]. Triangular routing and significant 551 binding update times lead to expected large handover delays, in 552 general. 554 A MN utilizing a HMIPv6 MAP infrastructure therefore SHOULD use the 555 M-HMIPv6 M-MAP functionality for other than link locally scoped 556 multicast transmissions. 558 5.3.1 Operations of the Mobile Node 560 A mobile multicast sender is registered with its local M-MAP, where 561 both communicate via a bi-directional tunnel. The MN submits 562 multicast packets through this tunnel with the RCoA as the source 563 address and the home address included in a home address destination 564 option as defined in [4]. 566 When a Mobile Node changes networks, it performs a Binding Update 567 with its previous M-MAP and re-establishes the tunnel at its new 568 LCoA. Thereafter it continues to send its multicast group traffic, 569 using previous RCoA as its source address. 571 On entering a new M-MAP domain a MN - in addition to the above BU - 572 registers with the new M-MAP and establishes a bi-directional tunnel. 574 It immediately SHOULD start the tree initialization procedure as 575 defined in section 5.3.3 and start a timer. As soon as this timer 576 exceeds MAX_MCASTTREEINIT_TIMEOUT the MN MUST complete the handover 577 by terminating multicast group forwarding through its previous M-MAP 578 and submit all subsequent traffic to its current M-MAP using its 579 current RCoA as source address. Note that these handover steps can be 580 performed stream wise. 582 A MN, which moves to a new link within the same M-MAP domain before 583 the timeout is reached, performs a BU with its current M-MAP and 584 continues the handover procedure without resetting its timers. 586 A MN, which moves into a new M-MAP domain before the timeout 587 occurred, continues to forward multicast traffic through its 588 previously established old M-MAP, discontinues to communicate via its 589 previously not fully established intermediate M-MAP, resets its timer 590 and restarts the tree initialization procedure for its current M-MAP. 592 Thus in case of rapid movement the MN stays bound with its formerly 593 fully established (or first) M-MAP, serving the last completely 594 erected multicast routing tree. 596 5.3.2 Operations of the MAP 598 M-MAP operations for multicast sender support are completely analog 599 to MAP functions for unicast support as described in [6]. 601 5.3.3 Tree initialization procedure 603 In preparation for a seamless handover of a multicast sender, a 604 distribution tree needs to be constructed by the routers, which 605 originates at the new M-MAP. In general, Any Source Multicast routing 606 trees will be initiated by submitting packets into the appropriate 607 multicast group. Depending on the routing protocol in use, this can 608 be a tardy procedure. A multicast sender MAY initiate a new group 609 tree by bi-casting its packets to its previous and its new point of 610 attachment. Bi-casting in the presence of slow routing protocols, 611 though, may result in a significant amount of duplicate traffic. In 612 many cases it may be highly desirable to proceed with less 613 communication overhead. The tree initialization procedure provides a 614 way for the MN to efficiently bridge the multicast routing 615 convergence gap. 617 In performing the tree initialization procedure, the source starts to 618 send probe packets, destined to all multicast groups under migration, 619 with complete IPv6 header, but without transport payload. In detail, 620 the next header field of tree initialization packets contains IPv6- 621 NoNxt (59) value. Subsequent packets SHOULD be sent with a random 622 delay uniformly chosen between 0 and MCASTTREEINIT_FREQUENCY. 624 The tree initialization procedure ends after 625 MAX_MCASTTREEINIT_TIMEOUT is reached with continuous submission of 626 regular traffic to the initiated delivery tree. 628 5.3.4 Buffering 630 To prevent or reduce packet loss during handover, the mobile source 631 MAY buffer packets to be sent, while its tunnel to the M-MAP is not 632 established. This buffer should be played out as soon as the tunnel 633 re-establishment to the previous MAP has completed. 635 5.4 Protocol Timer 637 MAX_MCASTTREEINIT_TIMEOUT 180 seconds (Default) 638 160 seconds (For DVMRP regimes) 639 0.5 seconds (For PIM-SM regimes) 641 MCASTTREEINIT_FREQUENCY 10 seconds (Default) 643 Mobile nodes must allow these variables to be configured by system 644 management. 646 6. Security Considerations 648 This specification uses the concepts of Mobile IPv6 and Hierarchical 649 Mobile IPv6 mobility management. All security provisions regarding 650 the relation between the Mobile Node and the Home Agents and between 651 the Mobile Node and the Mobility Anchor Points apply equally to this 652 M-HMIPv6 concept. 653 Threats of hijacking unicast sessions derive from attempts of a MN to 654 operate binding updates within multicast sessions. Any binding update 655 received within a multicast session therefore MUST be ignored. 657 7. IANA Considerations 659 This document defines extension codes for two ICMPv6 messages. For 660 the 662 Type Multicast Listener Query (Type = decimal 130) 664 and the 666 Type Version 2 Multicast Listener Report Message 667 (Type = decimal 143) 669 this requires the registration of two codes. The suggested values for 670 these codes are: 672 Code 673 0: Query on actively forwarded multicast groups 674 1: Query on multicast groups intended for attendance. 676 8. References 678 Normative References 680 1 Bradner, S., "Intellectual Property Rights in IETF Technology", 681 BCP 79, RFC 3979, March 2005. 683 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 684 Levels", BCP 14, RFC 2119, March 1997. 686 3 Hinden, R. and Deering, S. "Internet Protocol Version 6 687 Specification", RFC 2460, December 1998. 689 4 Johnson, D.B., Perkins, C., Arkko, J. "Mobility Support in IPv6", 690 RFC 3775, June 2004. 692 5 Arkko, J., Devarapalli, V., Dupont, F "Using IPsec to Protect 693 Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 694 3776, June 2004. 696 6 Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L. 697 "Hierarchical Mobile IPv6 mobility management", RFC 4140, August 698 2005. 700 7 Koodli, R. "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. 702 8 Conta, A., Deering, S. "Generic Packet Tunneling in IPv6 703 Specification", RFC 2473, December 1998. 705 9 S. Deering, W. Fenner and B. Haberman "Multicast Listener 706 Discovery (MLD) for IPv6", RFC 2710, October 1999. 708 10 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version 709 2 (MLDv2) for IPv6", RFC3810, June 2004. 711 Informative References 713 11 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - 714 Analysis of Handover Performance and Its Implications on IPv6 and 715 Multicast Mobility", Telecommunication Systems, Vol. 30, No. 1, 716 pp. 123-142, Berlin Heidelberg:Springer, 2005. 718 12 Romdhani, I., Kellil, M., Lach, H.-Y. et. al. "IP Mobile 719 Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6, 1, 720 2004. 722 13 Suh, K., Kwon, D.-H., Suh, Y.-J. and Park, Y. "Fast Multicast 723 Protocol for Mobile IPv6 in the fast handovers environments", 724 IETF, Internet Draft - (work in progress), February 2004. 726 14 Jelger, C., Noel, T. "Multicast for Mobile Hosts in IP Networks: 727 Progress and Challenges", IEEE Wireless Comm., pp 58-64, Oct. 728 2002. 730 15 Schmidt, T.C. and Waehlisch, M. "Multicast Mobility in MIPv6: 731 Problem Statement", draft-schmidt-mobopts-mmcastv6-ps-00.txt - 732 (work in progress), October 2005. 734 Acknowledgments 736 The authors would like to thank Stefan Zech (FHTW Berlin), Mark 737 Palkow (DaViKo GmbH) and Hans L. Cycon (FHTW Berlin) for valuable 738 discussions and a joyful collaboration. 740 Author's Addresses 742 Thomas C. Schmidt 743 HAW Hamburg, Dept. Informatik 744 Berliner Tor 7 745 D-20099 Hamburg 746 Phone: +49-40-42875-8157 747 Email: Schmidt@informatik.haw-hamburg.de 749 Matthias Waehlisch 750 FHTW Berlin, HRZ 751 Treskowallee 8 752 D-10318 Berlin 753 Email: mw@fhtw-berlin.de 755 A. A Note on Tunneling 757 Following the concepts of MIPv6 and HMIPv6 the packet forwarding to 758 and from the Mobile Node is organized by means of a tunnel section 759 spanned to a static anchor component such as a MAP or a Home Agent. 761 Through this technique a MN can hide its movement to CNs or to the 762 routing infrastructure. 764 However, keeping in mind real-time data requirements it is highly 765 desirable to avoid packet encapsulation. Besides the unwanted 766 overhead, a tunnel may hide QoS information of the original packet 767 headers and may require load and jitter generating packet 768 fragmentation, if the tunnel entry point is distinguished from the 769 sender. 771 Tunnelling can be avoided by a direct packet forwarding of the static 772 anchor components. Such forwarding requires a change of packet's 773 source or destination address at the forwarder, which usually 774 conflicts with checksums covering IPv6 pseudo headers. In M-MIPv6 775 multicast communication from a Mobile Node though carries a MIPv6 776 extension header, the home address destination option header. This 777 header denotes an alternate source address which enters the pseudo 778 header instead of the original IPv6 header address. 780 Multicast packets sent from the MN therefore could be forwarded by 781 the MAP to the network by replacing source addresses without 782 recalculation of header checksums. Employing such direct packet 783 forwarding would allow a MN to distribute multicast streams without a 784 tunnel. 786 Copyright Notice 788 Copyright (C) The Internet Society (2005). This document is subject 789 to the rights, licenses and restrictions contained in BCP 78, and 790 except as set forth therein, the authors retain all their rights. 792 Disclaimer of Validity 794 "This document and the information contained herein are provided on 795 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 796 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 797 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 798 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 799 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 800 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 802 Acknowledgement 804 Funding of the RFC Editor function is currently provided by the 805 Internet Society