idnits 2.17.1 draft-irtf-mobopts-mmcastv6-ps-09.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 (October 20, 2009) is 5295 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 246 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 914 looks like a reference -- Missing reference section? '6' on line 268 looks like a reference -- Missing reference section? '65' on line 966 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 247 looks like a reference -- Missing reference section? '10' on line 247 looks like a reference -- Missing reference section? '11' on line 249 looks like a reference -- Missing reference section? '12' on line 250 looks like a reference -- Missing reference section? '13' on line 250 looks like a reference -- Missing reference section? '14' on line 250 looks like a reference -- Missing reference section? '15' on line 251 looks like a reference -- Missing reference section? '16' on line 252 looks like a reference -- Missing reference section? '17' on line 1015 looks like a reference -- Missing reference section? '18' on line 268 looks like a reference -- Missing reference section? '19' on line 935 looks like a reference -- Missing reference section? '20' on line 936 looks like a reference -- Missing reference section? '21' on line 269 looks like a reference -- Missing reference section? '22' on line 270 looks like a reference -- Missing reference section? '23' on line 270 looks like a reference -- Missing reference section? '62' on line 948 looks like a reference -- Missing reference section? '24' on line 492 looks like a reference -- Missing reference section? '25' on line 937 looks like a reference -- Missing reference section? '26' on line 615 looks like a reference -- Missing reference section? '27' on line 551 looks like a reference -- Missing reference section? '28' on line 554 looks like a reference -- Missing reference section? '29' on line 558 looks like a reference -- Missing reference section? '30' on line 1001 looks like a reference -- Missing reference section? '31' on line 816 looks like a reference -- Missing reference section? '32' on line 573 looks like a reference -- Missing reference section? '33' on line 583 looks like a reference -- Missing reference section? '34' on line 594 looks like a reference -- Missing reference section? '35' on line 592 looks like a reference -- Missing reference section? '36' on line 597 looks like a reference -- Missing reference section? '37' on line 600 looks like a reference -- Missing reference section? '70' on line 1018 looks like a reference -- Missing reference section? '38' on line 656 looks like a reference -- Missing reference section? '39' on line 720 looks like a reference -- Missing reference section? '40' on line 722 looks like a reference -- Missing reference section? '41' on line 723 looks like a reference -- Missing reference section? '42' on line 732 looks like a reference -- Missing reference section? '43' on line 734 looks like a reference -- Missing reference section? '44' on line 770 looks like a reference -- Missing reference section? '45' on line 776 looks like a reference -- Missing reference section? '46' on line 797 looks like a reference -- Missing reference section? '47' on line 809 looks like a reference -- Missing reference section? '48' on line 847 looks like a reference -- Missing reference section? '49' on line 846 looks like a reference -- Missing reference section? '50' on line 824 looks like a reference -- Missing reference section? '51' on line 839 looks like a reference -- Missing reference section? '52' on line 841 looks like a reference -- Missing reference section? '53' on line 864 looks like a reference -- Missing reference section? '54' on line 867 looks like a reference -- Missing reference section? '55' on line 867 looks like a reference -- Missing reference section? '56' on line 919 looks like a reference -- Missing reference section? '57' on line 935 looks like a reference -- Missing reference section? '58' on line 935 looks like a reference -- Missing reference section? '59' on line 1074 looks like a reference -- Missing reference section? '60' on line 937 looks like a reference -- Missing reference section? '61' on line 937 looks like a reference -- Missing reference section? '63' on line 958 looks like a reference -- Missing reference section? '64' on line 965 looks like a reference -- Missing reference section? '66' on line 974 looks like a reference -- Missing reference section? '67' on line 1005 looks like a reference -- Missing reference section? '68' on line 1009 looks like a reference -- Missing reference section? '69' on line 1010 looks like a reference -- Missing reference section? '71' on line 1046 looks like a reference -- Missing reference section? '72' on line 1093 looks like a reference -- Missing reference section? '73' on line 1077 looks like a reference -- Missing reference section? '74' on line 1085 looks like a reference -- Missing reference section? '75' on line 1102 looks like a reference -- Missing reference section? '76' on line 1109 looks like a reference -- Missing reference section? '77' on line 1112 looks like a reference -- Missing reference section? '78' on line 1120 looks like a reference -- Missing reference section? '79' on line 1121 looks like a reference -- Missing reference section? '80' on line 1126 looks like a reference -- Missing reference section? '81' on line 1251 looks like a reference -- Missing reference section? '82' on line 1132 looks like a reference -- Missing reference section? '83' on line 1142 looks like a reference -- Missing reference section? '84' on line 1180 looks like a reference -- Missing reference section? '85' on line 1181 looks like a reference -- Missing reference section? '86' on line 1181 looks like a reference -- Missing reference section? '87' on line 1243 looks like a reference -- Missing reference section? '88' on line 1250 looks like a reference Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 90 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: April 22, 2010 link-lab 6 Godred Fairhurst 7 University of Aberdeen 8 October 20, 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 April 22, 2010. 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.........................................14 82 4.2 Multicast for Specific Technologies........................14 83 4.2.1 802.11 WLAN..........................................15 84 4.2.2 802.16 WIMAX.........................................15 85 4.2.3 3GPP/3GPP2...........................................17 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.............23 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 References.......................................................27 111 Acknowledgments..................................................34 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 led 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 - A Mobile Node (MN) Directly 237 attaching to Fixed Access Routers (AR) or attached via Local Access 238 Routers (LAR) 240 2. Problem Description 242 2.1 General Issues 244 Multicast mobility is a generic term, which subsumes a collection of 245 distinct functions. First, multicast communication is divided into 246 Any Source Multicast (ASM) [2] and Source Specific Multicast (SSM) 247 [9,10]. Second, the roles of senders and receivers are distinct and 248 asymmetric. Both may individually be mobile. Their interaction is 249 facilitated by a multicast routing protocol such as DVMRP [11], PIM- 250 SM/SSM [12,13], Bi-directional PIM [14], or inter-domain multicast 251 prefix advertisements via MBGP [15]. IPv6 clients interact using the 252 multicast listener discovery protocol (MLD and MLDv2) [16,17]. 254 Any solution for multicast mobility needs to take all of these 255 functional blocks into account. It should enable seamless continuity 256 of multicast sessions when moving from one IPv6 subnet to another. It 257 is desired to preserve the multicast nature of packet distribution 258 and approximate optimal routing. It should support per-flow handover 259 for multicast traffic, because the properties and designations of 260 flows can be distinct. Such distinctions may result from differing 261 QoS/real-time requirements, but may also be caused by network 262 conditions that may differ for different groups. 264 The host group model extends the capability of the network layer 265 unicast service. In common with the architecture of fixed networks, 266 multicast mobility management should transparently utilize or 267 smoothly extend the unicast functions of MIPv6 [5], its security 268 extensions [6,18], its expediting schemes FMIPv6 [19] and HMIPv6 269 [20], its context transfer protocols [21], its multihoming 270 capabilities [22,23], emerging protocols like PMIPv6 [62] or future 271 developments. From the perspective of an integrated mobility 272 architecture, it is desirable to avoid multicast-specific as well as 273 unicast-restricted solutions, whenever general approaches can be 274 derived that can jointly support unicast and multicast. 276 Multicast routing dynamically adapts to the network topology at the 277 locations of the sender(s) and receiver(s) participating in a 278 multicast session, which then may change under mobility. However, 279 depending on the topology and the protocol in use, current multicast 280 routing protocols may require a time close to seconds to converge 281 following a change in receiver or sender location. This is far too 282 slow to support seamless handovers for interactive or real-time media 283 sessions. The actual temporal behavior strongly depends on the 284 multicast routing protocol in use, the configuration of routers, and 285 on the geometry of the current distribution tree. A mobility scheme 286 that re-adjusts routing, i.e., partially changes or fully 287 reconstructs a multicast tree, is forced to comply with the time 288 scale for protocol convergence. Specifically, it needs to consider a 289 possible rapid movement of the mobile node, as this may occur at much 290 higher rates than common protocol state updates. 292 The mobility of hosts using IP multicast can impact the service 293 presented to the higher-layer protocols. IP layer multicast packet 294 distribution is an unreliable service that is bound to connectionless 295 transport protocols. Where applications are sensitive to packet loss 296 or jitter, countermeasures need to be performed (loss recovery, 297 content recoding, concealment, etc) by the multicast transport or 298 application. Mobile multicast handovers should not introduce 299 significant additional packet drops. Due to statelessness, the bi- 300 casting of multicast flows does not cause degradations at the 301 transport layer, and applications should implement mechanisms to 302 detect and correctly respond to duplicate datagrams. Nevertheless, 303 individual application programs may not be robust with respect to 304 repeated reception of duplicate streams. 306 IP multicast applications can be designed to adapt the multicast 307 stream to prevailing network conditions (adapting the sending rate to 308 the level of congestion, adaptive tuning of clients in response to 309 measured delay, dynamic suppression of feedback messages, etc). An 310 adaptive application may also use more than one multicast group 311 (e.g., layered multicast in which a client selects a set of multicast 312 groups based on perceived available network capacity). A mobility 313 handover may temporarily disrupt the operation of these higher-layer 314 functions. The handover can invalidate assumptions about the 315 forwarding path (e.g., acceptable delivery rate, round trip delay), 316 which could impact an application and level of network traffic. Such 317 effects need to be considered in the design of multicast applications 318 and in the design of network-layer mobility. Specifically, mobility 319 mechanisms need to be robust to transient packet loss that may result 320 from invalid path expectations following a handover of an MN to a 321 different network. 323 Group addresses in general are location transparent, even though they 324 may be scoped and methods can embed unicast prefixes or Rendezvous 325 Point addresses [24]. The addresses of sources contributing to a 326 multicast session are interpreted by the routing infrastructure and 327 by receiver applications, which frequently are aware of source 328 addresses. Multicast therefore inherits the mobility address duality 329 problem of MIPv6 for source addresses: Addresses being a logical node 330 identifier, i.e., the home address (HoA) on the one hand, and a 331 topological locator, the care-of-address (CoA), on the other. At the 332 network layer, the elements that comprise the delivery tree, i.e., 333 multicast senders, forwarders and receivers, need to carefully 334 account for address duality issues, e.g., by using binding caches, 335 extended multicast states or signaling. 337 Multicast sources in general operate decoupled from their receivers 338 in the following sense: A multicast source sends packets to a group 339 of receivers that are unknown at the network layer, and thus operates 340 without a feedback channel. It neither has means to inquire about the 341 properties of its delivery trees, nor is it able to learn about the 342 network-layer state of its receivers. In the event of an inter-tree 343 handover, a mobile multicast source therefore is vulnerable to losing 344 connectivity to receivers without noticing. (Appendix A describes 345 implicit source notification approaches). Applying a MIPv6 mobility 346 binding update or return routability procedure will similarly break 347 the semantic of a receiver group remaining unidentified by the source 348 and thus cannot be applied in unicast analogy. 350 Despite the complexity of the requirements, multicast mobility 351 management should seek lightweight solutions with easy deployment. 352 Realistic, sample deployment scenarios and architectures should be 353 provided in future solution documents. 355 2.2 Multicast Listener Mobility 357 2.2.1 Node & Application Perspective 359 A mobile multicast listener entering a new IP subnet requires 360 multicast reception following a handover in real-time. This needs to 361 transfer the multicast membership context from its old to its new 362 point of attachment. This can either be achieved by (re-) 363 establishing a tunnel or by transferring the MLD Listening State 364 information of the MN's moving interface(s) to the new upstream 365 router(s). In the latter case, it may encounter either one of the 366 following conditions: 367 o In the simplest scenario, packets of some, or all, of the 368 subscribed groups of the mobile node are already received by one 369 or several other group members in the new network, and thus 370 multicast streams natively flow after the MN arrives at the new 371 network. 372 o The requested multicast service may be supported and enabled in 373 the visited network, but the multicast groups under subscription 374 may not be forwarded to it, e.g., groups may be scoped or 375 administratively prohibited. This means that current distribution 376 trees for the desired groups may only be re-joined at a (possibly 377 large) routing distance. 378 o The new network may not be multicast-enabled or the specific 379 multicast service may be unavailable, e.g., unsupported or 380 prohibited. This means that current distribution trees for the 381 desired groups need to be re-joined at a large routing distance 382 by (re) establishing a tunnel to a multicast-enabled network 383 node. 385 The problem of achieving seamless multicast listener handovers is 386 thus threefold: 387 o Ensure multicast reception, even in visited networks, without 388 appropriate multicast support. 389 o Minimize multicast forwarding delay to provide seamless 390 and fast handovers for real-time services. Dependant on layer 2 391 and 3 handover performance, the time available for multicast 392 mobility operations is typically bound the total handover time 393 left after IPv6 connectivity is regained. In real-time scenarios 394 this may be significantly less than 100 ms. 395 o Minimize packet loss and reordering that result from multicast 396 handover management. 398 Moreover, in many wireless regimes it is also desirable to minimize 399 multicast-related signaling to preserve the limited resources of 400 battery powered mobile devices and the constrained transmission 401 capacities of the networks. This may lead to a desire to restrict MLD 402 queries towards the MN. Multihomed MNs may ensure smooth handoffs by 403 using a 'make-before-break' approach, which requires a per interface 404 subscription, facilitated by an MLD JOIN operating on a pre-selected 405 IPv6 interface. 407 Encapsulation on the path between the upstream router and the 408 receiver may result in MTU size conflicts, since path-MTU discovery 409 is often not supported for multicast and can reduce scalability in 410 networks with many different MTU sizes or introduce potential denial 411 of service vulnerabilities (since the originating addresses of ICMPv6 412 messages can not be verified for multicast). In the absence of 413 fragmentation at tunnel entry points, this may prevent the group 414 being forwarded to the destination. 416 2.2.2 Network Perspective 418 The infrastructure providing multicast services is required to keep 419 traffic following the MN without compromising network functionality. 420 Mobility solutions thus have to face some immediate problems: 422 o Realize native multicast forwarding, and where applicable 423 conserve network resources and utilize link layer multipoint 424 distribution to avoid data redundancy. 425 o Activate link multipoint services, even if the MN performs 426 only a layer 2 / vertical handover. 427 o Ensure routing convergence, even when the MN moves rapidly 428 and performs handovers at a high frequency. 430 o Avoid avalanche problems and stream multiplication (n-casting), 431 which potentially result from replicated tunnel initiation or 432 redundant forwarding at network nodes. 434 There are additional implications for the infrastructure: In changing 435 its point of attachment, an exclusive mobile receiver may cause 436 initiation in the new network and termination of a group distribution 437 service in the previous network. Mobility management may impact 438 multicast routing by, e.g., erroneous subscriptions following 439 predictive handover operations, or slow traffic termination at leaf 440 nodes resulting from MLD query timeouts, or by departure of the MN 441 from a previous network without leaving the subscribed groups. 442 Finally, packet duplication and re-ordering may follow a change of 443 topology. 445 2.3 Multicast Source Mobility 447 2.3.1 Any Source Multicast Mobility 449 A node submitting data to an ASM group either forms the root of a 450 source specific shortest path tree (SPT), distributing data towards a 451 rendezvous point (RP) or receivers, or it forwards data directly down 452 a shared tree, e.g., via encapsulated PIM Register messages, or using 453 bi-directional PIM routing. Native forwarding along source specific 454 delivery trees will be bound to the source's topological network 455 address, due to reverse path forwarding (RPF) checks. A mobile 456 multicast source moving to a new subnetwork is only able to either 457 inject data into a previously established delivery tree, which may be 458 a rendezvous point based shared tree, or to (re)initiate the 459 construction of a multicast distribution tree for its new network 460 location. In the latter case, the mobile sender will have to proceed 461 without knowing whether the new tree has regained ability to forward 462 traffic to the group, due to the decoupling of sender and receivers. 464 A mobile multicast source must therefore provide address transparency 465 at two layers: To comply with RPF checks, it has to use an address 466 within the source field of the IPv6 basic header, which is in 467 topological agreement with the employed multicast distribution tree. 468 For application transparency the logical node identifier, commonly 469 the HoA, must be presented as the packet source address to the 470 transport layer at the receiver side. 472 The address transparency and temporal handover constraints pose major 473 problems for route optimizing mobility solutions. Additional issues 474 arise from possible packet loss and from multicast scoping. A mobile 475 source away from home must respect scoping restrictions that arise 476 from its home and its visited location [5]. 478 Intra-domain multicast routing may allow the use of shared trees that 479 can reduce mobility-related complexity. A static rendezvous point may 480 allow a mobile source to continuously send data to the group by 481 encapsulating packets to the RP with its previous topologically 482 correct or home source address. Intra-domain mobility is 483 transparently provided by bi-directional shared domain-spanning 484 trees, when using bi-directional PIM, eliminating the need for 485 tunneling to the corresponding RP (in contrast to IPv4, IPv6 ASM 486 multicast groups are associated with a specific RP/RPs). 488 Issues arise in inter-domain multicast, whenever notification of 489 source addresses is required between distributed instances of shared 490 trees. A new CoA acquired after a mobility handover will necessarily 491 be subject to inter-domain record exchange. In the presence of an 492 embedded rendezvous point address [24], e.g., the primary rendezvous 493 point for inter-domain PIM-SM will be globally appointed, and a newly 494 attached mobile source can contact the RP without prior signaling 495 (like a new source) and transmit data in the PIM register tunnel. 496 Multicast route optimization (e.g., PIM 'shortcuts') will require 497 multicast routing protocol operations equivalent to serving a new 498 source. 500 2.3.2 Source Specific Multicast Mobility 502 Source Specific Multicast has been designed for multicast senders 503 with static source addresses. The source addresses in a client 504 subscription to an SSM group is directly used to route 505 identification. Any SSM subscriber is thus forced to know the 506 topological address of the contributor to the group it wishes to 507 join. The SSM source identification becomes invalid when the 508 topological source address changes under mobility. Hence client 509 implementations of SSM source filtering must be MIPv6 aware in the 510 sense that a logical source identifier (HoA) is correctly mapped to 511 its current topological correspondent (CoA). 513 As a consequence, source mobility for SSM requires a conceptual 514 treatment beyond the problem scope of mobile ASM. A listener 515 subscribes to an (S,G) channel membership and routers establish an 516 (S,G)-state shortest path tree rooted at source S, therefore any 517 change of source addresses under mobility requires state updates at 518 all routers on the upstream path and at all receivers in the group. 519 On source handover, a new SPT needs to be established that will share 520 paths with the previous SPT, e.g., at the receiver side. As the 521 principle of multicast decoupling of a sender from its receivers 522 holds for SSM, the client updates needed for switching trees become a 523 severe burden. 525 An SSM listener may subscribe to or exclude any specific multicast 526 source, and thereby wants to rely on the topological correctness of 527 network operations. The SSM design permits trust in equivalence to 528 the correctness of unicast routing tables. Any SSM mobility solution 529 should preserve this degree of confidence. Binding updates for SSM 530 sources thus should have to prove address correctness in the unicast 531 routing sense, which is equivalent to binding update security with a 532 correspondent node in MIPv6 [5]. 534 The above methods could add significant complexity to a solution for 535 robust SSM mobility, which needs to converge to optimal routes and, 536 for efficiency, is desired to avoid data encapsulation. Like ASM, 537 handover management is a time-critical operation. The routing 538 distance between subsequent points of attachment, the 'step size' of 539 the mobile from previous to next designated router, may serve as an 540 appropriate measure of complexity [25,26]. 542 Finally, Source Specific Multicast has been designed as a light- 543 weight approach to group communication. In adding mobility 544 management, it is desirable to preserve the leanness of SSM by 545 minimizing additional signaling overhead. 547 2.4 Deployment Issues 549 IP multicast deployment in general has been slow over the past 15 550 years, even though all major router vendors and operating systems 551 offer implementations that support multicast [27]. While many 552 (walled) domains or enterprise networks operate point-to-multipoint 553 services, IP multicast roll-out is currently limited in public inter- 554 domain scenarios [28]. A dispute arose on the appropriate layer, 555 where group communication service should reside, and the focus of the 556 research community turned towards application layer multicast. This 557 debate on "efficiency versus deployment complexity" now overlaps the 558 mobile multicast domain [29]. Garyfalos and Almeroth [30] derived 559 from fairly generic principles that when mobility is introduced, the 560 performance gap between IP and application layer multicast widens in 561 different metrics up to a factor of four. 563 Facing deployment complexity, it is desirable that any solution for 564 mobile multicast does not change the routing protocols. Mobility 565 management in such a deployment-friendly scheme should preferably be 566 handled at edge nodes, preserving a mobility-agnostic routing 567 infrastructure. Future research needs to search for such simple, 568 infrastructure transparent solutions, even though there are 569 reasonable doubts, whether this can be achieved in all cases. 571 Nevertheless, multicast services in mobile environments may soon 572 become indispensable, when multimedia distribution services such as 573 DVB-H [31,32] or IPTV develop a strong business case for portable IP- 574 based devices. As IP mobility becomes an important service and as 575 efficient link utilization is of a larger impact in costly radio 576 environments, the evolution of multicast protocols will naturally 577 follow mobility constraints. 579 3. Characteristics of Multicast Routing Trees under Mobility 581 Multicast distribution trees have been studied from a focus of 582 network efficiency. Grounded on empirical observations Chuang and 583 Sirbu [33] proposed a scaling power-law for the total number of links 584 in a multicast shortest path tree with m receivers (proportional to 585 m^k). The authors consistently identified the scale factor to attain 586 the independent constant k = 0.8. The validity of such universal, 587 heavy-tailed distribution suggests that multicast shortest path trees 588 are of self-similar nature with many nodes of small, but few of 589 higher degrees. Trees consequently would be shaped rather tall than 590 wide. 592 Subsequent empirical and analytical work [34,35] debated the 593 applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. 594 [34] proved that the proposed power law cannot hold for an increasing 595 Internet or very large multicast groups, but is indeed applicable for 596 moderate receiver numbers and the current Internet size of N = 10^5 597 core nodes. Investigating self-similarity Janic and Van Mieghem [36] 598 semi-empirically substantiated that multicast shortest path trees in 599 the Internet can be modeled with reasonable accuracy by uniform 600 recursive trees (URT) [37], provided m remains small compared to N. 602 The mobility perspective on shortest path trees focuses on their 603 alteration, i.e., the degree of topological changes induced by 604 movement. For receivers, and more interestingly for sources this may 605 serve as an outer measure for routing complexity. Mobile listeners 606 moving to neighboring networks will only alter tree branches 607 extending over a few hops. Source specific multicast trees 608 subsequently generated from source handover steps are not 609 independent, but highly correlated. They most likely branch to 610 identical receivers at one or several intersection points. By the 611 self-similar nature, the persistent sub-trees (of previous and next 612 distribution tree), rooted at any such intersection point, exhibit 613 again the scaling law behavior, are tall-shaped with nodes of mainly 614 low degree and thus likely to coincide. Tree alterations under 615 mobility have been studied in [26], both analytically and by 616 simulations. It was found that even in large networks and for 617 moderate receiver numbers more than 80 % of the multicast router 618 states remain invariant under a source handover. 620 4. Link Layer Aspects 621 4.1 General Background 623 Scalable group data distribution has the highest potential in edge 624 networks, where large numbers of end systems reside. Consequently, it 625 is not surprising that most LAN network access technologies natively 626 support point-to-multipoint or multicast services. Wireless access 627 technologies inherently support broadcast/multicast at L2 and operate 628 on a shared medium 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 [70] 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 669 4.2.1 802.11 WLAN 671 IEEE 802.11 WLAN is a broadcast network of Ethernet type. This 672 inherits multicast address mapping concepts from 802.3. In 673 infrastructure mode, an access point operates as a repeater, only 674 bridging data between the Base (BSS) and the Extended Service Set 675 (ESS). A mobile node submits multicast data to an access point in 676 point-to-point acknowledged unicast mode (when the ToDS bit is set). 677 An access point receiving multicast data from a MN simply repeats 678 multicast frames to the BSS and propagates them to the ESS as 679 unacknowledged broadcast. Multicast frames received from the ESS 680 receive similar treatment. 682 Multicast frame delivery has the following characteristics: 684 o As an unacknowledged service it offers limited reliability. 685 Frames (and hence packet) loss arise from interference, 686 collision, or time-varying channel properties. 688 o Data distribution may be delayed, as unicast power saving 689 synchronization via Traffic Indication Messages (TIM) does not 690 operate in multicast mode. Access points buffer multicast packets 691 while waiting for a larger DTIM interval, whenever stations use 692 the power saving mode. 694 o Multipoint data may cause congestion, because the distribution 695 system floods multicast, without further control. All access 696 points of the same subnet replicate multicast frames. 698 To limit or prevent the latter, many vendors have implemented a 699 configurable rate limit for forwarding multicast packets. 700 Additionally, an IGMP/MLD snooping or proxy may be active at the 701 bridging layer between the BSS and the ESS or at switches 702 interconnecting access points. 704 4.2.2 802.16 WIMAX 706 IEEE 802.16 WIMAX combines a family of connection-oriented radio 707 transmission services that can operate in single-hop point-to- 708 multipoint (PMP) or in mesh mode. The latter does not support 709 multipoint transmission and currently has no deployment. PMP operates 710 between Base and Subscriber Stations in distinguished, unidirectional 711 channels. The channel assignment is controlled by the Base Station, 712 which assigns channel IDs (CIDs) within service flows to the 713 Subscriber Stations. Service flows may provide an optional Automatic 714 Repeat Request (ARQ) to improve reliability and may operate in point- 715 to-point or point-to-multipoint (restricted to downlink and without 716 ARQ) mode. 718 A WIMAX Base Station operates as a full-duplex L2 switch, with 719 switching based on CIDs. Two IPv6 link models for mobile access 720 scenarios exist: A shared IPv6 prefix for IP over Ethernet CS [39] 721 provides MAC separation within a shared prefix. A second, point-to- 722 point link model [40] is recommended in the IPv6 Convergence Sublayer 723 [41], which treats each connection to a mobile node as a single link. 724 The point-to-point link model conflicts with a consistent group 725 distribution at the IP layer when using a shared medium (cf. section 726 4.1 for MVR as a workaround). 728 To invoke a multipoint data channel, the base station assigns a 729 common CID to all Subscriber Stations in the group. An IPv6 multicast 730 address mapping to these 16 bit IDs is proposed by copying either the 731 4 lowest bits, while sustaining the scope field, or by utilizing the 732 8 lowest bits derived from Multicast on Ethernet CS [42]. For 733 selecting group members, a Base Station may implement IGMP/MLD 734 snooping or proxy as foreseen in 802.16e-2005 [43]. 736 A Subscriber Station multicasts IP packets to a Base Station as a 737 point-to-point unicast stream. When the IPv6 CS is used, these are 738 forwarded to the upstream access router. The access router (or the 739 Base Station for IP over Ethernet CS) may send downstream multicast 740 packets by feeding them to the multicast service channel. On 741 reception, a Subscriber Station cannot distinguish multicast from 742 unicast streams at the link layer. 744 Multicast services have the following characteristics: 746 o Multicast CIDs are unidirectional and available only in the 747 downlink direction. Thus a native broadcast-type forwarding model 748 is not available. 750 o The mapping of multicast addresses to CIDs needs standardization, 751 since different entities (Access Router, Base Station) may have 752 to perform the mapping. 754 o CID collisions for different multicast groups may occur due 755 to the short ID space. This can result in several point-to- 756 multipoint groups sharing the same CID, reducing the ability of 757 a receiver to filter unwanted L2 traffic. 759 o The point-to-point link model for mobile access contradicts a 760 consistent mapping of IP layer multicast onto 802.16 761 point-to-multipoint services. 763 o Multipoint channels cannot operate ARQ service and thus 764 experience a reduced reliability. 766 4.2.3 3GPP/3GPP2 768 The 3GPP System architecture spans a circuit switched (CS) and a 769 packet switched (PS) domain, the latter General Packet Radio Services 770 (GPRS) incorporates the IP Multimedia Subsystem (IMS) [44]. The 3GPP 771 PS is connection-oriented and based on the concept of Packet Data 772 Protocol (PDP) Contexts. PDPs define point-to-point links between the 773 Mobile Terminal and the Gateway GPRS Support Node (GGSN). Internet 774 service types are PPP, IPv4 and IPv6, where the recommendation for 775 IPv6 address assignment associates a prefix to each (primary) PDP 776 context [45]. 778 In UMTS Rel. 6 the IMS was extended to include Multimedia Broadcast 779 and Multicast Services (MBMS). A point-to-multipoint GPRS connection 780 service is operated on radio links, while the gateway service to 781 Internet multicast is handled at the IGMP/MLD-aware GGSN. Local 782 multicast packet distribution is used within the GPRS IP backbone 783 resulting in the common double encapsulation at GGSN: global IP 784 multicast datagrams over GTP (with multipoint TID) over local IP 785 multicast. 787 The 3GPP MBMS has the following characteristics: 789 o There is no immediate layer 2 source-to-destination transition, 790 resulting in transit of all multicast traffic at the GGSN. 792 o As GGSN commonly are regional, distant entities, triangular 793 routing and encapsulation may cause a significant degradation of 794 efficiency. 796 In 3GPP2, the MBMS has been extended to the Broadcast and Multicast 797 Service (BCMCS) [46], which on the routing layer operates very 798 similar to MBMS. In both 3GPP and 3GPP2 multicast can either be sent 799 using point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and 800 there is support for switching between PTP and PTM. PTM uses an 801 unidirectional common channel, operating in unacknowledged mode 802 without adjustment of power levels and no reporting on lost packets. 804 4.2.4 DVB-H / DVB-IPDC 806 Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional 807 physical layer broadcasting specification for the efficient delivery 808 of broadband, IP-encapsulated data streams, and published as an ETSI 809 standard [47] (see http://www.dvb-h.org). This uses multi-protocol 810 encapsulation (MPE) to transport IP packets over an MPEG-2 Transport 811 Stream (TS) with link forward error correction (FEC). Each stream is 812 identified by a 13 bit TS ID (PID), which together with a multiplex 813 service ID, is associated with IPv4 or IPv6 addresses [48] and used 814 for selective traffic filtering at receivers. Upstream channels may 815 complement DVB-H using other transmission technologies. The IP 816 Datacast Service, DVB-IPDC [31] specifies a set of applications that 817 can use the DVB-H transmission network. 819 Multicast distribution services are defined by a mapping of groups 820 onto appropriate PIDs, which is managed at the IP Encapsulator [49]. 821 To increase flexibility and avoid collisions, this address resolution 822 is facilitated by dynamic tables, provided within the self-contained 823 MPEG-2 TS. Mobility is supported in the sense that changes of cell 824 ID, network ID or Transport Stream ID are foreseen [50]. A multicast 825 receiver thus needs to re-locate the multicast services it is 826 subscribed to, which is to be done in the synchronization phase, and 827 update its service filters. Its handover decision may depend on 828 service availability. An active service subscription (multicast join) 829 requires initiation at the IP Encapsulator / DVB-H Gateway, which 830 cannot be signaled in a pure DVB-H network. 832 4.2.5 TV Broadcast and Satellite Networks 834 IP multicast may be enabled in TV broadcast networks, including those 835 specified by DVB, ATSC, and related standards [49]. These standards 836 are also used for one and two-way satellite IP services. Networks 837 based on the MPEG-2 Transport Stream may support either the multi- 838 protocol encapsulation (MPE) or the unidirectional lightweight 839 encapsulation (ULE) [51]. The second generation DVB standards allow 840 the Transport Stream to be replaced with a Generic Stream, using the 841 generic stream encapsulation (GSE) [52]. These encapsulation formats 842 all support multicast operation. 844 In MPEG-2 transmission networks, multicast distribution services are 845 defined by a mapping of groups onto appropriate PIDs, which is 846 managed at the IP Encapsulator [49]. The addressing issues resemble 847 those for DVB-H (section 4.2.4) [48]. The issues for using GSE 848 resemble those for ULE (except the PID is not available as a 849 mechanism for filtering traffic). Networks that provide bidirectional 850 connectivity may allow active service subscription (multicast join) 851 to initiate forwarding from the upstream IP Encapsulator / gateway. 852 Some kind of filtering can be achieved using the Input Stream 853 Identifier (ISI) field. 855 4.3 Vertical Multicast Handovers 857 A mobile multicast node may change its point of layer 2 attachment 858 within homogeneous access technologies (horizontal handover) or 859 between heterogeneous links (vertical handover). In either case, a 860 layer 3 network change may or may not take place, but multicast-aware 861 links always need information about group traffic demands. 862 Consequently, a dedicated context transfer of multicast subscriptions 863 is required at the network access. Such Media Independent Handover 864 (MIH) is addressed in IEEE 802.21 [53], but is relevant also beyond 865 IEEE protocols. Mobility services transport for MIH are required as 866 an abstraction for layer 2 multicast service transfer in an Internet 867 context [54] and are specified in [55]. 869 MIH needs to assist in more than service discovery: There is a need 870 for complex, media dependent multicast adaptation, a possible absence 871 of MLD signaling in L2-only transfers, and requirements originating 872 from predictive handovers, a multicast mobility services transport 873 needs to be sufficiently comprehensive and abstract to initiate a 874 seamless multicast handoff at network access. 876 Functions required for MIH include: 878 o Service discovery. 879 o Service context transformation. 880 o Service context transfer. 881 o Service invocation. 883 5. Solutions 885 5.1 General Approaches 887 Three approaches to mobile multicast are common [56]: 889 o Bi-directional Tunneling, in which the mobile node tunnels all 890 multicast data via its home agent. This fundamental multicast 891 solution hides all movement and results in static multicast 892 trees. It may be employed transparently by mobile multicast 893 listeners and sources, at the cost of triangular routing and 894 possibly significant performance degradation from widely spanned 895 data tunnels. 897 o Remote Subscription forces the mobile node to re-initiate 898 multicast distribution following handover, e.g., by submitting an 899 MLD listener report to the subnet where a receiver attaches. This 900 approach of tree discontinuation relies on multicast dynamics to 901 adapt to network changes. It not only results in significant 902 service disruption, but leads to mobility-driven changes of 903 source addresses, and thus cannot support session persistence 904 under multicast source mobility. 906 o Agent-based solutions attempt to balance between the previous two 907 mechanisms. Static agents typically act as local tunneling 908 proxies, allowing for some inter-agent handover when the mobile 909 node moves. A decelerated inter-tree handover, i.e. 'tree 910 walking', will be the outcome of agent-based multicast mobility, 911 where some extra effort is needed to sustain session persistence 912 through address transparency of mobile sources. 914 MIPv6 [5] introduces bi-directional tunneling as well as remote 915 subscription as minimal standard solutions. Various publications 916 suggest utilizing remote subscription for listener mobility only, 917 while advising bi-directional tunneling as the solution for source 918 mobility. Such an approach avoids the 'tunnel convergence' or 919 'avalanche' problem [56], which refers to the responsibility of the 920 home agent to multiply and encapsulate packets for many receivers of 921 the same group, even if they are located within the same subnetwork. 922 However, this suffers from the drawback that multicast communication 923 roles are not explicitly known at the network layer and may change 924 unexpectedly. 926 None of the above approaches address SSM source mobility, except the 927 use of bi-directional tunneling. 929 5.2 Solutions for Multicast Listener Mobility 931 5.2.1 Agent Assistance 933 There are proposals for agent-assisted handover for host-based 934 mobility, which complement the unicast real-time mobility 935 infrastructure of Fast MIPv6 [19], the M-FMIPv6 [57,58], and of 936 Hierarchical MIPv6 [20], the M-HMIPv6 [59], and to context transfer 937 [60], which have been thoroughly analyzed in [25,61]. 939 All these solutions presume the context state was stored within a 940 network node that is reachable before and after a move. But there 941 could be cases were the MN is no longer in contact with the previous 942 network, when at the new location. In this case, the network itself 943 cannot assist in the context transfer. Such scenarios may occur when 944 moving from one (walled) operator to another and will require a 945 backwards compatible way to recover from loss of connectivity and 946 context based on the node alone. 948 Network based mobility management, PMIPv6 [62], is multicast 949 transparent in the sense that the MN experiences a point-to-point 950 home link fixed at its (static) Local Mobility Anchor (LMA). This 951 virtual home link is composed of a unicast tunnel between the LMA and 952 the current Mobile Access Gateway (MAG), and a point-to-point link 953 connecting the current MAG to the MN. A PMIPv6 domain thereby 954 inherits MTU-size problems from spanning tunnels at the receiver 955 site. Furthermore, two avalanche problem points can be identified: 956 The LMA may be required to tunnel data to a large number of MAGs, 957 while a MAG may be required to forward the same multicast stream to 958 many MNs via individual point-to-point links [63]. Future 959 optimizations and extensions to shared links preferably adapt native 960 multicast distribution towards the edge network, possibly using a 961 local routing option, including context transfer between access 962 gateways to assist IP-mobility-agnostic MNs. 964 An approach based on dynamically negotiated inter-agent handovers is 965 presented in [64]. Aside from IETF work, numerous publications 966 present proposals for seamless multicast listener mobility, e.g. [65] 967 provides a comprehensive overview of the work prior to 2004. 969 5.2.2 Multicast Encapsulation 971 Encapsulation of multicast data packets is an established method to 972 shield mobility and to enable access to remotely located data 973 services, e.g., streams from the home network. Applying generic 974 packet tunneling in IPv6 [66] using a unicast point-to-point method 975 will also allow multicast-agnostic domains to be transited, but does 976 inherit the tunnel convergence problem and may result in traffic 977 multiplication. 979 Multicast enabled environments may take advantage of point-to- 980 multipoint encapsulation, i.e., generic packet tunneling using an 981 appropriate multicast destination address in the outer header. Such 982 multicast-in-multicast encapsulated packets similarly enable 983 reception of remotely located streams, but do not suffer from the 984 scaling overhead from using unicast tunnels. 986 The tunnel entry point performing encapsulation should provide 987 fragmentation of data packets to avoid issues resulting from MTU size 988 constraints within the network(s) supporting the tunnel(s). 990 5.2.3 Hybrid Architectures 992 There has been recent interest in seeking method that avoid the 993 complexity at the Internet core network, e.g. application layer and 994 overlay proposals for (mobile) multicast. The possibility of 995 integrating multicast distribution on the overlay into the network 996 layer is also being considered by the IRTF Scalable Adaptive 997 Multicast (SAM) Research Group. 999 An early hybrid architecture using reactively operating proxy- 1000 gateways located at the Internet edges was introduced by Garyfalos 1001 and Almeroth [30]. The authors presented an Intelligent Gateway 1002 Multicast as a bridge between mobility-aware native multicast 1003 management in access networks and mobility group distribution 1004 services in the Internet core, which may be operated on the network 1005 or application layer. The Hybrid Shared Tree approach [67] introduced 1006 a mobility-agnostic multicast backbone on the overlay. 1008 Current work in the SAM RG is developing general architectural 1009 approaches for hybrid multicast solutions [68] and a common multicast 1010 API for a transparent access of hybrid multicast [69] that will 1011 require a detailed design in future work. 1013 5.2.4 MLD Extensions 1015 The default timer values specified in MLD [17] were not designed for 1016 the mobility context. This results in a slow reaction of the 1017 multicast routing infrastructure (including layer-3-aware access 1018 devices [70]) following a client leave. This may be a disadvantage 1019 for wireless links, where performance may be improved by carefully 1020 tuning the Query Interval. Some vendors have optimized performance by 1021 implementing a listener node table at the access router that can 1022 eliminate the need for query timeouts when receiving leave messages 1023 (explicit receiver tracking). 1025 A MN operating predictive handover, e.g., using FMIPv6, may 1026 accelerate multicast service termination when leaving the previous 1027 network by submitting an early Done message before handoff. MLD 1028 router querying will allow the multicast forwarding state to be 1029 restored in case of an erroneous prediction (i.e., an anticipated 1030 move to a network that has not taken place). Backward context 1031 transfer may otherwise ensure a leave is signaled. A further 1032 optimization was introduced by Jelger and Noel [71] for the special 1033 case when the HA is a multicast router. A Done message received 1034 through a tunnel from the mobile end node (through a point-to-point 1035 link directly connecting the MN, in general), should not initiate 1036 standard MLD membership queries (with a subsequent timeout). Such 1037 explicit treatment of point-to-point links will reduce traffic and 1038 accelerate the control protocol. Explicit tracking will cause 1039 identical protocol behavior. 1041 While away from home, a MN may wish to rely on a proxy or 'standby' 1042 multicast membership service, optionally provided by a HA or proxy 1043 router. Such functions rely on the ability to restart fast packet 1044 forwarding; it may be desirable for the proxy router to remain part 1045 of the multicast delivery tree, even when transmission of group data 1046 is paused. To enable such proxy control, the authors in [71] propose 1047 an extension to MLD, introducing a Listener Hold message that is 1048 exchanged between the MN and the HA. This idea was developed in [59] 1049 to propose multicast router attendance control, allowing for a 1050 general deployment of group membership proxies. Some currently 1051 deployed IPTV solutions use such a mechanism in combination with a 1052 recent (video) frame buffer, to enable fast channel switching between 1053 several IPTV multicast flows (zapping). 1055 5.3 Solutions for Multicast Source Mobility 1056 5.3.1 Any Source Multicast Mobility Approaches 1058 Solutions for multicast source mobility can be divided into three 1059 categories: 1061 o Statically Rooted Distribution Trees. These methods follow a 1062 shared tree approach. Romdhani et al. [72] proposed employing 1063 the Rendezvous Points of PIM-SM as mobility anchors. Mobile 1064 senders tunnel their data to these "Mobility-aware Rendezvous 1065 Points" (MRPs). When restricted to a single domain, this scheme is 1066 equivalent to bi-directional tunneling. Focusing on interdomain 1067 mobile multicast, the authors designed a tunnel- or SSM-based 1068 backbone distribution of packets between MRPs. 1070 o Reconstruction of Distribution Trees. Several authors have 1071 proposed the construction of a completely new distribution tree 1072 after the movement of a mobile source and therefore have to 1073 compensate for the additional routing (tree-building) delay. 1074 M-HMIPv6 [59] tunnels data into a previously established tree 1075 rooted at mobility anchor points to compensate for the routing 1076 delay until a protocol dependent timer expires. The RBMoM 1077 protocol [73] introduces an additional Multicast Agent (MA) that 1078 advertises its service range. A mobile source registers with 1079 the closest MA and tunnels data through it. When moving out of 1080 the previous service range, it will perform MA discovery, a re- 1081 registration and continue data tunneling with a newly established 1082 Multicast Agent in its new current vicinity. 1084 o Tree Modification Schemes. In the case of DVMRP routing, 1085 Chang and Yen [74] propose an algorithm to extend the root of a 1086 given delivery tree for incorporating a new source location in 1087 ASM. The authors rely on a complex additional signaling protocol 1088 to fix DVMRP forwarding states and heal failures in the reverse 1089 path forwarding (RPF) checks. 1091 5.3.2 Source Specific Multicast Mobility Approaches 1093 The shared tree approach of [72] has been extended to support SSM 1094 mobility by introducing the HoA address record to the Mobility-aware 1095 Rendezvous Points. The MRPs operate using extended multicast routing 1096 tables that simultaneously hold the HoA and CoA and thus can 1097 logically identify the appropriate distribution tree. Mobility thus 1098 may re-introduce the concept of rendezvous points to SSM routing. 1100 Approaches for reconstructing SPTs in SSM rely on a client 1101 notification to establish new router state. It also needs to preserve 1102 address transparency for the client. Thaler [75] proposed introducing 1103 a binding cache and providing source address transparency analogous 1104 to MIPv6 unicast communication. Initial session announcements and 1105 changes of source addresses are distributed periodically to clients 1106 via an additional multicast control tree rooted at the home agent. 1107 Source tree handovers are then activated on listener requests. 1109 Jelger and Noel [76] suggest handover improvements employing anchor 1110 points within the source network, supporting continuous data 1111 reception during client initiated handovers. Client updates are 1112 triggered out of band, e.g. by SDR/SAP [77]. Receiver-oriented tree 1113 construction in SSM thus remains unsynchronized with source 1114 handovers. 1116 To address the synchronization problem at the routing layer, several 1117 proposals have focused on direct modification of the distribution 1118 trees. A recursive scheme may use loose unicast source routes with 1119 branch points, based on a multicast Hop-by-Hop protocol. Vida et al 1120 [78] optimized SPT for a moving source on the path between the source 1121 and first branching point. O'Neill [79] suggested a scheme to 1122 overcome RPF check failures that originate from multicast source 1123 address changes with a rendezvous point scenario by introducing 1124 extended routing information, which accompanies data in a Hop-by-Hop 1125 option "RPF redirect" header. The Tree Morphing approach of Schmidt 1126 and Waehlisch [80] used source routing to extend the root of a 1127 previously established SPT, thereby injecting router state updates in 1128 a Hop-by-Hop option header. Using extended RPF checks the elongated 1129 tree autonomously initiates shortcuts and smoothly reduces to a new 1130 SPT rooted at the relocated source. An enhanced version of this 1131 protocol abandoned the initial source routing and could be proved to 1132 comply with rapid source movement [81]. Lee et al. [82] introduced a 1133 state-update mechanism for re-using major parts of established 1134 multicast trees. The authors start from an initially established 1135 distribution state, centered at the mobile source's home agent. A 1136 mobile leaving its home network will signal a multicast forwarding 1137 state update on the path to its home agent and, subsequently, 1138 distribution states according to the mobile source's new CoA along 1139 the previous distribution tree. Multicast data is then intended to 1140 flow natively using triangular routes via the elongation and an 1141 updated tree centered on the home agent. Based on Host Identity 1142 Protocol identifiers, Kovacshazi and Vida [83] introduce multicast 1143 routing states that remain independent of IP addresses. Drawing upon 1144 a similar scaling law argument, parts of these states may then be re- 1145 used after source address changes. 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 Multicast protocols exhibit a risk of network-based traffic 1157 amplification. For example, an attacker may abuse mobility signaling 1158 to inject unwanted traffic into a previously established multicast 1159 distribution infrastructure. These threats are partially mitigated by 1160 reverse path forwarding checks by multicast routers. However, a 1161 multicast or mobility agent that explicitly replicates multicast 1162 streams, e.g., Home Agent that n-casts data, may be vulnerable to 1163 denial of service attacks. In addition to source authentication, a 1164 rate control of the replicator may be required to protect the agent 1165 and the downstream network. 1167 Mobility protocols need to consider the implications and requirements 1168 for Authentication, Authorization and Accounting (AAA). A MN may have 1169 been authorized to receive a specific multicast group when using one 1170 mobile network, but this may not be valid when attaching to a 1171 different network. In general, the AAA association for an MN may 1172 change between attachments, or may be individually chosen prior to 1173 network (re-)association. The most appropriate network path may be 1174 one that satisfies user preferences, e.g., to use/avoid a specific 1175 network, minimize monetary cost, etc, rather than one that only 1176 minimizes the routing cost. Consequently, AAA bindings may need to be 1177 considered when performing context transfer. 1179 Admission control issues may arise with new CoA source addresses are 1180 introduced to SSM channels [84]. Due to lack of feedback, the 1181 admission [85] and binding updates [86] of mobile multicast sources 1182 require autonomously verifiable authentication. This can be achieved 1183 by, for instance, Cryptographically Generated Addresses (CGAs). 1185 Modification to IETF protocols (e.g. routing, membership, session 1186 announcement and control) as well as the introduction of new 1187 entities, e.g., multicast mobility agents, can introduce security 1188 vulnerabilities and require consideration of issues such as 1189 authentication of network entities, methods to mitigate denial of 1190 service (in terms of unwanted network traffic, unnecessary 1191 consumption of router/host resources and router/host state/buffers). 1192 Future solutions must therefore analyze and address the security 1193 implications of supporting mobile multicast. 1195 7. Summary and Future Steps 1197 This document is intended to provide a basis for the future design of 1198 mobile IPv6 multicast methods and protocols by: 1200 o providing a structured overview of the problem space that 1201 multicast and mobility jointly generate at the IPv6 layer; 1203 o referencing the implications and constraints arising from 1204 lower and upper layers, and from deployment; 1206 o briefly surveying conceptual ideas of currently available 1207 solutions; 1209 o including a comprehensive bibliographic reference base. 1211 It is recommended that future steps towards extending mobility 1212 services to multicast proceed to first solve the following problems: 1214 1. Ensure seamless multicast reception during handovers, 1215 meeting the requirements of mobile IPv6 nodes and networks. 1216 Thereby address the problems of home subscription without 1217 n-tunnels, as well as native multicast reception in those 1218 visited networks, which offer a group communication service. 1220 2. Integrate multicast listener support into unicast mobility 1221 management schemes and architectural entities to define a 1222 consistent mobility service architecture, providing equal 1223 supporting for unicast and multicast communication. 1225 3. Provide basic multicast source mobility by designing 1226 address duality management at end nodes. 1228 8. IANA Considerations 1230 There are no IANA considerations introduced by this draft. 1232 Appendix A. Implicit Source Notification Options 1234 An IP multicast source transmits data to a group of receivers without 1235 requiring any explicit feedback from the group. Sources therefore are 1236 unaware at the network-layer of whether any receivers have subscribed 1237 to the group, and unconditionally send multicast packets which 1238 propagate in the network to the first-hop router (often known in PIM 1239 as the designated router). There have been attempts to implicitly 1240 obtain information about the listening group members, e.g. extending 1241 an IGMP/MLD querier to inform the source of the existence of 1242 subscribed receivers. Multicast Source Notification of Interest 1243 Protocol (MSNIP) [87] was such a suggested method that allowed a 1244 multicast source to querying the upstream designated router. However, 1245 this work did not progress within the IETF mboned working group and 1246 was terminated by IETF. 1248 Multicast sources may also be controlled at the session or transport 1249 layer using end-to-end control protocols. A majority of real-time 1250 applications employ the Realtime Transport Protocol (RTP) [88]. The 1251 accompanying control protocol RTCP [81] allows receivers to report 1252 information about multicast group membership and associated 1253 performance data. In multicast, the RTCP reports are submitted to the 1254 same group and thus may be monitored by the source to monitor, manage 1255 and control multicast group operations. The Real Time Streaming 1256 Protocol (RTSP), (RFC 2326) provides session layer control that may 1257 be used to control a multicast source. However, RTCP and RTSP 1258 information is intended for end-to-end control and is not necessarily 1259 visible at the network layer. Application designers may chose to 1260 implement any appropriate control plane for their multicast 1261 applications (e.g. reliable multicast transport protocols_), and 1262 therefore a network-layer mobility mechanism must not assume the 1263 presence of a specific transport or session protocols. 1265 References 1267 Informative References 1269 1 Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM 1270 SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, 1271 ACM Press, June, 1984. 1273 2 S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 1274 August 1989. 1276 3 G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts", 1277 IEEE Communications Magazine, 35(1), pp. 54-58, January 1997. 1279 4 R. Hinden and S. Deering, "Internet Protocol Version 6 1280 Specification", RFC 2460, December 1998. 1282 5 D.B. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 1283 RFC 3775, June 2004. 1285 6 V. Devarapalli and F. Dupont, "Mobile IPv6 Operation with IKEv2 1286 and the Revised IPsec Architecture", RFC 4877, April 2007. 1288 7 ITU-T Recommendation, "G.114 - One-way transmission time", 1289 Telecommunication Union Standardization Sector, 05/2003. 1291 8 Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks", 1292 IEEE Communications Magazine, 43(9), pp. 23-30, September 2005. 1294 9 S. Bhattacharyya, "An Overview of Source-Specific Multicast (SSM)", 1295 RFC 3569, July 2003. 1297 10 H. Holbrook, B. Cain, "Source-Specific Multicast for IP", RFC 1298 4607, August 2006. 1300 11 D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector 1301 Multicast Routing Protocol", RFC 1075, November 1988. 1303 12 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. 1304 Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol 1305 Independent Multicast-Sparse Mode (PIM-SM): Protocol 1306 Specification", RFC 2362, June 1998. 1308 13 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 1309 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1310 Specification (Revised)", RFC 4601, August 2006. 1312 14 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bidirectional 1313 Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 1314 2007. 1316 15 T. Bates et al. "Multiprotocol Extensions for BGP-4", RFC 4760, 1317 January 2007. 1319 16 S. Deering, W. Fenner and B. Haberman "Multicast Listener 1320 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1322 17 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version 1323 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1325 18 Arkko, J, Vogt, C, Haddad, W. "Enhanced Route Optimization for 1326 Mobile IPv6", RFC 4866, May 2007. 1328 19 Koodli, R. "Mobile IPv6 Fast Handovers", RFC 5568, July 2009. 1330 20 Soliman, H, Castelluccia, C, El-Malki, K, Bellier, L. 1331 "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, 1332 October 2008. 1334 21 Loughney, J, Nakhjiri, M, Perkins, C, Koodli, R. "Context Transfer 1335 Protocol (CXTP)", RFC 4067, July 2005. 1337 22 Montavont, N, et al. "Analysis of Multihoming in Mobile IPv6", 1338 draft-ietf-monami6-mipv6-analysis-05, Internet Draft (work in 1339 progress), May 2008. 1341 23 Narayanan, V, Thaler, D, Bagnulo, M, Soliman, H. "IP Mobility and 1342 Multi-homing Interactions and Architectural Considerations", 1343 draft-vidya-ip-mobility-multihoming-interactions-01.txt, Internet 1344 Draft (work in progress, expired), July 2007. 1346 24 Savola, P, Haberman, B. "Embedding the Rendezvous Point (RP) 1347 Address in an IPv6 Multicast Address", RFC 3956, November 2004. 1349 25 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - 1350 Analysis of Handover Performance and Its Implications on IPv6 and 1351 Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123- 1352 142, November 2005. 1354 26 Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On 1355 the Evolution of Multicast States under Mobility and an Adaptive 1356 Routing Scheme for Mobile SSM Sources", Telecommunication Systems, 1357 Vol. 33, No. 1-3, pp. 131-154, December 2006. 1359 27 Diot, C. et al. "Deployment Issues for the IP Multicast Service 1360 and Architecture", IEEE Network Magazine, spec. issue on 1361 Multicasting 14(1), pp. 78-88, 2000. 1363 28 Eubanks, M. http://multicasttech.com/status/, 2008. 1365 29 Garyfalos, A, Almeroth, K. and Sanzgiri, K. "Deployment Complexity 1366 Versus Performance Efficiency in Mobile Multicast", Intern. 1367 Workshop on Broadband Wireless Multimedia: Algorithms, 1368 Architectures and Applications (BroadWiM), San Jose, California, 1369 USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM- 1370 04.pdf.gz 1372 30 Garyfalos, A, Almeroth, K. "A Flexible Overlay Architecture for 1373 Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm, 23 1374 (11), pp. 2194-2205, November 2005. 1376 31 "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of 1377 Specifications for Phase 1", ETSI TS 102 468; 1379 32 ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast 1380 over DVB-H: Implementation Guidelines for Mobility)", European 1381 Standard (Telecommunications series), November 2004. 1383 33 Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- 1384 Based Approach", Telecommunication Systems 17(3), 281-297, 2001. 1385 Presented at the INET'98, Geneva, Switzerland, July 1998. 1387 34 Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of 1388 Multicast", IEEE/ACM Trans. Netw., 9, 6, pp. 719-732, Dec. 2001. 1390 35 Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast 1391 trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003. 1393 36 Janic, M. and Van Mieghem, P. "On properties of multicast routing 1394 trees", Int. J. Commun. Syst. 19(1), pp. 95-114, Feb. 2006. 1396 37 Van Mieghem, P. "Performance Analysis of Communication Networks 1397 and Systems", Cambridge University Press, 2006. 1399 38 Fenner, B, He, H, Haberman, B, Sandick, H. "Internet Group 1400 Management Protocol (IGMP) / Multicast Listener Discovery (MLD)- 1401 Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, 1402 August 2006. 1404 39 Jeon, H., Riegel, M. and Jeong, S. "Transmission of IP over 1405 Ethernet over IEEE 802.16 Networks ", draft-ietf-16ng-ip-over- 1406 ethernet-over-802-dot-16-12.txt, (work in progress), September 1407 2009. 1409 40 Shin, M. et al. "IPv6 Deployment Scenarios in 802.16 Networks", 1410 RFC 5181, May 2008. 1412 41 Patil, B. et al. "Transmission of IPv6 via the IPv6 Convergence 1413 Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. 1415 42 Kim, S. et al. "Multicast Transport on IEEE 802.16 Networks", 1416 draft-sekim-802-16-multicast-01, (work in progress, expired), July 1417 2007. 1419 43 IEEE 802.16e-2005: IEEE Standard for Local and metropolitan area 1420 networks Part 16: "Air Interface for Fixed and Mobile Broadband 1421 Wireless Access Systems Amendment for Physical and Medium Access 1422 Control Layers for Combined Fixed and Mobile Operation in Licensed 1423 Bands.", New York, February 2006. 1425 44 3rd Generation Partnership Project; Technical Specification Group 1426 Services and System Aspects; "IP Multimedia Subsystem (IMS)"; 1427 Stage 2, 3GPP TS 23.228, Rel. 5 ff, 2002 - 2007. 1429 45 Wasserman, M. "Recommendations for IPv6 in Third Generation 1430 Partnership Project (3GPP) Standards", RFC 3314, September 2002. 1432 46 3GPP2, www.3gpp2.org, 1433 "X.S0022-A, Broadcast and Multicast Service in cdma2000 Wireless 1434 IP Network, Rev. A.", 1435 http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007. 1437 47 ETSI EN 302 304, "Digital Video Broadcasting (DVB); Transmission 1438 System for Handheld Terminals (DVB-H)", European Standard 1439 (Telecommunications series), November 2004. 1441 48 Fairhurst, G. and Montpetit, M. "Address Resolution Mechanisms for 1442 IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007. 1444 49 Montpetit, M. et al. "A Framework for Transmission of IP Datagrams 1445 over MPEG-2 Networks", RFC 4259, November 2005. 1447 50 Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in 1448 DVB-H", IEEE Comm. Surveys, 8(4), 2006. 1450 51 Fairhurst, G., and Collini-Nocker, B. "Unidirectional Lightweight 1451 Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG- 1452 2 Transport Stream (TS)", RFC 4326, December 2005. 1454 52 Fairhurst, G., and Collini-Nocker, B. "Extension Formats for 1455 Unidirectional Lightweight Encapsulation (ULE) and the Generic 1456 Stream Encapsulation (GSE)", RFC 5163, April 2008. 1458 53 "Draft IEEE Standard for Local and Metropolitan Area Networks: 1459 Media Independent Handover Services", IEEE LAN/MAN Draft IEEE 1460 P802.21/D07.00, July 2007. 1462 54 Melia, T. et al. "Mobility Services Transport: Problem Statement", 1463 RFC 5164, March 2008. 1465 55 Melia, T. et al. "IEEE 802.21 Mobility Services Framework Design 1466 (MSFD)", draft-ietf-mipshop-mstp-solution-12, January 2009. 1468 56 Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three 1469 Approaches Towards Mobile Multicast", IST Mobile Summit 2003, 1470 Aveiro, Portugal, 16-18 June 2003. 1472 57 Suh, K, Kwon, D.-H, Suh, Y.-J. and Park, Y, "Fast Multicast 1473 Protocol for Mobile IPv6 in the fast handovers environments", 1474 Internet Draft - (work in progress, expired), February 2004. 1476 58 Xia, F. and Sarikaya, B, "FMIPv6 extensions for Multicast 1477 Handover", draft-xia-mipshop-fmip-multicast-01, (work in progress, 1478 expired), March 2007. 1480 59 Schmidt, T.C. and Waehlisch, M, "Seamless Multicast Handover in a 1481 Hierarchical Mobile IPv6 Environment (M-HMIPv6)", draft-schmidt- 1482 waehlisch-mhmipv6-04, (work in progress, expired), December 2005. 1484 60 Jonas, K. and Miloucheva, I, "Multicast Context Transfer in mobile 1485 IPv6", draft-miloucheva-mldv2-mipv6-00.txt, (work in progress, 1486 expired), June 2005. 1488 61 Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast 1489 mobility support using fast MIPv6 extensions", Computer Comm. 29, 1490 pp. 3745-3765, 2006. 1492 62 Gundavelli, S, et al. "Proxy Mobile IPv6", RFC 5213, August 2008. 1494 63 Deng, H, Schmidt, T.C., Seite, P., and Yang, P. "Multicast Support 1495 Requirements for Proxy Mobile IPv6", draft-deng-multimob-pmip6- 1496 requirement-02, (work in progress), July 2009. 1498 64 Zhang, H. et al. "Mobile IPv6 Multicast with Dynamic Multicast 1499 Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in 1500 progress, expired), January 2007. 1502 65 Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile Multicast: 1503 Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004. 1505 66 Conta, A, Deering, S, "Generic Packet Tunneling in IPv6 - 1506 Specification", RFC 2473, December 1998. 1508 67 Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On 1509 Deployable, Efficient, Mobility-agnostic Group Communication 1510 Services", Internet Research, 17 (5), pp. 519-534, Emerald 1511 Insight, Bingley, UK, November 2007. 1513 68 Buford, J. "Hybrid Overlay Multicast Framework", draft-irtf-sam- 1514 hybrid-overlay-framework-02.txt, Internet Draft (work in 1515 progress), February 2008. 1517 69 Waehlisch, M., Schmidt, T.C. "A Common API for Transparent Hybrid 1518 Multicast", draft-waehlisch-sam-common-api, October 2009. 1520 70 Christensen, M, Kimball, K. and Solensky, F. "Considerations for 1521 Internet Group Management Protocol (IGMP) and Multicast Listener 1522 Discovery (MLD) Snooping Switches", RFC 4541, May 2006. 1524 71 Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks: 1525 Progress and Challenges", IEEE Wirel. Comm, pp 58-64, Oct. 2002. 1527 72 Romdhani, I, Bettahar, H. and Bouabdallah, A. "Transparent 1528 handover for mobile multicast sources", in P. Lorenz and P. Dini, 1529 eds, Proceedings of the IEEE ICN'06, IEEE Press, 2006. 1531 73 Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile 1532 Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002. 1534 74 Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with 1535 Dynamic Tree Adjustment for Mobile IPv6", Journ. Information 1536 Science and Engineering 20, pp. 1109-1124, 2004. 1538 75 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings 1539 of ietf meeting, Dec. 2001. 1540 URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf 1542 76 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6 1543 (MSSMSv6)", Internet Draft (work in progress, expired), January 1544 2002. 1546 77 Handley, M, Perkins, C, Whelan, E. "Session Announcement 1547 Protocol", RFC 2974, October 2000. 1549 78 Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility 1550 Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 1551 2002. 1553 79 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill- 1554 mip-multicast-00.txt, (work in progress, expired), July 2002. 1556 80 Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 - 1557 Problems, Solutions and Improvements", Computational Methods in 1558 Science and Technology 11(2), pp. 147-152. Selected Papers from 1559 TERENA Networking Conference, Poznan, May 2005. 1561 81 Schmidt, T.C., Waehlisch, M., and Wodarz, M. "Fast Adaptive 1562 Routing Supporting Mobile Senders in Source Specific Multicast", 1563 Telecommunication Systems, 2009, http://dx.doi.org/10.1007/s11235- 1564 009-9200-y 1566 82 Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source 1567 Mobility in Source Specific Multicast", in K. Kawahara and I. 1568 Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp. 82-91, 1569 Springer-Verlag, Berlin, Heidelberg, 2006. 1571 83 Kovacshazi, Z. and Vida, R. "Host Identity Specific Multicast", 1572 Third International Conference on Networking and Services ICNS, 1573 IEEE Press, pp. 1-1, June 2007. 1575 84 Kellil, M, Romdhani, I, Lach, H.-Y, Bouabdallah, A. and Bettahar, 1576 H. "Multicast Receiver and Sender Access Control and its 1577 Applicability to Mobile IP Environments: A Survey", IEEE Comm. 1578 Surveys & Tutorials 7(2), pp. 46-70, 2005. 1580 85 Castellucia, C, Montenegro, G. "Securing Group Management in IPv6 1581 with Cryptographically Based Addresses", Proc. 8th IEEE Int'l 1582 Symp. Comp. and Commun, Turkey, July 2003, pp. 588-93. 1584 86 Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G. "AuthoCast - 1585 a mobility-compliant protocol framework for multicast sender 1586 authentication", Security and Communication Networks, 1(6), 1587 pp. 495 - 509, 2008. 1589 87 Fenner, B. et al. "Multicast Source Notification of Interest 1590 Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress, 1591 expired), March 2004. 1593 88 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time 1594 Applications", RFC 3550, July 2003. 1596 Acknowledgments 1598 Work on exploring the problem space for mobile multicast has been 1599 pioneered by Greg Daley and Gopi Kurup within their early draft 1600 "Requirements for Mobile Multicast Clients" (draft-daley-magma- 1601 mobile). 1603 Since then, many people have actively discussed the different issues 1604 and contributed to the enhancement of this memo. The authors would 1605 like to thank (in alphabetical order) Kevin C. Almeroth, Lachlan 1606 Andrew, Jari Arkko, Cedric Baudoin, Hans L. Cycon, Hui Deng, Marshall 1607 Eubanks, Zhigang Huang, Christophe Jelger, Andrei Gutov, Rajeev 1608 Koodli, Mark Palkow, Craig Partridge, Imed Romdhani, Hesham Soliman, 1609 Dave Thaler and last, but not least, very special thanks to Stig 1610 Venaas for his frequent and thorough advice. 1612 Author's Addresses 1614 Thomas C. Schmidt 1615 Dept. Informatik 1616 Hamburg University of Applied Sciences, 1617 Berliner Tor 7 1618 D-20099 Hamburg, Germany 1619 Phone: +49-40-42875-8157 1620 Email: schmidt@informatik.haw-hamburg.de 1622 Matthias Waehlisch 1623 link-lab 1624 Hoenower Str. 35 1625 D-10318 Berlin, Germany 1626 Email: mw@link-lab.net 1628 Godred Fairhurst 1629 School of Engineering, 1630 University of Aberdeen, 1631 Aberdeen, AB24 3UE, UK 1632 EMail: gorry@erg.abdn.ac.uk