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