idnits 2.17.1 draft-irtf-mobopts-mmcastv6-ps-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document 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 (April 13, 2009) is 5485 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 125 looks like a reference -- Missing reference section? '2' on line 244 looks like a reference -- Missing reference section? '3' on line 129 looks like a reference -- Missing reference section? '4' on line 136 looks like a reference -- Missing reference section? '5' on line 922 looks like a reference -- Missing reference section? '6' on line 266 looks like a reference -- Missing reference section? '65' on line 974 looks like a reference -- Missing reference section? '7' on line 167 looks like a reference -- Missing reference section? '8' on line 199 looks like a reference -- Missing reference section? '9' on line 245 looks like a reference -- Missing reference section? '10' on line 245 looks like a reference -- Missing reference section? '11' on line 247 looks like a reference -- Missing reference section? '12' on line 248 looks like a reference -- Missing reference section? '13' on line 248 looks like a reference -- Missing reference section? '14' on line 248 looks like a reference -- Missing reference section? '15' on line 249 looks like a reference -- Missing reference section? '16' on line 250 looks like a reference -- Missing reference section? '17' on line 1022 looks like a reference -- Missing reference section? '18' on line 266 looks like a reference -- Missing reference section? '19' on line 943 looks like a reference -- Missing reference section? '20' on line 944 looks like a reference -- Missing reference section? '21' on line 267 looks like a reference -- Missing reference section? '22' on line 268 looks like a reference -- Missing reference section? '23' on line 268 looks like a reference -- Missing reference section? '62' on line 956 looks like a reference -- Missing reference section? '24' on line 490 looks like a reference -- Missing reference section? '25' on line 945 looks like a reference -- Missing reference section? '26' on line 613 looks like a reference -- Missing reference section? '27' on line 549 looks like a reference -- Missing reference section? '28' on line 552 looks like a reference -- Missing reference section? '29' on line 556 looks like a reference -- Missing reference section? '30' on line 1009 looks like a reference -- Missing reference section? '31' on line 817 looks like a reference -- Missing reference section? '32' on line 571 looks like a reference -- Missing reference section? '33' on line 581 looks like a reference -- Missing reference section? '34' on line 592 looks like a reference -- Missing reference section? '35' on line 590 looks like a reference -- Missing reference section? '36' on line 595 looks like a reference -- Missing reference section? '37' on line 598 looks like a reference -- Missing reference section? '69' on line 1025 looks like a reference -- Missing reference section? '38' on line 656 looks like a reference -- Missing reference section? '39' on line 722 looks like a reference -- Missing reference section? '40' on line 724 looks like a reference -- Missing reference section? '41' on line 725 looks like a reference -- Missing reference section? '42' on line 734 looks like a reference -- Missing reference section? '43' on line 736 looks like a reference -- Missing reference section? '44' on line 772 looks like a reference -- Missing reference section? '45' on line 778 looks like a reference -- Missing reference section? '46' on line 779 looks like a reference -- Missing reference section? '47' on line 800 looks like a reference -- Missing reference section? '48' on line 812 looks like a reference -- Missing reference section? '49' on line 854 looks like a reference -- Missing reference section? '50' on line 853 looks like a reference -- Missing reference section? '51' on line 831 looks like a reference -- Missing reference section? '52' on line 846 looks like a reference -- Missing reference section? '53' on line 848 looks like a reference -- Missing reference section? '54' on line 872 looks like a reference -- Missing reference section? '55' on line 875 looks like a reference -- Missing reference section? '56' on line 927 looks like a reference -- Missing reference section? '57' on line 943 looks like a reference -- Missing reference section? '58' on line 943 looks like a reference -- Missing reference section? '59' on line 1080 looks like a reference -- Missing reference section? '60' on line 945 looks like a reference -- Missing reference section? '61' on line 945 looks like a reference -- Missing reference section? '63' on line 966 looks like a reference -- Missing reference section? '64' on line 973 looks like a reference -- Missing reference section? '66' on line 982 looks like a reference -- Missing reference section? '67' on line 1013 looks like a reference -- Missing reference section? '68' on line 1017 looks like a reference -- Missing reference section? '70' on line 1052 looks like a reference -- Missing reference section? '71' on line 1099 looks like a reference -- Missing reference section? '72' on line 1083 looks like a reference -- Missing reference section? '73' on line 1091 looks like a reference -- Missing reference section? '74' on line 1108 looks like a reference -- Missing reference section? '75' on line 1115 looks like a reference -- Missing reference section? '76' on line 1118 looks like a reference -- Missing reference section? '77' on line 1126 looks like a reference -- Missing reference section? '78' on line 1127 looks like a reference -- Missing reference section? '79' on line 1132 looks like a reference -- Missing reference section? '80' on line 1136 looks like a reference -- Missing reference section? '81' on line 1237 looks like a reference -- Missing reference section? '82' on line 1166 looks like a reference -- Missing reference section? '83' on line 1167 looks like a reference -- Missing reference section? '84' on line 1229 looks like a reference -- Missing reference section? '85' on line 1236 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 87 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MobOpts Research Group Thomas C. Schmidt 3 Internet Draft HAW Hamburg 4 Intended Status: Informational Matthias Waehlisch 5 Expires: October 14, 2009 link-lab 6 Godred Fairhurst 7 University of Aberdeen 8 April 13, 2009 10 Multicast Mobility in MIPv6: Problem Statement and Brief Survey 11 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on October 14, 2009. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 This document discusses current mobility extensions to IP layer 49 multicast. It describes problems arising from mobile group 50 communication in general, the case of multicast listener mobility, 51 and for mobile senders using Any Source Multicast and Source Specific 52 Multicast. Characteristic aspects of multicast routing and deployment 53 issues for fixed IPv6 networks are summarized. Specific properties 54 and interplays with the underlying network access are surveyed with 55 respect to the relevant technologies in the wireless domain. It 56 outlines the principal approaches to multicast mobility, together 57 with a comprehensive exploration of the mobile multicast problem and 58 solution space. This document concludes with a conceptual roadmap for 59 initial steps in standardization for use by future mobile multicast 60 protocol designers. This document is a product of the IP Mobility 61 Optimizations (MobOpts) Research Group. 63 Table of Contents 65 1. Introduction and Motivation....................................3 66 1.1 Document Scope..............................................4 68 2. Problem Description............................................6 69 2.1 General Issues..............................................6 70 2.2 Multicast Listener Mobility.................................8 71 2.2.1 Node & Application Perspective........................8 72 2.2.2 Network Perspective...................................9 73 2.3 Multicast Source Mobility..................................10 74 2.3.1 Any Source Multicast Mobility........................10 75 2.3.2 Source Specific Multicast Mobility...................11 76 2.4 Deployment Issues..........................................12 78 3. Characteristics of Multicast Routing Trees under Mobility.....13 80 4. Link Layer Aspects............................................13 81 4.1 General Background.........................................13 82 4.2 Multicast for Specific Technologies........................14 83 4.2.1 802.11 WLAN..........................................14 84 4.2.2 802.16 WIMAX.........................................15 85 4.2.3 3GPP/3GPP2...........................................16 86 4.2.4 DVB-H / DVB-IPDC.....................................17 87 4.2.5 TV Broadcast and Satellite Networks..................18 88 4.3 Vertical Multicast Handovers...............................18 90 5. Solutions.....................................................19 91 5.1 General Approaches.........................................19 92 5.2 Solutions for Multicast Listener Mobility..................20 93 5.2.1 Agent Assistance.....................................20 94 5.2.2 Multicast Encapsulation..............................21 95 5.2.3 Hybrid Architectures.................................21 96 5.2.4 MLD Extensions.......................................22 97 5.3 Solutions for Multicast Source Mobility....................22 98 5.3.1 Any Source Multicast Mobility Approaches.............22 99 5.3.2 Source Specific Multicast Mobility Approaches........23 101 6. Security Considerations.......................................24 103 7. Summary and Future Steps......................................25 105 8. IANA Considerations...........................................26 107 Appendix A. Implicit Source Notification Options.................26 109 9. References....................................................26 111 Acknowledgments..................................................33 113 Author's Addresses...............................................34 115 1. Introduction and Motivation 117 Group communication forms an integral building block of a wide 118 variety of applications, ranging from content broadcasting and 119 streaming, voice and video conferencing, collaborative environments 120 and massive multiplayer gaming, up to the self-organization of 121 distributed systems, services or autonomous networks. Network layer 122 multicast support will be needed whenever globally distributed, 123 scalable, serverless or instantaneous communication is required. 125 The early idea of Internet multicasting [1] soon lead to a wide 126 adoption of Deering's host group model [2]. Broadband media delivery 127 is emerging as a typical mass scenario that demands scalability and 128 bandwidth efficiency from multicast routing. Although multicast 129 mobility has been a concern for about ten years [3] and has led to 130 numerous proposals, there is as yet no generally accepted solution. 131 Multicast network support will be of particular importance to mobile 132 environments, where users commonly share frequency bands of limited 133 capacity. Reception of 'infotainment' streams may soon require wide 134 deployment of mobile multicast services. 136 Mobility in IPv6 [4] is standardized in the Mobile IPv6 RFCs [5,6], 137 and addresses the scenario of network layer changes while moving 138 between wireless domains. MIPv6 [5] only roughly defines multicast 139 mobility for Mobile Nodes (MN), using a remote subscription approach 140 or through bi-directional tunneling via the Home Agent (HA). Remote 141 subscription suffers from slow handovers, relying on multicast 142 routing to adapt to handovers. Bi-directional tunneling introduces 143 inefficient overhead and delay due to triangular forwarding, i.e., 144 instead of traveling on shortest paths, packets are routed through 145 the Home Agent. Therefore these approaches have not been optimized 146 for a large scale deployment. A mobile multicast service for a future 147 Internet should provide 'close to optimal' routing at predictable and 148 limited cost, offering robustness combined with a service quality 149 compliant to real-time media distribution. 151 Intricate multicast routing procedures are not easily extensible to 152 satisfy the requirements for mobility. A client subscribed to a group 153 while performing mobility handovers, requires the multicast traffic 154 to follow to its new location; a mobile source needs the entire 155 delivery tree to comply with or to adapt to its changing position. 156 Significant effort has already been invested in protocol designs for 157 mobile multicast receivers; only limited work has been dedicated to 158 multicast source mobility, which poses the more delicate problem 159 [65]. 161 In multimedia conference scenarios, games or collaborative 162 environments each member commonly operates as a receiver and as a 163 sender for multicast group communication. In addition, real-time 164 communication such as conversational voice or video places severe 165 temporal requirements on mobility protocols: Typical seamless 166 handover scenarios are expected to limit disruptions or delay to less 167 than 100 - 150 ms [7]. Jitter disturbances should not exceed 50 ms. 168 Note that 100 ms is about the duration of a spoken syllable in real- 169 time audio. This problem statement is intended to also be applicable 170 to a range of other scenarios with a range of delivery requirements 171 appropriate to the general Internet. 173 This document represents the consensus of the MobOpts Research Group. 174 It has been reviewed by the Research Group members active in the 175 specific area of work. In addition, this document has been 176 comprehensively reviewed by multiple active contributors to the IETF 177 MEXT, MBONED, and PIM Working Groups. 179 1.1 Document Scope 181 This document defines the problem scope for multicast mobility 182 management, which may be elaborated in future work. It is subdivided 183 to present the various challenges according to their originating 184 aspects, and identifies existing proposals and major bibliographic 185 references. 187 When considering multicast node mobility, the network layer is 188 complemented by some wireless access technology. Two basic scenarios 189 are of interest: Single-hop mobility (shown in figure 1.a) and multi- 190 hop mobile routing (figure 1.b). Single-hop mobility is the focus of 191 this document, which coincides with the perspective of MIPv6 [5]. The 192 key issues of mobile multicast membership control, and the interplay 193 of mobile and multicast routing will be illustrated using this simple 194 scenario. 196 Multi-hop network mobility is a subsidiary scenario. All major 197 aspects are inherited from the single-hop problem, while additional 198 complexity is incurred from traversing a mobile cloud. This may be 199 solved by either encapsulation or flooding ([8] provides a general 200 overview). Specific issues arising from (nested) tunneling or 201 flooding, especially the preservation of address transparency, 202 require treatment analogous to MIPv6. 204 +------+ +------+ 205 | MN | =====> | MN | 206 +------+ +------+ 207 | . 208 | . 209 | . 210 +-------+ +-------+ 211 | LAR 1 | | LAR 2 | 212 +-------+ +-------+ 213 \ / 214 *** *** *** *** 215 * ** ** ** * 216 +------+ +------+ * * 217 | MN | =====> | MN | * Mobile Network * 218 +------+ +------+ * * 219 | . * ** ** ** * 220 | . *** *** *** *** 221 | . | . 222 +-------+ +-------+ +-------+ +-------+ 223 | AR 1 | | AR 2 | | AR 1 | =====> | AR 2 | 224 +-------+ +-------+ +-------+ +-------+ 225 | | | | 226 *** *** *** *** *** *** *** *** 227 * ** ** ** * * ** ** ** * 228 * * * * 229 * Fixed Internet * * Fixed Internet * 230 * * * * 231 * ** ** ** * * ** ** ** * 232 *** *** *** *** *** *** *** *** 234 a) Single-Hop Mobility b) Multi-Hop Mobility 236 Figure 1: Mobility Scenarios 238 2. Problem Description 240 2.1 General Issues 242 Multicast mobility is a generic term, which subsumes a collection of 243 distinct functions. First, multicast communication is divided into 244 Any Source Multicast (ASM) [2] and Source Specific Multicast (SSM) 245 [9,10]. Second, the roles of senders and receivers are distinct and 246 asymmetric. Both may individually be mobile. Their interaction is 247 facilitated by a multicast routing protocol such as DVMRP [11], PIM- 248 SM/SSM [12,13], Bi-directional PIM [14],or inter-domain multicast 249 prefix advertisements via MBGP [15]. IPv6 clients interact using the 250 multicast listener discovery protocol (MLD and MLDv2) [16,17]. 252 Any multicast mobility solution needs to take all of these functional 253 blocks into account. It should enable seamless continuity of 254 multicast sessions when moving from one IPv6 subnet to another. It is 255 desired to preserve the multicast nature of packet distribution and 256 approximate optimal routing. It should support per-flow handover for 257 multicast traffic, because the properties and designations of flows 258 can be distinct. Such distinctions may result from differing 259 QoS/real-time requirements, but may also be caused by network 260 conditions that may differ for different groups. 262 The host group model extends the capability of the network layer 263 unicast service. In common with the architecture of fixed networks, 264 multicast mobility management should transparently utilize or 265 smoothly extend the unicast functions of MIPv6 [5], its security 266 extensions [6,18], its expediting schemes FMIPv6 [19] and HMIPv6 267 [20], its context transfer protocols [21], its multihoming 268 capabilities [22,23], emerging protocols like PMIPv6 [62] or future 269 developments. From the perspective of an integrated mobility 270 architecture, it is desirable to avoid multicast-specific as well as 271 unicast-restricted solutions, whenever general approaches can be 272 derived that can jointly support unicast and multicast. 274 Multicast routing dynamically adapts to the network topology at the 275 locations of the sender(s) and receiver(s) participating in a 276 multicast session, which then may change under mobility. However, 277 depending on the topology and the protocol in use, current multicast 278 routing protocols may require a time close to seconds to converge 279 following a change in receiver or sender location. This is far too 280 slow to support seamless handovers for interactive or real-time media 281 sessions. The actual temporal behavior strongly depends on the 282 multicast routing protocol in use, the configuration of routers, and 283 on the geometry of the current distribution tree. A mobility scheme 284 that re-adjusts routing, i.e., partially changes or fully 285 reconstructs a multicast tree, is forced to comply with the time 286 scale for protocol convergence. Specifically, it needs to consider a 287 possible rapid movement of the mobile node, as this may occur at much 288 higher rates than common protocol state updates. 290 The mobility of hosts using IP multicast can impact the service 291 presented to the higher-layer protocols. IP layer multicast packet 292 distribution is an unreliable service that is bound to connectionless 293 transport protocols. Where applications are sensitive to packet loss 294 or jitter, countermeasures need to be performed (loss recovery, 295 content recoding, concealment, etc) by the multicast transport or 296 application. Mobile multicast handovers should not introduce 297 significant additional packet drops. Due to statelessness, the bi- 298 casting of multicast flows does not cause degradations at the 299 transport layer, and applications should implement mechanisms to 300 detect and correctly respond to duplicate datagrams. Nevertheless, 301 individual application programs may not be robust with respect to 302 repeated reception of duplicate streams. 304 IP multicast applications can be designed to adapt the multicast 305 stream to prevailing network conditions (adapting the sending rate to 306 the level of congestion, adaptive tuning of clients in response to 307 measured delay, dynamic suppression of feedback messages, etc). An 308 adaptive application may also use more than one multicast group 309 (e.g., layered multicast in which a client selects a set of multicast 310 groups based on perceived available network capacity). A mobility 311 handover may temporarily disrupt the operation of these higher-layer 312 functions. The handover can invalidate assumptions about the 313 forwarding path (e.g., acceptable delivery rate, round trip delay), 314 which could impact an application and level of network traffic. Such 315 effects need to be considered in the design of multicast applications 316 and in the design of network-layer mobility. Specifically, mobility 317 mechanisms need to be robust to transient packet loss that may result 318 from invalid path expectations following a handover of an MN to a 319 different network. 321 Group addresses in general are location transparent, even though they 322 may be scoped and methods can embed unicast prefixes or Rendezvous 323 Point addresses [24]. The addresses of sources contributing to a 324 multicast session are interpreted by the routing infrastructure and 325 by receiver applications, which frequently are aware of source 326 addresses. Multicast therefore inherits the mobility address duality 327 problem of MIPv6 for source addresses: Addresses being a logical node 328 identifier, i.e., the home address (HoA) on the one hand, and a 329 topological locator, the care-of-address (CoA), on the other. At the 330 network layer, the elements that comprise the delivery tree, i.e., 331 multicast senders, forwarders and receivers, need to carefully 332 account for address duality issues, e.g., by using binding caches, 333 extended multicast states or signaling. 335 Multicast sources in general operate decoupled from their receivers 336 in the following sense: A multicast source sends packets to a group 337 of receivers that are unknown at the network layer, and thus operates 338 without a feedback channel. It neither has means to inquire about the 339 properties of its delivery trees, nor is it able to learn about the 340 network-layer state of its receivers. In the event of an inter-tree 341 handover, a mobile multicast source therefore is vulnerable to 342 loosing connectivity to receivers without noticing. (Appendix A 343 describes implicit source notification approaches). Applying a MIPv6 344 mobility binding update or return routability procedure will 345 similarly break the semantic of a receiver group remaining 346 unidentified by the source and thus cannot be applied in unicast 347 analogy. 349 Despite the complexity of the requirements, multicast mobility 350 management should seek lightweight solutions with easy deployment. 351 Realistic, sample deployment scenarios and architectures should be 352 provided in future solution documents. 354 2.2 Multicast Listener Mobility 356 2.2.1 Node & Application Perspective 358 A mobile multicast listener entering a new IP subnet requires 359 multicast reception following a handover in real-time. This needs to 360 transfer the multicast membership context from its old to its new 361 point of attachment. This can either be achieved by (re-) 362 establishing a tunnel or by transferring the MLD Listening State 363 information of the MN's moving interface(s) to the new upstream 364 router(s). In the latter case, it may encounter either one of the 365 following conditions: 366 o In the simplest scenario, packets of some, or all, of the 367 subscribed groups of the mobile node are already received by one 368 or several other group members in the new network, and thus 369 multicast streams natively flow after the MN arrives at the new 370 network. 371 o The requested multicast service may be supported and enabled in 372 the visited network, but the multicast groups under subscription 373 may not be forwarded to it, e.g., groups may be scoped or 374 administratively prohibited. This means that current distribution 375 trees for the desired groups may only be re-joined at a (possibly 376 large) routing distance. 377 o The new network may not be multicast-enabled or the specific 378 multicast service may be unavailable, e.g., unsupported or 379 prohibited. This means that current distribution trees for the 380 desired groups need to be re-joined at a large routing distance 381 by (re) establishing a tunnel to a multicast-enabled network 382 node. 384 The problem of achieving seamless multicast listener handovers is 385 thus threefold: 386 o Ensure multicast reception, even in visited networks, without 387 appropriate multicast support. 388 o Minimize multicast forwarding delay to provide seamless 389 and fast handovers for real-time services. Dependant on layer 2 390 and 3 handover performance, the time available for multicast 391 mobility operations is typically bound the total handover time 392 left after IPv6 connectivity is regained. In real-time scenarios 393 this may be significantly less than 100 ms. 394 o Minimize packet loss and reordering that result from multicast 395 handover management. 397 Moreover, in many wireless regimes it is also desirable to minimize 398 multicast-related signaling to preserve the limited resources of 399 battery powered mobile devices and the constrained transmission 400 capacities of the networks. This may lead to a desire to restrict MLD 401 queries towards the MN. Multihomed MNs may ensure smooth handoffs by 402 using a 'make-before-break' approach, which requires a per interface 403 subscription, facilitated by an MLD JOIN operating on a pre-selected 404 IPv6 interface. 406 Encapsulation on the path between the upstream router and the 407 receiver may result in MTU size conflicts, since path-MTU discovery 408 is often not supported for multicast and can reduce scalability in 409 networks with many different MTU sizes or introduce potential denial 410 of service vulnerabilities (since the originating addresses of ICMPv6 411 messages can not be verified for multicast). In the absence of 412 fragmentation at tunnel entry points, this may prevent the group 413 being forwarded to the destination. 415 2.2.2 Network Perspective 417 The infrastructure providing multicast services is required to keep 418 traffic following the MN without compromising network functionality. 419 Mobility solutions thus have to face some immediate problems: 421 o Realize native multicast forwarding, and where applicable 422 conserve network resources and utilize link layer multipoint 423 distribution to avoid data redundancy. 424 o Activate link multipoint services, even if the MN performs 425 only a layer 2 / vertical handover. 426 o Ensure routing convergence, even when the MN moves rapidly 427 and performs handovers at a high frequency. 428 o Avoid avalanche problems and stream multiplication (n-casting), 429 which potentially result from replicated tunnel initiation or 430 redundant forwarding at network nodes. 432 There are additional implications for the infrastructure: In changing 433 its point of attachment, an exclusive mobile receiver may cause 434 initiation in the new network and termination of a group distribution 435 service in the previous network. Mobility management may issue 436 traffic directives that lead to suboptimal routing, i.e., erroneous 437 subscriptions following predictive handover operations, or slow 438 effective leaves caused by MLD querying, or by departure of the MN 439 from a previous network without leaving the subscribed groups. 440 Finally, packet duplication and re-ordering may follow a change of 441 topology. 443 2.3 Multicast Source Mobility 445 2.3.1 Any Source Multicast Mobility 447 A node submitting data to an ASM group either forms the root of a 448 source specific shortest path tree (SPT), distributing data towards a 449 rendezvous point (RP) or receivers, or it forwards data directly down 450 a shared tree, e.g., via encapsulated PIM Register messages, or using 451 bi-directional PIM routing. Native forwarding along source specific 452 delivery trees will be bound to the source's topological network 453 address, due to reverse path forwarding (RPF) checks. A mobile 454 multicast source moving to a new subnetwork is only able to either 455 inject data into a previously established delivery tree, which may be 456 a rendezvous point based shared tree, or to (re)initiate the 457 construction of a multicast distribution tree for its new network 458 location. In the latter case, the mobile sender will have to proceed 459 without knowing whether the new tree has regained ability to forward 460 traffic to the group, due to the decoupling of sender and receivers. 462 A mobile multicast source must therefore provide address transparency 463 at two layers: To comply with RPF checks, it has to use an address 464 within the source field of the IPv6 basic header, which is in 465 topological agreement with the employed multicast distribution tree. 466 For application transparency the logical node identifier, commonly 467 the HoA, must be presented as the packet source address to the 468 transport layer at the receiver side. 470 The address transparency and temporal handover constraints pose major 471 problems for route optimizing mobility solutions. Additional issues 472 arise from possible packet loss and from multicast scoping. A mobile 473 source away from home must respect scoping restrictions that arise 474 from its home and its visited location [5]. 476 Intra-domain multicast routing may allow the use of shared trees that 477 can reduce mobility-related complexity. A static rendezvous point may 478 allow a mobile source to continuously send data to the group by 479 encapsulating packets to the RP with its previous topologically 480 correct or home source address. Intra-domain mobility is 481 transparently provided by bi-directional shared domain-spanning 482 trees, when using bi-directional PIM, eliminating the need for 483 tunneling to the corresponding RP (in contrast to IPv4, IPv6 ASM 484 multicast groups are associated with a specific RP/RPs). 486 Issues arise in inter-domain multicast, whenever notification of 487 source addresses is required between distributed instances of shared 488 trees. A new CoA acquired after a mobility handover will necessarily 489 be subject to inter-domain record exchange. In the presence of an 490 embedded rendezvous point address [24], e.g., the primary rendezvous 491 point for inter-domain PIM-SM will be globally appointed, and a newly 492 attached mobile source can contact the RP without prior signaling 493 (like a new source) and transmit data in the PIM register tunnel. 494 Multicast route optimization (e.g., PIM 'shortcuts') will require 495 multicast routing protocol operations equivalent to serving a new 496 source. 498 2.3.2 Source Specific Multicast Mobility 500 Source Specific Multicast has been designed for multicast senders 501 with static source addresses. The source addresses in a client 502 subscription to an SSM group is directly used to route 503 identification. Any SSM subscriber is thus forced to know the 504 topological address of the contributor to the group it wishes to 505 join. The SSM source identification becomes invalid when the 506 topological source address changes under mobility. Hence client 507 implementations of SSM source filtering must be MIPv6 aware in the 508 sense that a logical source identifier (HoA) is correctly mapped to 509 its current topological correspondent (CoA). 511 As a consequence, source mobility for SSM requires a conceptual 512 treatment beyond the problem scope of mobile ASM. A listener 513 subscribes to an (S,G) channel membership and routers establish an 514 (S,G)-state shortest path tree rooted at source S, therefore any 515 change of source addresses under mobility requires state updates at 516 all routers on the upstream path and at all receivers in the group. 517 On source handover, a new SPT needs to be established that will share 518 paths with the previous SPT, e.g., at the receiver side. As the 519 principle of multicast decoupling of a sender from its receivers 520 holds for SSM, the client updates needed for switching trees become a 521 severe burden. 523 An SSM listener may subscribe to or exclude any specific multicast 524 source, and thereby wants to rely on the topological correctness of 525 network operations. The SSM design permits trust in equivalence to 526 the correctness of unicast routing tables. Any SSM mobility solution 527 should preserve this degree of confidence. Binding updates for SSM 528 sources thus should have to prove address correctness in the unicast 529 routing sense, which is equivalent to binding update security with a 530 correspondent node in MIPv6 [5]. 532 The above methods add significant complexity to provide a robust SSM 533 mobility solution, which needs to converge to optimal routes and, for 534 efficiency, is desired to avoid data encapsulation. Like ASM, 535 handover management is a time-critical operation. The routing 536 distance between subsequent points of attachment, the 'step size' of 537 the mobile from previous to next designated router, may serve as an 538 appropriate measure of complexity [25,26]. 540 Finally, Source Specific Multicast has been designed as a light- 541 weight approach to group communication. In adding mobility 542 management, it is desirable to preserve the leanness of SSM by 543 minimizing additional signaling overhead. 545 2.4 Deployment Issues 547 IP multicast deployment in general has been hesitant over the past 15 548 years, even though all major router vendors and operating systems 549 offer implementations that support multicast [27]. While many 550 (walled) domains or enterprise networks operate point-to-multipoint 551 services, IP multicast rollout is currently limited in public inter- 552 domain scenarios [28]. A dispute arose on the appropriate layer, 553 where group communication service should reside, and the focus of the 554 research community turned towards application layer multicast. This 555 debate on "efficiency versus deployment complexity" now overlaps the 556 mobile multicast domain [29]. Garyfalos and Almeroth [30] derived 557 from fairly generic principles that when mobility is introduced, the 558 performance gap between IP and application layer multicast widens in 559 different metrics up to a factor of four. 561 Facing deployment complexity, it is desirable that any solution for 562 mobile multicast leaves routing protocols unchanged. Mobility 563 management in such a deployment-friendly scheme should preferably be 564 handled at edge nodes, preserving a mobility-agnostic routing 565 infrastructure. Future research needs to search for such simple, 566 infrastructure transparent solutions, even though there are 567 reasonable doubts, whether this can be achieved in all cases. 569 Nevertheless, multicast services in mobile environments may soon 570 become indispensable, when multimedia distribution services such as 571 DVB-H [31,32] or IPTV develop a strong business case for IP 572 portables. As IP mobility becomes an important service and as 573 efficient link utilization is of a larger impact in costly radio 574 environments, the evolution of multicast protocols will naturally 575 follow mobility constraints. 577 3.Characteristics of Multicast Routing Trees under Mobility 579 Multicast distribution trees have been studied from a focus of 580 network efficiency. Grounded on empirical observations Chuang and 581 Sirbu [33] proposed a scaling power-law for the total number of links 582 in a multicast shortest path tree with m receivers (proportional to 583 m^k). The authors consistently identified the scale factor to attain 584 the independent constant k = 0.8. The validity of such universal, 585 heavy-tailed distribution suggests that multicast shortest path trees 586 are of self-similar nature with many nodes of small, but few of 587 higher degrees. Trees consequently would be shaped rather tall than 588 wide. 590 Subsequent empirical and analytical work [34,35] debated the 591 applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. 592 [34] proved that the proposed power law cannot hold for an increasing 593 Internet or very large multicast groups, but is indeed applicable for 594 moderate receiver numbers and the current Internet size of N = 10^5 595 core nodes. Investigating self-similarity Janic and Van Mieghem [36] 596 semi-empirically substantiated that multicast shortest path trees in 597 the Internet can be modeled with reasonable accuracy by uniform 598 recursive trees (URT) [37], provided m remains small compared to N. 600 The mobility perspective on shortest path trees focuses on their 601 alteration, i.e., the degree of topological changes induced by 602 movement. For receivers, and more interestingly for sources this may 603 serve as an outer measure for routing complexity. Mobile listeners 604 moving to neighboring networks will only alter tree branches 605 extending over a few hops. Source specific multicast trees 606 subsequently generated from source handover steps are not 607 independent, but highly correlated. They most likely branch to 608 identical receivers at one or several intersection points. By the 609 self-similar nature, the persistent sub-trees (of previous and next 610 distribution tree), rooted at any such intersection point, exhibit 611 again the scaling law behavior, are tall-shaped with nodes of mainly 612 low degree and thus likely to coincide. Tree alterations under 613 mobility have been studied in [26], both analytically and by 614 simulations. It was found that even in large networks and for 615 moderate receiver numbers more than 80 % of the multicast router 616 states remain invariant under a source handover. 618 4. Link Layer Aspects 620 4.1 General Background 622 Scalable group data distribution has the highest potential in leaf 623 networks, where large numbers of end systems reside. Consequently, it 624 is not surprising that most LAN network access technologies natively 625 support point-to-multipoint or multicast services. Of focal interest 626 to the mobility domain are wireless access technologies, which are 627 inherently broadcast-oriented and always operate on a shared medium 628 with limited frequency and bandwidth. 630 Several aspects need consideration: First, dissimilar network access 631 radio technologies cause distinct group traffic transmissions. There 632 are: 634 o connection-less link services of a broadcast type, which mostly 635 are bound to limited reliability; 637 o connection-oriented link services of a point-to-multipoint type, 638 which require more complex control and frequently exhibit reduced 639 efficiency; 641 o connection-oriented link services of a broadcast type, which are 642 restricted to unidirectional data transmission. 644 In addition, multicast may be distributed via multiple point-to-point 645 unicast links without use of a dedicated multipoint radio channel. A 646 fundamental difference between unicast and group transmission arises 647 from power management. Some radio technologies adjust transmit power 648 to be as small as possible based on link-layer feedback from the 649 receiver which is not done in multipoint mode. They consequently 650 incur a 'multicast tax', making multicast less efficient than unicast 651 unless the number of receivers is larger than some threshold. 653 Second, point-to-multipoint service activation at the network access 654 layer requires a mapping mechanism from network layer requests. This 655 function is commonly achieved by L3 awareness, i.e., IGMP/MLD 656 snooping [69] or proxy [38], which occasionally is complemented by 657 Multicast VLAN Registration (MVR). MVR allows sharing of a single 658 multicast IEEE 802.1Q Virtual LAN in the network, while subscribers 659 remain in separate VLANs. This layer 2 separation of multicast and 660 unicast traffic can be employed as a workaround for point-to-point 661 link models to establish a common multicast link. 663 Third, an address mapping between the layers is needed for common 664 group identification. Address resolution schemes depend on framing 665 details for the technologies in use, but commonly cause a significant 666 address overlap at the lower layer. 668 4.2 Multicast for Specific Technologies 670 4.2.1 802.11 WLAN 672 IEEE 802.11 WLAN is a broadcast network of Ethernet type. This 673 inherits multicast address mapping concepts from 802.3. In 674 infrastructure mode, an access point operates as a repeater, only 675 bridging data between the Base (BSS) and the Extended Service Set 676 (ESS). A mobile node submits multicast data to an access point in 677 point-to-point acknowledged unicast mode (when the ToDS bit is set). 678 An access point receiving multicast data from a MN simply repeats 679 multicast frames to the BSS and propagates them to the ESS as 680 unacknowledged broadcast. Multicast frames received from the ESS 681 receive similar treatment. 683 Multicast frame delivery has the following characteristics: 685 o As an unacknowledged service it offers limited reliability. 686 Frames (and hence packet) loss arise from interference, 687 collision, or time-varying channel properties. 689 o Data distribution may be delayed, as unicast power saving 690 synchronization via Traffic Indication Messages (TIM) does not 691 operate in multicast mode. Access points buffer multicast packets 692 while waiting for a larger DTIM interval, whenever stations use 693 the power saving mode. 695 o Multipoint data may cause congestion, because the distribution 696 system floods multicast, without further control. All access 697 points of the same subnet replicate multicast frames. 699 To limit or prevent the latter, many vendors have implemented a 700 configurable rate limit for forwarding multicast packets. 701 Additionally, an IGMP/MLD snooping or proxy may be active at the 702 bridging layer between the BSS and the ESS or at switches 703 interconnecting access points. 705 4.2.2 802.16 WIMAX 707 IEEE 802.16 WIMAX combines a family of connection-oriented radio 708 transmission services that can operate in single-hop point-to- 709 multipoint (PMP) or in mesh mode. The latter does not support 710 multipoint transmission and currently has no deployment. PMP operates 711 between Base and Subscriber Stations in distinguished, unidirectional 712 channels. The channel assignment is controlled by the Base Station, 713 which assigns channel IDs (CIDs) within service flows to the 714 Subscriber Stations. Service flows may provide an optional Automatic 715 Repeat Request (ARQ) to improve reliability and may operate in point- 716 to-point or point-to-multipoint (restricted to downlink and without 717 ARQ) mode. 719 A WIMAX Base Station operates as a L2 switch in full duplex mode, 720 where switching is based on CIDs. Two possible IPv6 link models for 721 mobile access deployment scenarios exist: Shared IPv6 prefix and 722 point-to-point link model [39]. The latter treats each connection to 723 a mobile node as a single link and is recommended in the IPv6 724 Convergence Sublayer [40], while MAC separation within a shared 725 prefix is applied in the IP over Ethernet CS [41]. The point-to-point 726 link model on the IP layer conflicts with a consistent group 727 distribution via a shared medium (cf. section 4.1 for MVR as a 728 workaround). 730 To invoke a multipoint data channel, the base station assigns a 731 common CID to all Subscriber Stations in the group. An IPv6 multicast 732 address mapping to these 16 bit IDs is proposed by copying either the 733 4 lowest bits, while sustaining the scope field, or by utilizing the 734 8 lowest bits derived from Multicast on Ethernet CS [42]. For 735 selecting group members, a Base Station may implement IGMP/MLD 736 snooping or proxy as foreseen in 802.16e-2005 [43]. 738 A Subscriber Station will send multicast data to a Base Station as a 739 point-to-point unicast stream, which - in the presence of the IPv6 CS 740 - is forwarded to the upstream access router. The access router or - 741 in the presence of the IP over Ethernet CS - the Base Station may 742 return multicast data to the downstream Base Station by feeding into 743 a multicast service channel. On reception, a Subscriber Station 744 cannot distinguish multicast from unicast streams on the link layer. 746 Multicast services have the following characteristics: 748 o Multicast CIDs are unidirectional and available only in the 749 downlink direction. Thus a native broadcast-type forwarding model 750 is not available. 752 o The mapping of multicast addresses to CIDs needs standardization, 753 since different entities (Access Router, Base Station) may have 754 to perform the mapping. 756 o CID collisions for different multicast groups are very likely due 757 to the short ID space. As a consequence, multicast data 758 transmission may occur in joint point-to-multipoint groups of 759 reduced selectiveness. 761 o The point-to-point link model for mobile access contradicts a 762 consistent mapping of IP layer multicast onto 802.16 763 point-to-multipoint services. 765 o Multipoint channels cannot operate ARQ service and thus 766 experience a reduced reliability. 768 4.2.3 3GPP/3GPP2 770 The 3GPP System architecture spans a circuit switched (CS) and a 771 packet switched (PS) domain, the latter General Packet Radio Services 772 (GPRS) incorporates the IP Multimedia Subsystem (IMS) [44]. The 3GPP 773 PS is connection-oriented and based on the concept of Packet Data 774 Protocol (PDP) Contexts. PDPs define point-to-point links between the 775 Mobile Terminal and the Gateway GPRS Support Node (GGSN). Internet 776 service types are PPP, IPv4 and IPv6, where the recommendation for 777 IPv6 address assignment associates a prefix to each (primary) PDP 778 context [45]. Current packet filtering practice causes inter-working 779 problems between Mobile IPv6 nodes connected via GPRS [46]. 781 In UMTS Rel. 6 the IMS was extended to include Multimedia Broadcast 782 and Multicast Services (MBMS). A point-to-multipoint GPRS connection 783 service is operated on radio links, while the gateway service to 784 Internet multicast is handled at the IGMP/MLD-aware GGSN. Local 785 multicast packet distribution is used within the GPRS IP backbone 786 resulting in the common double encapsulation at GGSN: global IP 787 multicast datagrams over GTP (with multipoint TID) over local IP 788 multicast. 790 The 3GPP MBMS has the following characteristics: 792 o There is no immediate layer 2 source-to-destination transition, 793 resulting in transit of all multicast traffic at the GGSN. 795 o As GGSN commonly are regional, distant entities, triangular 796 routing and encapsulation may cause a significant degradation of 797 efficiency. 799 In 3GPP2, the MBMS has been extended to the Broadcast and Multicast 800 Service (BCMCS) [47], which on the routing layer operates very 801 similar to MBMS. In both 3GPP and 3GPP2 multicast can either be sent 802 using point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and 803 there is support for switching between PTP and PTM. PTM uses an 804 unidirectional common channel, operating in unacknowledged without 805 adjustment of power levels and no reporting on lost packets. 807 4.2.4 DVB-H / DVB-IPDC 809 Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional 810 physical layer broadcasting specification for the efficient delivery 811 of broadband, IP-encapsulated data streams, and published as an ETSI 812 standard [48] (see http://www.dvb-h.org). DVB uses a mechanism called 813 multi-protocol encapsulation (MPE), which enables a transport of 814 network layer protocols on top of a link layer built from MPEG-2 815 transport streams and includes link forward error correction (FEC). 816 In this model, DVB transmission networks not only support TV 817 broadcasting, but also offer an IP Datacast Service. DVB-IPDC [31] 818 consists of a number of individual, application layer specifications, 819 some of which continue to be developed. Transport Streams (TS) form 820 the basic logical channels, identified by a 13 bit TS ID (PID). This, 821 together with a multiplex service ID, is associated with IPv4 or IPv6 822 addresses [49] and used for selective traffic filtering at receivers. 823 Upstream channels may complement DVB-H using alternative transmission 824 technologies. 826 Multicast distribution services are defined by a mapping of groups 827 onto appropriate PIDs, which is managed at the IP Encapsulator [50]. 828 To increase flexibility and avoid collisions, this address resolution 829 is facilitated by dynamic tables, provided within the self-consistent 830 MPEG-2 TS. Mobility is supported in the sense that changes of cell 831 ID, network ID or Transport Stream ID are foreseen [51]. A multicast 832 receiver thus needs to re-locate the multicast services it is 833 subscribed to, which is to be done in the synchronization phase, and 834 update its service filters. Its handover decision may depend on 835 service availability. An active service subscription (multicast join) 836 requires initiation at the IP Encapsulator / DVB-H Gateway, which 837 cannot be signaled in a pure DVB-H network. 839 4.2.5 TV Broadcast and Satellite Networks 841 IP multicast may be enabled in TV broadcast networks, including those 842 specified by DVB, ATSC, and related standards [50]. These standards 843 are also used for one and two-way satellite IP services. Networks 844 based on the MPEG-2 Transport Stream may support either the multi- 845 protocol encapsulation (MPE) or the unidirectional lightweight 846 encapsulation (ULE) [52]. The second generation DVB standards allow 847 the Transport Stream to be replaced with a Generic Stream, using the 848 generic stream encapsulation (GSE) [53]. These encapsulation formats 849 all support multicast operation. 851 In MPEG-2 transmission networks, multicast distribution services are 852 defined by a mapping of groups onto appropriate PIDs, which is 853 managed at the IP Encapsulator [50]. The addressing issues resemble 854 those for DVB-H (section 4.2.4) [49]. The issues for using GSE 855 resemble those for ULE (except the PID is not available as a 856 mechanism for filtering traffic). Networks that provide bidirectional 857 connectivity may allow active service subscription (multicast join) 858 to initiate forwarding from the upstream IP Encapsulator / gateway. 859 Some kind of filtering can be achieved using the Input Stream 860 Identifier (ISI) field. 862 4.3 Vertical Multicast Handovers 864 A mobile multicast node may change its point of layer 2 attachment 865 within homogeneous access technologies (horizontal handover) or 866 between heterogeneous links (vertical handover). In either case a 867 layer 3 network change may or may not take place, but multicast-aware 868 links always need information about group traffic demands. 870 Consequently, a dedicated context transfer of multicast subscriptions 871 is required at the network access. Such Media Independent Handover 872 (MIH) is addressed in IEEE 802.21 [54], but is relevant also beyond 873 IEEE protocols. Mobility services transport for MIH naturally reside 874 on the network layer and are currently in the process of 875 specification [55]. 877 MIH needs to assist in more than service discovery: There is a need 878 for complex, media dependent multicast adaptation, a possible absence 879 of MLD signaling in L2-only transfers and requirements originating 880 from predictive handovers, a multicast mobility services transport 881 needs to be sufficiently comprehensive and abstract to initiate a 882 seamless multicast handoff at network access. 884 Functions required for MIH include: 886 o Service discovery. 887 o Service context transformation. 888 o Service context transfer. 889 o Service invocation. 891 5. Solutions 893 5.1 General Approaches 895 Three approaches to mobile multicast are common [56]: 897 o Bi-directional Tunneling, in which the mobile node tunnels all 898 multicast data via its home agent. This fundamental multicast 899 solution hides all movement and results in static multicast 900 trees. It may be employed transparently by mobile multicast 901 listeners and sources, at the cost of triangular routing and 902 possibly significant performance degradation from widely spanned 903 data tunnels. 905 o Remote Subscription forces the mobile node to re-initiate 906 multicast distribution following handover, e.g., by submitting an 907 MLD listener report to the subnet where a receiver attaches. This 908 approach of tree discontinuation relies on multicast dynamics to 909 adapt to network changes. It not only results in significant 910 service disruption, but leads to mobility-driven changes of 911 source addresses, and thus cannot support session persistence 912 under multicast source mobility. 914 o Agent-based solutions attempt to balance between the previous two 915 mechanisms. Static agents typically act as local tunneling 916 proxies, allowing for some inter-agent handover when the mobile 917 node moves. A decelerated inter-tree handover, i.e. 'tree 918 walking', will be the outcome of agent-based multicast mobility, 919 where some extra effort is needed to sustain session persistence 920 through address transparency of mobile sources. 922 MIPv6 [5] introduces bi-directional tunneling as well as remote 923 subscription as minimal standard solutions. Various publications 924 suggest utilizing remote subscription for listener mobility only, 925 while advising bi-directional tunneling as the solution for source 926 mobility. Such an approach avoids the 'tunnel convergence' or 927 'avalanche' problem [56], which refers to the responsibility of the 928 home agent to multiply and encapsulate packets for many receivers of 929 the same group, even if they are located within the same subnetwork. 930 However, this suffers from the drawback that multicast communication 931 roles are not explicitly known at the network layer and may change 932 unexpectedly. 934 None of the above approaches address SSM source mobility, except the 935 use of bi-directional tunneling. 937 5.2 Solutions for Multicast Listener Mobility 939 5.2.1 Agent Assistance 941 There are proposals for agent-assisted handover for host-based 942 mobility, which complement the unicast real-time mobility 943 infrastructure of Fast MIPv6 [19], the M-FMIPv6 [57,58], and of 944 Hierarchical MIPv6 [20], the M-HMIPv6 [59], and to context transfer 945 [60], which have been thoroughly analyzed in [25,61]. 947 All these solutions presume the context state was stored within a 948 network node that is reachable before and after a move. But there 949 could be cases were the MN is no longer in contact with the previous 950 network, when at the new location. In this case, the network itself 951 cannot assist in the context transfer. Such scenarios may occur when 952 moving from one (walled) operator to another and will require a 953 backwards compatible way to recover from loss of connectivity and 954 context based on the node alone. 956 Network based mobility management, PMIPv6 [62], is multicast 957 transparent in the sense that the MN experiences a point-to-point 958 home link fixed at its (static) Local Mobility Anchor (LMA). This 959 virtual home link is composed of a unicast tunnel between the LMA and 960 the current Mobile Access Gateway (MAG), and a point-to-point link 961 connecting the current MAG to the MN. A PMIPv6 domain thereby 962 inherits MTU-size problems from spanning tunnels at the receiver 963 site. Furthermore, two avalanche problem points can be identified: 964 The LMA may be required to tunnel data to a large number of MAGs, 965 while a MAG may be required to forward the same multicast stream to 966 many MNs via individual point-to-point links [63]. Future 967 optimizations and extensions to shared links preferably adapt native 968 multicast distribution towards the edge network, possibly using a 969 local routing option, including context transfer between access 970 gateways to assist IP-mobility-agnostic MNs. 972 An approach based on dynamically negotiated inter-agent handovers is 973 presented in [64]. Aside from IETF work, numerous publications 974 present proposals for seamless multicast listener mobility, e.g. [65] 975 provides a comprehensive overview of the work prior to 2004. 977 5.2.2 Multicast Encapsulation 979 Encapsulation of multicast data packets is an established method to 980 shield mobility and to enable access to remotely located data 981 services, e.g., streams from the home network. Applying generic 982 packet tunneling in IPv6 [66] using a unicast point-to-point method 983 will also allow multicast-agnostic domains to be transited, but does 984 inherit the tunnel convergence problem and may result in traffic 985 multiplication. 987 Multicast enabled environments may take advantage of point-to- 988 multipoint encapsulation, i.e., generic packet tunneling using an 989 appropriate multicast destination address in the outer header. Such 990 multicast-in-multicast encapsulated packets similarly enable 991 reception of remotely located streams, but do not suffer from the 992 scaling overhead from using unicast tunnels. 994 The tunnel entry point performing encapsulation should provide 995 fragmentation of data packets to avoid issues resulting from MTU size 996 constraints within the network(s) supporting the tunnel(s). 998 5.2.3 Hybrid Architectures 1000 There has been recent interest in seeking method that avoid the 1001 complexity at the Internet core network, e.g. application layer and 1002 overlay proposals for (mobile) multicast. The possibility of 1003 integrating multicast distribution on the overlay into the network 1004 layer is also being considered by the IRTF Scalable Adaptive 1005 Multicast (SAM) Research Group. 1007 An early hybrid architecture using reactively operating proxy- 1008 gateways located at the Internet edges was introduced by Garyfalos 1009 and Almeroth [30]. The authors presented an Intelligent Gateway 1010 Multicast as a bridge between mobility-aware native multicast 1011 management in access networks and mobility group distribution 1012 services in the Internet core, which may be operated on the network 1013 or application layer. The Hybrid Shared Tree approach [67] introduced 1014 a mobility-agnostic multicast backbone on the overlay. 1016 Current work in the SAM RG is developing general architectural 1017 approaches for hybrid multicast solutions [68] that will require a 1018 detailed design in future work. 1020 5.2.4 MLD Extensions 1022 The default timer values specified in MLD [17] were not designed for 1023 the mobility context. This results in a slow reaction of the 1024 multicast routing infrastructure (including layer-3-aware access 1025 devices [69]) following a client leave. This may be a disadvantage 1026 for wireless links, where performance may be improved by carefully 1027 tuning the Query Interval. Some vendors have optimized performance by 1028 implementing a listener node table at the access router that can 1029 eliminate query timeouts on leaves (explicit receiver tracking). 1031 A MN operating predictive handover, e.g., using FMIPv6, may 1032 accelerate multicast service termination when leaving the previous 1033 network by submitting an early Done message before handoff. MLD 1034 router querying will allow the multicast forwarding state to be 1035 restored in case of an erroneous prediction (i.e., an anticipated 1036 move to a network that is not fulfilled). Backward context transfer 1037 may otherwise ensure a leave is signaled. A further optimization was 1038 introduced by Jelger and Noel [70] for the special case when the HA 1039 is a multicast router. A Done message received through a tunnel from 1040 the mobile end node (through a point-to-point link directly 1041 connecting the MN, in general), should not initiate standard MLD 1042 membership queries (with a subsequent timeout). Such explicit 1043 treatment of point-to-point links will reduce traffic and accelerate 1044 the control protocol. Explicit tracking will cause identical protocol 1045 behavior. 1047 While away from home, a MN may wish to rely on a proxy or 'standby' 1048 multicast membership service, optionally provided by a HA or proxy 1049 router. Such functions rely on the ability to restart fast packet 1050 forwarding; it may be desirable for the proxy router to remain part 1051 of the multicast delivery tree, even when transmission of group data 1052 is paused. To enable such proxy control, the authors in [70] propose 1053 an extension to MLD, introducing a Listener Hold message that is 1054 exchanged between the MN and the HA. This idea was developed in [59] 1055 to propose multicast router attendance control, allowing for a 1056 general deployment of group membership proxies. Some currently 1057 deployed IPTV solutions use such a mechanism in combination with a 1058 recent (video) frame buffer, to enable fast channel switching between 1059 several IPTV multicast flows (zapping). 1061 5.3 Solutions for Multicast Source Mobility 1063 5.3.1 Any Source Multicast Mobility Approaches 1064 Solutions for multicast source mobility can be divided into three 1065 categories: 1067 o Statically Rooted Distribution Trees. These methods follow a 1068 shared tree approach. Romdhani et al. [71] proposed employing 1069 the Rendezvous Points of PIM-SM as mobility anchors. Mobile 1070 senders tunnel their data to these "Mobility-aware Rendezvous 1071 Points" (MRPs). When restricted to a single domain, this scheme is 1072 equivalent to bi-directional tunneling. Focusing on interdomain 1073 mobile multicast, the authors designed a tunnel- or SSM-based 1074 backbone distribution of packets between MRPs. 1076 o Reconstruction of Distribution Trees. Several authors have 1077 proposed the construction of a completely new distribution tree 1078 after the movement of a mobile source and therefore have to 1079 compensate for the additional routing (tree-building) delay. 1080 M-HMIPv6 [59] tunnels data into a previously established tree 1081 rooted at mobility anchor points to compensate for the routing 1082 delay until a protocol dependent timer expires. The RBMoM 1083 protocol [72] introduces an additional Multicast Agent (MA) that 1084 advertises its service range. A mobile source registers with 1085 the closest MA and tunnels data through it. When moving out of 1086 the previous service range, it will perform MA discovery, a re- 1087 registration and continue data tunneling with a newly established 1088 Multicast Agent in its new current vicinity. 1090 o Tree Modification Schemes. In the case of DVMRP routing, 1091 Chang and Yen [73] propose an algorithm to extend the root of a 1092 given delivery tree for incorporating a new source location in 1093 ASM. The authors rely on a complex additional signaling protocol 1094 to fix DVMRP forwarding states and heal failures in the reverse 1095 path forwarding (RPF) checks. 1097 5.3.2 Source Specific Multicast Mobility Approaches 1099 The shared tree approach of [71] has been extended to support SSM 1100 mobility by introducing the HoA address record to the Mobility-aware 1101 Rendezvous Points. The MRPs operate using extended multicast routing 1102 tables that simultaneously hold the HoA and CoA and thus can 1103 logically identify the appropriate distribution tree. Mobility thus 1104 may re-introduces the concept of rendezvous points to SSM routing. 1106 Approaches for reconstructing SPTs in SSM rely on a client 1107 notification to establish new router state. It also needs to preserve 1108 address transparency for the client. Thaler [74] proposed introducing 1109 a binding cache and providing source address transparency analogous 1110 to MIPv6 unicast communication. Initial session announcements and 1111 changes of source addresses are distributed periodically to clients 1112 via an additional multicast control tree rooted at the home agent. 1113 Source tree handovers are then activated on listener requests. 1115 Jelger and Noel [75] suggest handover improvements employing anchor 1116 points within the source network, supporting continuous data 1117 reception during client initiated handovers. Client updates are 1118 triggered out of band, e.g. by SDR/SAP [76]. Receiver-oriented tree 1119 construction in SSM thus remains unsynchronized with source 1120 handovers. 1122 To address the synchronization problem at the routing layer, several 1123 proposals have focused on direct modification of the distribution 1124 trees. A recursive scheme may use loose unicast source routes with 1125 branch points, based on a multicast Hop-by-Hop protocol. Vida et al 1126 [77] optimized SPT for a moving source on the path between the source 1127 and first branching point. O'Neill [78] suggested a scheme to 1128 overcome RPF check failures that originate from multicast source 1129 address changes with a rendezvous point scenario by introducing 1130 extended routing information, which accompanies data in a Hop-by-Hop 1131 option "RPF redirect" header. The Tree Morphing approach of Schmidt 1132 and Waehlisch [79] used source routing to extend the root of a 1133 previously established SPT, thereby injecting router state updates in 1134 a Hop-by-Hop option header. Using extended RPF checks the elongated 1135 tree autonomously initiates shortcuts and smoothly reduces to a new 1136 SPT rooted at the relocated source. Lee et al. [80] introduced a 1137 state-update mechanism for re-using major parts of established 1138 multicast trees. The authors start from an initially established 1139 distribution state, centered at the mobile source's home agent. A 1140 mobile leaving its home network will signal a multicast forwarding 1141 state update on the path to its home agent and, subsequently, 1142 distribution states according to the mobile source's new CoA along 1143 the previous distribution tree. Multicast data is then intended to 1144 flow natively using triangular routes via the elongation and an 1145 updated tree centered on the home agent. 1147 6. Security Considerations 1149 This document discusses multicast extensions to mobility. It does not 1150 define new methods or procedures. Security issues arise from source 1151 address binding updates, specifically in the case of source specific 1152 multicast. Threats of hijacking unicast sessions will result from any 1153 solution jointly operating binding updates for unicast and multicast 1154 sessions. 1156 Mobility protocols need to consider the implications and requirements 1157 for AAA. AAA binding records may change between attachments, or may 1158 be individually chosen prior to network (re-)association. The most 1159 appropriate network path may be one that satisfies user preferences, 1160 e.g., to use/avoid a specific network, minimize monetary cost, etc, 1161 rather than one that only minimizes the routing cost. Consequently, 1162 AAA bindings cannot be treated at a pure level of context transfer. 1164 Admission control issues may arise with new CoA source addresses 1165 being introduced to SSM channels (cf. [81] for a comprehensive 1166 discussion). Due to lack of feedback, the admission [82] and binding 1167 updates [83] of mobile multicast sources require autonomously 1168 verifiable authentication as can be achieved by Cryptographically 1169 Generated Addresses (CGAs). 1171 Modification to IETF protocols (e.g. routing, membership, session 1172 announcement and control) as well as the introduction of new 1173 entities, e.g., multicast mobility agents, can introduce security 1174 vulnerabilities and require consideration of issues such as 1175 authentication of network entities, methods to mitigate denial of 1176 service (in terms of unwanted network traffic, unnecessary 1177 consumption of router/host resources and router/host state/buffers). 1178 Future solutions must therefore analyze and address the security 1179 implications of supporting mobile multicast. 1181 7.Summary and Future Steps 1183 This document is intended to provide a basis for the future design of 1184 mobile IPv6 multicast methods and protocols by: 1186 o providing a structured overview of the problem space that 1187 multicast and mobility jointly generate at the IPv6 layer; 1189 o referencing the implications and constraints arising from 1190 lower and upper layers, and from deployment; 1192 o briefly surveying conceptual ideas of currently available 1193 solutions; 1195 o including a comprehensive bibliographic reference base. 1197 It is recommended that future steps towards extending mobility 1198 services to multicast proceed to first solve the following problems: 1200 1. Ensure seamless multicast reception during handovers, 1201 meeting the requirements of mobile IPv6 nodes and networks. 1202 Thereby address the problems of home subscription without 1203 n-tunnels, as well as native multicast reception in those 1204 visited networks, which offer a group communication service. 1206 2. Integrate multicast listener support into unicast mobility 1207 management schemes and architectural entities to define a 1208 consistent mobility service architecture, providing equal 1209 supporting for unicast and multicast communication. 1211 3. Provide basic multicast source mobility by designing 1212 address duality management at end nodes. 1214 8. IANA Considerations 1216 There are no IANA considerations introduced by this draft. 1218 Appendix A. Implicit Source Notification Options 1220 An IP multicast source transmits data to a group of receivers without 1221 requiring any explicit feedback from the group. Sources therefore are 1222 unaware at the network-layer of whether any receivers have subscribed 1223 to the group, and unconditionally send multicast packets which 1224 propagate in the network to the first-hop router (often known in PIM 1225 as the designated router). There have been attempts to implicitly 1226 obtain information about the listening group members, e.g. extending 1227 an IGMP/MLD querier to inform the source of the existence of 1228 subscribed receivers. Multicast Source Notification of Interest 1229 Protocol (MSNIP) [84] was such a suggested method that allowed a 1230 multicast source to querying the upstream designated router. However, 1231 this work did not progress within the IETF mboned working group and 1232 was terminated by IETF. 1234 Multicast sources may also be controlled at the session or transport 1235 layer using end-to-end control protocols. A majority of real-time 1236 applications employ the Realtime Transport Protocol (RTP) [85]. The 1237 accompanying control protocol RTCP [81] allows receivers to report 1238 information about multicast group membership and associated 1239 performance data. In multicast, the RTCP reports are submitted to the 1240 same group and thus may be monitored by the source to monitor, manage 1241 and control multicast group operations. The Real Time Streaming 1242 Protocol (RTSP), (RFC 2326) provides session layer control that may 1243 be used to control a multicast source. However, RTCP and RTSP 1244 information is intended for end-to-end control and is not necessarily 1245 visible at the network layer. Application designers may chose to 1246 implement any appropriate control plane for their multicast 1247 applications (e.g. reliable multicast transport protocols_), and 1248 therefore a network-layer mobility mechanism must not assume the 1249 presence of a specific transport or session protocols. 1251 9. References 1253 Informative References 1254 1 Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM 1255 SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, 1256 ACM Press, June, 1984. 1258 2 S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 1259 August 1989. 1261 3 G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts", 1262 IEEE Communications Magazine, 35(1), pp. 54-58, January 1997. 1264 4 R. Hinden and S. Deering, "Internet Protocol Version 6 1265 Specification", RFC 2460, December 1998. 1267 5 D.B. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 1268 RFC 3775, June 2004. 1270 6 V. Devarapalli and F. Dupont, "Mobile IPv6 Operation with IKEv2 1271 and the Revised IPsec Architecture", RFC 4877, April 2007. 1273 7 ITU-T Recommendation, "G.114 - One-way transmission time", 1274 Telecommunication Union Standardization Sector, 05/2003. 1276 8 Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks", 1277 IEEE Communications Magazine, 43(9), pp. 23-30, September 2005. 1279 9 S. Bhattacharyya, "An Overview of Source-Specific Multicast (SSM)", 1280 RFC 3569, July 2003. 1282 10 H. Holbrook, B. Cain, "Source-Specific Multicast for IP", RFC 1283 4607, August 2006. 1285 11 D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector 1286 Multicast Routing Protocol", RFC 1075, November 1988. 1288 12 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. 1289 Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol 1290 Independent Multicast-Sparse Mode (PIM-SM): Protocol 1291 Specification", RFC 2362, June 1998. 1293 13 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1294 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1295 Specification (Revised)", RFC 4601, August 2006. 1297 14 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bidirectional 1298 Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 1299 2007. 1301 15 T. Bates et al. "Multiprotocol Extensions for BGP-4", RFC 4760, 1302 January 2007. 1304 16 S. Deering, W. Fenner and B. Haberman "Multicast Listener 1305 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1307 17 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version 1308 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1310 18 Arkko, J, Vogt, C, Haddad, W. "Enhanced Route Optimization for 1311 Mobile IPv6", RFC 4866, May 2007. 1313 19 Koodli, R. "Mobile IPv6 Fast Handovers", RFC 5268, June 2008. 1315 20 Soliman, H, Castelluccia, C, El-Malki, K, Bellier, L. 1316 "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, 1317 October 2008. 1319 21 Loughney, J, Nakhjiri, M, Perkins, C, Koodli, R. "Context Transfer 1320 Protocol (CXTP)", RFC 4067, July 2005. 1322 22 Montavont, N, et al. "Analysis of Multihoming in Mobile IPv6", 1323 draft-ietf-monami6-mipv6-analysis-05, Internet Draft (work in 1324 progress), May 2008. 1326 23 Narayanan, V, Thaler, D, Bagnulo, M, Soliman, H. "IP Mobility and 1327 Multi-homing Interactions and Architectural Considerations", 1328 draft-vidya-ip-mobility-multihoming-interactions-01.txt, Internet 1329 Draft (work in progress), July 2007. 1331 24 Savola, P, Haberman, B. "Embedding the Rendezvous Point (RP) 1332 Address in an IPv6 Multicast Address", RFC 3956, November 2004. 1334 25 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - 1335 Analysis of Handover Performance and Its Implications on IPv6 and 1336 Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123- 1337 142, November 2005. 1339 26 Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On 1340 the Evolution of Multicast States under Mobility and an Adaptive 1341 Routing Scheme for Mobile SSM Sources", Telecommunication Systems, 1342 Vol. 33, No. 1-3, pp. 131-154, December 2006. 1344 27 Diot, C. et al. "Deployment Issues for the IP Multicast Service 1345 and Architecture", IEEE Network Magazine, spec. issue on 1346 Multicasting 14(1), pp. 78-88, 2000. 1348 28 Eubanks, M. http://multicasttech.com/status/, 2008. 1350 29 Garyfalos, A, Almeroth, K. and Sanzgiri, K. "Deployment Complexity 1351 Versus Performance Efficiency in Mobile Multicast", Intern. 1352 Workshop on Broadband Wireless Multimedia: Algorithms, 1353 Architectures and Applications (BroadWiM), San Jose, California, 1354 USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM- 1355 04.pdf.gz 1357 30 Garyfalos, A, Almeroth, K. "A Flexible Overlay Architecture for 1358 Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm, 23 1359 (11), pp. 2194-2205, November 2005. 1361 31 "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of 1362 Specifications for Phase 1", ETSI TS 102 468; 1364 32 ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast 1365 over DVB-H: Implementation Guidelines for Mobility)", European 1366 Standard (Telecommunications series), November 2004. 1368 33 Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- 1369 Based Approach", Telecommunication Systems 17(3), 281-297, 2001. 1370 Presented at the INET'98, Geneva, Switzerland, July 1998. 1372 34 Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of 1373 Multicast", IEEE/ACM Trans. Netw., 9, 6, pp. 719-732, Dec. 2001. 1375 35 Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast 1376 trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003. 1378 36 Janic, M. and Van Mieghem, P. "On properties of multicast routing 1379 trees", Int. J. Commun. Syst. 19(1), pp. 95-114, Feb. 2006. 1381 37 Van Mieghem, P. "Performance Analysis of Communication Networks 1382 and Systems", Cambridge University Press, 2006. 1384 38 Fenner, B, He, H, Haberman, B, Sandick, H. "Internet Group 1385 Management Protocol (IGMP) / Multicast Listener Discovery (MLD)- 1386 Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, 1387 August 2006. 1389 39 Shin, M. et al. "IPv6 Deployment Scenarios in 802.16 Networks", 1390 RFC 5181, May 2008. 1392 40 Patil, B. et al. "Transmission of IPv6 via the IPv6 Convergence 1393 Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. 1395 41 Jeon, H., Riegel, M. and Jeong, S. "Transmission of IP over 1396 Ethernet over IEEE 802.16 Networks ", draft-ietf-16ng-ip-over- 1397 ethernet-over-802.16-08.txt, (work in progress), January 2009. 1399 42 Kim, S. et al. "Multicast Transport on IEEE 802.16 Networks", 1400 draft-sekim-802-16-multicast-01, (work in progress, expired), July 1401 2007. 1403 43 IEEE 802.16e-2005: IEEE Standard for Local and metropolitan area 1404 networks Part 16: "Air Interface for Fixed and Mobile Broadband 1405 Wireless Access Systems Amendment for Physical and Medium Access 1406 Control Layers for Combined Fixed and Mobile Operation in Licensed 1407 Bands.", New York, February 2006. 1409 44 3rd Generation Partnership Project; Technical Specification Group 1410 Services and System Aspects; "IP Multimedia Subsystem (IMS)"; 1411 Stage 2, 3GPP TS 23.228, Rel. 5 ff, 2002 - 2007. 1413 45 Wasserman, M. "Recommendations for IPv6 in Third Generation 1414 Partnership Project (3GPP) Standards", RFC 3314, September 2002. 1416 46 Chen, X, Rinne, J. and Wiljakka, J. "Problem Statement for MIPv6 1417 Interactions with GPRS/UMTS Packet Filtering", draft-chen-mip6- 1418 gprs-07.txt, (work in progress, expired), January 2007. 1420 47 3GPP2, www.3gpp2.org, 1421 "X.S0022-A, Broadcast and Multicast Service in cdma2000 Wireless 1422 IP Network, Rev. A.", 1423 http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007. 1425 48 ETSI EN 302 304, "Digital Video Broadcasting (DVB); Transmission 1426 System for Handheld Terminals (DVB-H)", European Standard 1427 (Telecommunications series), November 2004. 1429 49 Fairhurst, G. and Montpetit, M. "Address Resolution Mechanisms for 1430 IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007. 1432 50 Montpetit, M. et al. "A Framework for Transmission of IP Datagrams 1433 over MPEG-2 Networks", RFC 4259, November 2005. 1435 51 Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in 1436 DVB-H", IEEE Comm. Surveys, 8(4), 2006. 1438 52 Fairhurst, G., and Collini-Nocker, B. "Unidirectional Lightweight 1439 Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG- 1440 2 Transport Stream (TS)", RFC 4326, December 2005. 1442 53 Fairhurst, G., and Collini-Nocker, B. "Extension Formats for 1443 Unidirectional Lightweight Encapsulation (ULE) and the Generic 1444 Stream Encapsulation (GSE)", RFC 5163, April 2008. 1446 54 "Draft IEEE Standard for Local and Metropolitan Area Networks: 1447 Media Independent Handover Services", IEEE LAN/MAN Draft IEEE 1448 P802.21/D07.00, July 2007. 1450 55 Melia, T. et al. "Mobility Services Transport: Problem Statement", 1451 RFC 5164, March 2008. 1453 56 Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three 1454 Approaches Towards Mobile Multicast", IST Mobile Summit 2003, 1455 Aveiro, Portugal, 16-18 June 2003. 1457 57 Suh, K, Kwon, D.-H, Suh, Y.-J. and Park, Y, "Fast Multicast 1458 Protocol for Mobile IPv6 in the fast handovers environments", 1459 Internet Draft - (work in progress, expired), February 2004. 1461 58 Xia, F. and Sarikaya, B, "FMIPv6 extensions for Multicast 1462 Handover", draft-xia-mipshop-fmip-multicast-01, (work in progress, 1463 expired), March 2007. 1465 59 Schmidt, T.C. and Waehlisch, M, "Seamless Multicast Handover in a 1466 Hierarchical Mobile IPv6 Environment(M-HMIPv6)", draft-schmidt- 1467 waehlisch-mhmipv6-04.txt, (work in progress, expired), December 1468 2005. 1470 60 Jonas, K. and Miloucheva, I, "Multicast Context Transfer in mobile 1471 IPv6", draft-miloucheva-mldv2-mipv6-00.txt, (work in progress, 1472 expired), June 2005. 1474 61 Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast 1475 mobility support using fast MIPv6 extensions", Computer Comm. 29, 1476 pp. 3745-3765, 2006. 1478 62 Gundavelli, S, et al. "Proxy Mobile IPv6", RFC 5213, August 2008. 1480 63 Deng, H, Schmidt, T.C., Seite, P., and Yang, P. "Multicast Support 1481 Requirements for Proxy Mobile IPv6", draft-deng-multimob-pmip6- 1482 requirement-01, (work in progress), October 2008. 1484 64 Zhang, H. et al. "Mobile IPv6 Multicast with Dynamic Multicast 1485 Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in 1486 progress, expired), January 2007. 1488 65 Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile Multicast: 1489 Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004. 1491 66 Conta, A, Deering, S, "Generic Packet Tunneling in IPv6 - 1492 Specification", RFC 2473, December 1998. 1494 67 Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On 1495 Deployable, Efficient, Mobility-agnostic Group Communication 1496 Services", Internet Research, 17 (5), pp. 519-534, Emerald 1497 Insight, Bingley, UK, November 2007. 1499 68 Buford, J. "Hybrid Overlay Multicast Framework", draft-irtf-sam- 1500 hybrid-overlay-framework-02.txt, Internet Draft (work in 1501 progress), February 2008. 1503 69 Christensen, M, Kimball, K. and Solensky, F. "Considerations for 1504 Internet Group Management Protocol (IGMP) and Multicast Listener 1505 Discovery (MLD) Snooping Switches", RFC 4541, May 2006. 1507 70 Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks: 1508 Progress and Challenges", IEEE Wirel. Comm, pp 58-64, Oct. 2002. 1510 71 Romdhani, I, Bettahar, H. and Bouabdallah, A. "Transparent 1511 handover for mobile multicast sources", in P. Lorenz and P. Dini, 1512 eds, Proceedings of the IEEE ICN'06, IEEE Press, 2006. 1514 72 Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile 1515 Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002. 1517 73 Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with 1518 Dynamic Tree Adjustment for Mobile IPv6", Journ. Information 1519 Science and Engineering 20, pp. 1109-1124, 2004. 1521 74 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings 1522 of ietf meeting, Dec. 2001. 1523 URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf 1525 75 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6 1526 (MSSMSv6)", Internet Draft (work in progress, expired), January 1527 2002. 1529 76 Handley, M, Perkins, C, Whelan, E. "Session Announcement 1530 Protocol", RFC 2974, October 2000. 1532 77 Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility 1533 Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 1534 2002. 1536 78 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill- 1537 mip-multicast-00.txt, (work in progress, expired), July 2002. 1539 79 Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 - 1540 Problems, Solutions and Improvements", Computational Methods in 1541 Science and Technology 11(2), pp. 147-152. Selected Papers from 1542 TERENA Networking Conference, Poznan, May 2005. 1544 80 Lee, H, Han, S. and Hong, J. "Efficient Mechanism for Source 1545 Mobility in Source Specific Multicast", in K. Kawahara and I. 1546 Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp. 82-91, 1547 Springer-Verlag, Berlin, Heidelberg, 2006. 1549 81 Kellil, M, Romdhani, I, Lach, H.-Y, Bouabdallah, A. and Bettahar, 1550 H. "Multicast Receiver and Sender Access Control and its 1551 Applicability to Mobile IP Environments: A Survey", IEEE Comm. 1552 Surveys & Tutorials 7(2), pp. 46-70, 2005. 1554 82 Castellucia, C, Montenegro, G. "Securing Group Management in IPv6 1555 with Cryptographically Based Addresses", Proc. 8th IEEE Int'l 1556 Symp. Comp. and Commun, Turkey, July 2003, pp. 588-93. 1558 83 Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G. "AuthoCast - 1559 a mobility-compliant protocol framework for multicast sender 1560 authentication", Security and Communication Networks, 1(6), 1561 pp. 495 - 509, 2008. 1563 84 Fenner, B. et al. "Multicast Source Notification of Interest 1564 Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress, 1565 expired), March 2004. 1567 85 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time 1568 Applications", RFC 3550, July 2003. 1570 Acknowledgments 1572 Work on exploring the problem space for mobile multicast has been 1573 pioneered by Greg Daley and Gopi Kurup within their early draft 1574 "Requirements for Mobile Multicast Clients" (draft-daley-magma- 1575 mobile). 1577 Since then, many people have actively discussed the different issues 1578 and contributed to the enhancement of this memo. The authors would 1579 like to thank (in alphabetical order) Kevin C. Almeroth, Cedric 1580 Baudoin, Hans L. Cycon, Hui Deng, Marshall Eubanks, Zhigang Huang, 1581 Christophe Jelger, Rajeev Koodli, Mark Palkow, Craig Partridge, Imed 1582 Romdhani, Hesham Soliman, Dave Thaler and last, but not least, very 1583 special thanks to Stig Venaas for his frequent and thorough advice. 1585 Author's Addresses 1587 Thomas C. Schmidt 1588 Hamburg University of Applied Sciences, 1589 Dept. Informatik 1590 Berliner Tor 7 1591 D-20099 Hamburg, Germany 1592 Phone: +49-40-42875-8157 1593 Email: Schmidt@informatik.haw-hamburg.de 1595 Matthias Waehlisch 1596 link-lab 1597 Hoenower Str. 35 1598 D-10318 Berlin, Germany 1599 Email: mw@link-lab.net 1601 Godred Fairhurst 1602 School of Engineering, 1603 University of Aberdeen, 1604 Aberdeen, AB24 3UE, UK 1605 EMail: gorry@erg.abdn.ac.uk