idnits 2.17.1 draft-schmidt-mobopts-mmcastv6-ps-02.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 3979, Section 5, paragraph 1 on line 814. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 821. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 827. ** 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? ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 297: '...entations of SSM source filtering MUST...' 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 (March 2007) is 6252 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '2' on line 100 looks like a reference -- Missing reference section? '3' on line 106 looks like a reference -- Missing reference section? '4' on line 109 looks like a reference -- Missing reference section? '5' on line 432 looks like a reference -- Missing reference section? '6' on line 110 looks like a reference -- Missing reference section? '35' on line 453 looks like a reference -- Missing reference section? '7' on line 151 looks like a reference -- Missing reference section? '8' on line 152 looks like a reference -- Missing reference section? '9' on line 152 looks like a reference -- Missing reference section? '10' on line 155 looks like a reference -- Missing reference section? '11' on line 155 looks like a reference -- Missing reference section? '12' on line 155 looks like a reference -- Missing reference section? '13' on line 156 looks like a reference -- Missing reference section? '14' on line 156 looks like a reference -- Missing reference section? '15' on line 157 looks like a reference -- Missing reference section? '16' on line 157 looks like a reference -- Missing reference section? '17' on line 285 looks like a reference -- Missing reference section? '43' on line 449 looks like a reference -- Missing reference section? '47' on line 328 looks like a reference -- Missing reference section? '44' on line 339 looks like a reference -- Missing reference section? '45' on line 344 looks like a reference -- Missing reference section? '24' on line 450 looks like a reference -- Missing reference section? '38' on line 369 looks like a reference -- Missing reference section? '39' on line 379 looks like a reference -- Missing reference section? '40' on line 377 looks like a reference -- Missing reference section? '42' on line 382 looks like a reference -- Missing reference section? '41' on line 385 looks like a reference -- Missing reference section? '36' on line 407 looks like a reference -- Missing reference section? '18' on line 446 looks like a reference -- Missing reference section? '19' on line 447 looks like a reference -- Missing reference section? '20' on line 447 looks like a reference -- Missing reference section? '21' on line 447 looks like a reference -- Missing reference section? '22' on line 477 looks like a reference -- Missing reference section? '23' on line 448 looks like a reference -- Missing reference section? '49' on line 449 looks like a reference -- Missing reference section? '25' on line 452 looks like a reference -- Missing reference section? '26' on line 497 looks like a reference -- Missing reference section? '27' on line 480 looks like a reference -- Missing reference section? '28' on line 489 looks like a reference -- Missing reference section? '29' on line 507 looks like a reference -- Missing reference section? '30' on line 513 looks like a reference -- Missing reference section? '31' on line 523 looks like a reference -- Missing reference section? '32' on line 525 looks like a reference -- Missing reference section? '33' on line 530 looks like a reference -- Missing reference section? '34' on line 534 looks like a reference -- Missing reference section? '37' on line 555 looks like a reference -- Missing reference section? '48' on line 569 looks like a reference -- Missing reference section? '50' on line 573 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 53 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 Matthias Waehlisch 5 Expires: September 2007 link-lab 6 March 2007 8 Multicast Mobility in MIPv6: Problem Statement 9 11 IPR Statement 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79 [1]. 18 Status of this Memo 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This document is a submission of the IRTF MobOpts RG. Comments should 36 be directed to the MobOpts RG mailing list, mobopts@irtf.org. 38 Abstract 40 In this document we discuss mobility extensions to current IP layer 41 multicast solutions. Problems arising from mobile group communication 42 in general, in the case of multicast listener mobility and for mobile 43 Any Source Multicast as well as Source Specific Multicast senders are 44 documented. Characteristic aspects of multicast routing and 45 deployment issues are summarized. The principal approaches to the 46 multicast mobility problems are outlined subsequently. 48 Table of Contents 50 1. Introduction and Motivation....................................3 52 2. Problem Description............................................4 53 2.1 Generals...................................................4 54 2.2 Multicast Listener Mobility................................5 55 2.3 Multicast Source Mobility..................................6 56 2.3.1 Any Source Multicast Mobility.........................6 57 2.3.2 Source Specific Multicast Mobility....................7 58 2.4 Deployment Issues..........................................8 60 3. Characteristics of Multicast Routing Trees under Mobility......8 62 4. Solutions......................................................9 63 4.1 General Approaches.........................................9 64 4.2 Solutions for Multicast Listener Mobility.................10 65 4.3 Solutions for Multicast Source Mobility...................10 66 4.3.1 Any Source Multicast Mobility Approaches.............10 67 4.3.2 Source Specific Multicast Mobility Approaches........11 69 5. Security Considerations.......................................12 71 6. IANA Considerations...........................................12 73 Appendix A. Implicit Source Notification Options.................12 75 7. References....................................................13 77 Acknowledgments..................................................17 79 Author's Addresses...............................................17 81 Intellectual Property Statement..................................18 83 Copyright Notice.................................................18 85 Disclaimer of Validity...........................................18 87 Acknowledgement..................................................18 89 1. Introduction and Motivation 91 Group communication forms an integral building block of a wide 92 variety of applications, ranging from public content distribution and 93 streaming over voice and video conferencing, collaborative 94 environments and gaming up to the self-organization of distributed 95 systems. Its support by network layer multicast will be needed, 96 whenever globally distributed, scalable, serverless or instantaneous 97 communication is required. As broadband media delivery more and more 98 emerges to be a typical mass scenario, scalability and bandwidth 99 efficiency of multicast routing continuously gains relevance. The 100 idea of Internet multicasting already arose in the early days [2], 101 its realization will be of particular importance to mobile 102 environments, where users commonly share frequency bands of limited 103 capacity. The rapidly increasing mobile reception of 'infotainment' 104 streams may soon require a wide deployment of mobile multicast 105 services. Multicast mobility consequently has been a concern for 106 about ten years [3] and led to innumerous proposals, but no generally 107 accepted solution. 109 The fundamental approach to deal with mobility in IPv6 [4] is stated 110 in the Mobile IPv6 RFCs [5,6]. MIPv6 [5] only roughly treats 111 multicast mobility, in a pure remote subscription approach or through 112 bi-directional tunneling via the Home Agent. Whereas the remote 113 subscription suffers from slow handovers, as it relies on multicast 114 routing to adapt to handovers, bi-directional tunneling introduces 115 inefficient overheads and delays due to triangular forwarding. 116 Therefore none of the approaches can be considered solutions for a 117 deployment on large scale. A mobile multicast service for a future 118 Internet should admit 'close to optimal' routing at predictable and 119 limited cost, robustness combined with a service quality compliant to 120 real-time media distribution. 122 Intricate multicast routing procedures, though, are not easily 123 extensible to comply with mobility requirements. Any client 124 subscribed to a group while in motion, requires delivery branches to 125 pursue its new location; any mobile source requests the entire 126 delivery tree to adapt to its changing positions. Significant effort 127 has already been invested in protocol designs for mobile multicast 128 receivers. Only limited work has been dedicated to multicast source 129 mobility, which poses the more delicate problem [35]. 131 In multimedia conference scenarios each member commonly operates as 132 receiver and as sender for multicast based group communication. In 133 addition, real-time communication such as voice or video over IP 134 places severe temporal requirement on mobility protocols: Seamless 135 handover scenarios need to limit disruptions or delay to less than 136 100 ms. Jitter disturbances are not to exceed 50 ms. Note that 100 ms 137 is about the duration of a spoken syllable in real-time audio. 139 It is the aim of this document, to specify the problem scope for a 140 multicast mobility management as to be refined in future work. The 141 attempt is made to subdivide the various challenges according to 142 their originating aspects and to present existing proposals for 143 solution, as well as major bibliographic references. 145 2. Problem Description 147 2.1 Generals 149 Multicast mobility must be considered as a generic term, which 150 subsumes a collection of quite distinct functions. At first, 151 multicast communication divides into Any Source Multicast (ASM) [7] 152 and Source Specific Multicast (SSM) [8,9]. At second, the roles of 153 senders and receivers are asymmetric and need distinction. Both may 154 individually be mobile. Their interaction is facilitated by a 155 multicast routing function such as DVMRP [10], PIM-SM/SSM [11,12], 156 Bi-directional PIM [13] or CBT [14] and the multicast listener 157 discovery protocol [15,16]. 159 Any multicast mobility solution must account for all of these 160 functional blocks. It should enable seamless continuity of multicast 161 sessions when moving from one IPv6 subnet to another. It should 162 preserve the multicast nature of packet distribution and approximate 163 optimal routing. It should support per flow handover for multicast 164 traffic, as properties and designations of flows may be of distinct 165 nature. 167 Multicast routing dynamically adapts to session topologies, which 168 then may change under mobility. However, depending on the topology 169 and the protocol in use, routing convergence arrives at a time scale 170 close to seconds, or even minutes and is far too slow to support 171 seamless handovers for interactive or real-time media sessions. The 172 actual temporal behavior strongly depends on the routing protocol in 173 use and on the geometry of the current distribution tree. A mobility 174 scheme that arranges for adjustments, i.e., partial changes or full 175 reconstruction of multicast trees is forced to make provision for 176 time buffers sufficient for protocol convergence. Special attention 177 is needed with a possible rapid movement of the mobile node, as this 178 may occur at much higher rates than compatible with protocol 179 convergence. 181 IP layer multicast packet distribution is an unreliable service, 182 which is bound to connectionless transport protocols. Packet loss 183 thus will not be handled in a predetermined fashion. Mobile multicast 184 handovers should not cause significant packet drops. Due to 185 statelessness the bi-casting of multicast flows does not cause 186 foreseeable degradations of the transport layer. 188 Group addresses in general are location transparent, even though 189 there are proposals to embed unicast prefixes or Rendezvous Point 190 addresses [17]. Addresses of sources contributing to a multicast 191 session are interpreted by the routing infrastructure and by receiver 192 applications, which frequently are source address aware. Multicast 193 therefore inherits the mobility address duality problem for source 194 addresses, being a logical node identifier, i.e., the home address 195 (HoA) at the one hand and a topological locator, the care-of-address 196 (CoA) at the other. 198 Multicast sources in general operate decoupled from their receivers 199 in the following sense: A multicast source submits data to a group of 200 unknown receivers and thus operates without any feedback channel. It 201 neither has means to inquire on properties of its delivery trees, nor 202 will it be able to learn about the state of its receivers. In the 203 event of an inter-tree handover, a mobile multicast source therefore 204 is vulnerable to loosing receivers without taking notice. (Cf. 205 Appendix A for implicit source notification approaches). Applying a 206 mobility binding update or return routability procedure will likewise 207 break the semantic of a receiver group remaining unidentified by the 208 source and thus cannot be applied in unicast analogy. 210 2.2 Multicast Listener Mobility 212 A mobile multicast listener entering a new IP subnet faces the 213 problem of transferring the multicast membership context to its new 214 point of attachment. It thereby may encounter either one of the 215 following conditions: The new network may not be multicast enabled or 216 the specific multicast service in use may be unsupported or 217 prohibited. Alternatively, the requested multicast service may be 218 supported and enabled in the new network, but the multicast groups 219 under subscription may not be forwarded to it. Then current 220 distribution trees for the desired groups may reside at large routing 221 distance. It may as well occur that data of some or all groups under 222 subscription of the mobile node are received by one or several local 223 group members at the instance of arrival and that multicast streams 224 flow natively. 226 The problem of achieving seamless multicast listener handovers is 227 thus threefold: 228 o Ensure multicast reception even in visited networks without 229 appropriate multicast support. 230 o Expedite primary multicast forwarding to comply with a seamless 231 timescale at handovers. 232 o Realize native multicast forwarding whenever applicable to 233 preserve network resources and avoid data redundancy. 235 Additional aspects related to infrastructure remain. In changing its 236 point of attachment a mobile receiver may not have enough time to 237 leave groups in the previous network. Also, packet duplication and 238 disorder may result from the change of topology. 240 2.3 Multicast Source Mobility 242 2.3.1 Any Source Multicast Mobility 244 A node submitting data to an ASM group either defines the root of a 245 source specific shortest path tree (SPT), distributing data towards a 246 rendezvous point or receivers, or it forwards data directly down a 247 shared tree, e.g., via encapsulated PIM register messages. Aside from 248 tunneling or shared trees, forwarding along source specific delivery 249 trees will be bound to a topological network address due to reverse 250 path forwarding (RPF) checks. A mobile multicast source moving away 251 is solely enabled to either inject data into a previously established 252 delivery tree, which may be a rendezvous point based shared tree, or 253 to (re-)define a multicast distribution tree compliant to its new 254 location. In pursuing the latter the mobile sender will have to 255 proceed without control of the new tree construction due to 256 decoupling of sender and receivers. 258 A mobile multicast source consequently must meet address transparency 259 at two layers: In order to comply with RPF checks, it has to use an 260 address within the IPv6 basic header's source field, which is in 261 topological concordance with the employed multicast distribution 262 tree. For application transparency the logical node identifier, 263 commonly the HoA, must be presented as packet's source address to the 264 socket layer at the receiver side. 266 Conforming to address transparency and temporal handover constraints 267 will be major problems for any route optimizing mobility solution. 268 Additional issues arrive from possible packet loss and from multicast 269 scoping. A mobile source away from home must attend scoping 270 restrictions, which arise from its home and its visited location [5]. 272 Within intra-domain multicast routing the employment of shared trees 273 may considerably relax mobility related complexity. Relying upon a 274 static rendezvous point, a mobile source may continuously submit data 275 by encapsulating packets with its previous topologically correct or 276 home source address. Constraints even weaken, when bi-directional PIM 277 is used. Intra-domain mobility is transparently covered by bi- 278 directional shared trees, eliminating the need for tunneling data to 279 reach the rendezvous point. 281 However, issues arise in inter-domain multicast scenarios, whenever 282 notification of source addresses is required between distributed 283 instances of shared trees. A new CoA acquired after a mobility 284 handover will necessarily be subject to inter-domain record exchange. 285 In presence of embedded rendezvous point addresses [17], e.g., for 286 inter-domain PIM-SM, the primary rendezvous point will be globally 287 appointed and the signaling requirements obsolete. 289 2.3.2 Source Specific Multicast Mobility 291 Fundamentally, Source Specific Multicast has been designed for static 292 addresses of multicast senders. Source addresses in client 293 subscription to SSM groups are directly used for route 294 identification. Any SSM subscriber is thus forced to know the 295 topological address of its group contributors. SSM source 296 identification invalidates, when source addresses change under 297 mobility. Hence client implementations of SSM source filtering MUST 298 be MIPv6 aware in the sense that a logical source identifier (HoA) is 299 correctly mapped to its current topological correspondent (CoA). 301 Consequently source mobility for SSM packet distribution requires a 302 dedicated conceptual treatment in addition to the problems of mobile 303 ASM. As a listener is subscribed to an (S,G) channel membership and 304 as routers have established an (S,G)-state shortest path tree rooted 305 at source S, any change of source addresses under mobility requests 306 for state updates at all routers and all receivers. On source 307 handover a new SPT needs to be established, which partly will 308 coincide with the previous SPT, e.g., at the receiver side. As the 309 principle multicast decoupling of a sender from its receivers 310 likewise holds for SSM, client updates needed for switching trees 311 turns into a severe problem. 313 An SSM listener subscribing to or excluding any specific multicast 314 source, may want to rely on the topological correctness of network 315 operations. The SSM design permits trust in equivalence to the 316 correctness of unicast routing tables. Any SSM mobility solution 317 should preserve this degree of confidence. Binding updates for SSM 318 sources thus should have to prove address correctness in the unicast 319 routing sense, which is equivalent to binding update security with a 320 correspondent node in MIPv6 [5]. 322 All of the above severely add complexity to a robust SSM mobility 323 solution, which should converge to optimal routes and, for the sake 324 of efficiency, should avoid data encapsulation, as well. Like in ASM 325 handover delays are to be considered critical. The routing distance 326 between subsequent points of attachment, the �step size� of the 327 mobile from previous to next designated router, may serve as an 328 appropriate measure of complexity [43,47]. 330 Finally, Source Specific Multicast has been designed as a light- 331 weight approach to group communication. In adding mobility 332 management, it is desirable to preserve the principle leanness of SSM 333 by minimizing additional signaling overheads. 335 2.4 Deployment Issues 337 IP multicast deployment in general has been hesitant over the past 15 338 years, even though all major router vendors and operating systems 339 offer a wide variety of implementations to support multicast [44]. A 340 dispute arose on the appropriate layer, where group communication 341 service should reside, and the focus of the research community turned 342 towards application layer multicast. This debate on "efficiency 343 versus deployment complexity" now overlaps into the mobile multicast 344 domain [45]. Hereunto Garyfalos and Almeroth [24] derived from fairly 345 generic principles that when mobility is introduced the performance 346 gap between IP and application layer multicast widens in different 347 metrics up to a factor of four. 349 Therefore it is desirable that any solution to mobile multicast 350 should leave routing protocols unchanged. Mobility management in such 351 deployment-friendly schemes should preferably be handled at edge 352 nodes, preserving the routing infrastructure in mobility agnostic 353 condition. Facing the current state of proposals, the urge remains 354 open to search for such simple, infrastructure transparent solutions, 355 even though there are reasonable doubts, whether the desired can be 356 achieved in all cases. 358 Nevertheless, multicast services in mobile environments may soon 359 become indispensable, when multimedia distribution services such as 360 DVB will develop as a strong business case for IP portables. As IP 361 mobility will unfold dominance and as efficient link utilization will 362 show a larger impact in costly radio environments, the evolution of 363 multicast protocols will naturally follow mobility constraints. 365 3.Characteristics of Multicast Routing Trees under Mobility 367 Multicast distribution trees have been studied well under the focus 368 of network efficiency. Grounded on empirical observations Chuang and 369 Sirbu [38] proposed a scaling power-law for the total number of links 370 in a multicast shortest path tree with m receivers (prop. m^k). The 371 authors consistently identified the scale factor to attain the 372 independent constant k = 0.8. The validity of such universal, heavy- 373 tailed distribution suggests that multicast shortest path trees are 374 of self-similar nature with many nodes of small, but few of higher 375 degrees. Trees consequently would be shaped rather tall than wide. 377 Subsequent empirical and analytical work, cf. [39,40], debated the 378 applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. 379 [39] proved that the proposed power law cannot hold for an increasing 380 Internet or very large multicast groups, but is indeed applicable for 381 moderate receiver numbers and the current Internet size N = 10^5 core 382 nodes. Investigating on self-similarity Janic and Van Mieghem [42] 383 semi-empirically substantiated that multicast shortest path trees in 384 the Internet can be modeled with reasonable accuracy by uniform 385 recursive trees (URT) [41], provided m remains small compared to N. 387 The mobility perspective on shortest path trees focuses on their 388 alteration, i.e., the degree of topological changes induced by 389 movement. For receivers, and more interestingly for sources this may 390 serve as an outer measure for routing complexity. Source specific 391 multicast trees subsequently generated from mobility handover steps 392 are not independent, but highly correlated. They most likely branch 393 to the identical receivers at one or several intersection points. By 394 the self-similar nature, the persistent subtrees (of previous and 395 next distribution tree), rooted at any such intersection point, 396 exhibit again the scaling law behavior, are tall-shaped with nodes of 397 mainly low degree and thus likely to coincide. Tree alterations under 398 mobility have been studied in [43], both analytically and by 399 simulations. It was found that even in large networks and for 400 moderate receiver numbers more than 80 % of the multicast router 401 states remain invariant under a source handover. 403 4. Solutions 405 4.1 General Approaches 407 Three approaches to mobile Multicast are commonly around [36]: 409 o Bi-directional Tunnelling guides the mobile node to tunnel all 410 multicast data via its home agent. This principle multicast solution 411 hides all movement and results in static multicast trees. It may be 412 employed transparently by mobile multicast listeners and sources, on 413 the price of triangular routing and possibly significant performance 414 degradations due to widely spanned data tunnels. 416 o Remote Subscription forces the mobile node to re-initiate 417 multicast distribution subsequent to handover by submitting an MLD 418 listener report within the subnet it newly attached to. This approach 419 of tree discontinuation relies on multicast dynamics to adapt to 420 network changes. It not only results in rigorous service disruption, 421 but leads to mobility driven changes of source addresses, and thus 422 disregards session persistence under multicast source mobility. 424 o Agent-based solutions attempt to balance between the previous two 425 mechanisms. Static agents typically act as local tunnelling proxies, 426 allowing for some inter-agent handover while the mobile node moves 427 away. A decelerated inter-tree handover, i.e. tree walking, will be 428 the outcome of agent-based multicast mobility, where some extra 429 effort is needed to sustain session persistence through address 430 transparency of mobile sources. 432 MIPv6 [5] introduces bi-directional tunnelling as well as remote 433 subscription as minimal standard solutions. Various publications 434 suggest utilizing remote subscription for listener mobility, only, 435 while advising bi-directional tunnelling as the solution for source 436 mobility. Such approach suffers from the drawback that multicast 437 communication roles are not explicitly known at the network layer and 438 may change or mix unexpectedly. 440 It should be noted that none of the above approaches address SSM 441 source mobility, except the bi-directional tunnelling. 443 4.2 Solutions for Multicast Listener Mobility 445 There are proposals of agent assisted handovers compliant to the 446 unicast real-time mobility infrastructure of Fast MIPv6 [18], the M- 447 FMIPv6 [19,20], and of Hierarchical MIPv6 [21], the M-HMIPv6 [22], 448 and to context transfer [23], which have been thoroughly analyzed in 449 [43,49]. A hybrid architecture of reactively operating proxy-gateways 450 located at the Internet edges is introduced in [24]. An approach 451 based on dynamically negotiated inter-agent handovers is presented in 452 [25]. Aside from IETF work countless publications present proposals 453 for seamless multicast listener mobility, cf. [35] for a 454 comprehensive overview. 456 4.3 Solutions for Multicast Source Mobility 458 4.3.1 Any Source Multicast Mobility Approaches 460 Solutions for the multicast source mobility problem can be sorted in 461 three categories: 463 o Statically Rooted Distribution Trees: 465 Following a shared tree approach, Romdhani et al. [26] propose to 466 employ Rendezvous Points of PIM-SM as mobility anchors. Mobile 467 senders tunnel their data to these "Mobility-aware Rendezvous Points" 468 (MRPs), whence in restriction to a single domain this scheme is 469 equivalent to the bi-directional tunneling. Focusing on interdomain 470 mobile multicast, the authors design a tunnel- or SSM-based backbone 471 distribution of packets between MRPs. 473 o Reconstruction of Distribution Trees: 475 Several authors propose to construct a completely new distribution 476 tree after the movement of a mobile source and thereby have to 477 compensate routing delays. M-HMIPv6 [22] tunnels data into previously 478 established trees rooted at mobility anchor points to compensate for 479 routing delays until a protocol dependent timer expires. The RBMoM 480 protocol [27] introduces additional Multicast Agents (MA), which 481 advertise their service range. The mobile source registers with the 482 closest MA and tunnels its data through it. When moving out of the 483 previous service range, it will perform a MA discovery, a re- 484 registration and continue data tunneling with its newly established 485 Multicast Agent in its current vicinity. 487 o Tree Modification Schemes: 489 In the case of DVMRP routing, Chang and Yen [28] propose an algorithm 490 to extend the root of a given delivery tree for incorporating a new 491 source location in ASM. To fix DVMRP forwarding states and heal 492 reverse path forwarding (RPF) check failures, the authors rely on a 493 complex additional signaling protocol. 495 4.3.2 Source Specific Multicast Mobility Approaches 497 The shared tree approach of [26] has been extended to SSM mobility by 498 introducing the HoA address record to Mobility-aware Rendezvous 499 Points. These MRPs operate on extended multicast routing tables, 500 which simultaneously hold HoA and CoA and are thus enabled to 501 logically identify the appropriate distribution tree. Mobility thus 502 re-introduces rendezvous points to SSM routing. 504 Approaches of reconstructing SPTs in SSM have to rely on client 505 notification for initiating new router state establishment. At the 506 same time they need to preserve address transparency to the client. 507 To account for the latter, Thaler [29] proposes to employ binding 508 caches and to obtain source address transparency analogous to MIPv6 509 unicast communication. Initial session announcements and changes of 510 source addresses are to be distributed periodically to clients via an 511 additional multicast control tree based at the home agent. Source 512 tree handovers are then activated on listener requests. 513 Jelger and Noel [30] suggest handover improvements by employing 514 anchor points within the source network, supporting a continuous data 515 reception during client initiated handovers. Client updates are to be 516 triggered out of band, e.g. by SDR. Receiver oriented tree 517 construction in SSM thus remains unsynchronized with source 518 handovers. 520 Addressing this synchronization problem at the routing layer, several 521 proposals concentrate on direct modification of distribution trees. 522 Based on a multicast Hop-by-Hop protocol, a recursive scheme of loose 523 unicast source routes with branch points, Vida et al [31] optimize 524 SPTs for moving sources on the path between source and first 525 branching point. O'Neill [32] suggests a scheme to overcome RPF check 526 failures originating from multicast source address changes in a 527 rendezvous point scenario by introducing extended routing 528 information, which accompanies data in a Hop-by-Hop option "RPF 529 redirect" header. The Tree Morphing approach of Schmidt and Waehlisch 530 [33] uses source routing to extend the root of a previously 531 established SPT, thereby injecting router state updates in a Hop-by- 532 Hop option header. Using extended RPF checks the elongated tree 533 autonomously initiates shortcuts and smoothly reduces to a new SPT 534 rooted at the relocated source. Lee et al. [34] introduce a state 535 update mechanism for re-using major parts of established multicast 536 trees. The authors start from initially established distribution 537 states centered at the mobile source's home agent. A mobile leaving 538 its home network will signal a multicast forwarding state update on 539 the path to its home agent and, subsequently, distribution states 540 according to the mobile source's new CoA are implemented along the 541 previous distribution tree. Multicast data then is intended to 542 natively flow in triangular routes via the elongation and updated 543 tree centered at the home agent. Consequently this mechanism refrains 544 from using shortest path trees. Unfortunately the authors do not 545 address the problem of RPF check failures in their paper. 547 5. Security Considerations 549 This document discusses multicast extensions to mobility. Security 550 issues arise from source address binding updates, specifically in the 551 case of source specific multicast. Threats of hijacking unicast 552 sessions will result from any solution jointly operating binding 553 updates for unicast and multicast sessions. Admission control issues 554 may arise with new CoA source addresses being introduced to SSM 555 channels (cf. [37] for a comprehensive discussion). Future solutions 556 must address the security implications. 558 6. IANA Considerations 560 There are no IANA considerations introduced by this draft. 562 Appendix A. Implicit Source Notification Options 564 A multicast source will transmit data to a group of receivers without 565 any option of an explicit feedback channel. There are attempts though 566 to implicitly obtain information on listening group members. One 567 approach has been dedicated to inquire designated routers on the pure 568 existence of receivers. Based on an extension of IGMP, the Multicast 569 Source Notification of Interest Protocol (MSNIP) [48] was designed to 570 allow for the multicast source querying its designated router. 571 However, work on MSNIP has been terminated by IETF. 573 A majority of real-time applications employ RTP [50] as its 574 application layer transport protocol, which is accompanied by its 575 control protocol RTCP. RTP is capable of multicast group distribution 576 and RTCP receiver reports are submitted to the same group in the 577 multicast case. Thus RTCP may be used to monitor, manage and control 578 multicast group operations, as it provides a fairly comprehensive 579 insight into group member statuses. However, RTCP information is 580 neither present at the network layer nor does multicast communication 581 presuppose the use of RTP. 583 7. References 585 Normative References 587 1 S. Bradner "Intellectual Property Rights in IETF Technology", BCP 588 79, RFC 3979, March 2005. 590 2 Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM 591 SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, 592 ACM Press, June, 1984. 594 3 G. Xylomenos and G.C. Plyzos "IP Multicast for Mobile Hosts", IEEE 595 Communications Magazine, pp. 54-58, January 1997. 597 4 R. Hinden and S. Deering "Internet Protocol Version 6 598 Specification", RFC 2460, December 1998. 600 5 D.B. Johnson, C. Perkins and J. Arkko "Mobility Support in IPv6", 601 RFC 3775, June 2004. 603 6 J. Arkko, V. Devarapalli and F. Dupont "Using IPsec to Protect 604 Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 605 3776, June 2004. 607 7 S. Deering "Host Extensions for IP Multicasting", RFC 1112, August 608 1989. 610 8 S. Bhattacharyya "An Overview of Source-Specific Multicast (SSM)", 611 RFC 3569, July 2003. 613 9 H. Holbrook, B. Cain "Source-Specific Multicast for IP", RFC 4607, 614 August 2006. 616 10 D. Waitzman, C. Partridge, S.E. Deering "Distance Vector Multicast 617 Routing Protocol", RFC 1075, November 1988. 619 11 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. 620 Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei "Protocol 621 Independent Multicast-Sparse Mode (PIM-SM): Protocol 622 Specification", RFC 2362, June 1998. 624 12 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas: "Protocol 625 Independent Multicast - Sparse Mode PIM-SM): Protocol 626 Specification (Revised)", RFC 4601, August 2006. 628 13 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano "Bi-directional 629 Protocol Independent Multicast (BIDIR-PIM)", draft-ietf-pim-bidir- 630 09.txt, (work in progress), February 2007. 632 14 A. Ballardie "Core Based Trees (CBT version 2) Multicast Routing", 633 RFC 2189, September 1997. 635 15 S. Deering, W. Fenner and B. Haberman "Multicast Listener 636 Discovery (MLD) for IPv6", RFC 2710, October 1999. 638 16 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version 639 2 (MLDv2) for IPv6", RFC3810, June 2004. 641 17 P. Savola, B. Haberman "Embedding the Rendezvous Point (RP) 642 Address in an IPv6 Multicast Address", RFC 3956, November 2004. 644 18 Koodli, R. "Fast Handovers for Mobile IPv6", RFC 4068, July 2004. 646 19 Suh, K., Kwon, D.-H., Suh, Y.-J. and Park, Y. "Fast Multicast 647 Protocol for Mobile IPv6 in the fast handovers environments", 648 Internet Draft - (work in progress, expired), February 2004. 650 20 Xia, F. and Sarikaya, B. "FMIPv6 extensions for Multicast 651 Handover", draft-xia-mipshop-fmip-multicast-00.txt, (work in 652 progress), September 2006. 654 21 Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L. 655 "Hierarchical Mobile IPv6 mobility management", RFC 4140, August 656 2005. 658 22 Schmidt, T.C. and Waehlisch, M. "Seamless Multicast Handover in a 659 Hierarchical Mobile IPv6 Environment(M-HMIPv6)", draft-schmidt- 660 waehlisch-mhmipv6-04.txt, (work in progress, expired), December 661 2005. 663 23 Jonas, K. and Miloucheva, I. "Multicast Context Transfer in mobile 664 IPv6", draft-miloucheva-mldv2-mipv6-00.txt, (work in progress, 665 expired), June 2005. 667 24 Garyfalos, A., Almeroth, K. "A Flexible Overlay Architecture for 668 Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm., 23 669 (11), pp. 2194-2205, November 2005. 671 25 Zhang, H. et al "Mobile IPv6 Multicast with Dynamic Multicast 672 Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in 673 progress), January 2007. 675 26 Romdhani, I., Bettahar, H. and Bouabdallah, A. "Transparent 676 handover for mobile multicast sources", in P. Lorenz and P. Dini, 677 eds, 'Proceedings of the IEEE ICN'06', IEEE Press, 2006. 679 27 Lin, C.R. et al., "Scalable Multicast Protocol in IP-Based Mobile 680 Networks", Wireless Networks and Applications, 5, pp. 259-271, 681 2000. 683 28 Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with 684 Dynamic Tree Adjustment for Mobile IPv6", Journ. Information 685 Science and Engineering 20, 1109-1124, 2004. 687 29 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings 688 of ietf meeting Dec. 2001, individual. 689 URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf 691 30 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6 692 (MSSMSv6)", Internet Draft (work in progress, expired), January 693 2002. 695 31 Vida, R., Costa, L., Fdida, S. "M-HBH - Efficient Mobility 696 Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 697 2002. 699 32 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill- 700 mip-multicast-01.txt, (work in progress, expired), July 2002. 702 33 Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 - 703 Problems, Solutions and Improvements", Computational Methods in 704 Science and Technology 11(2), 147-152. Selected Papers from TERENA 705 Networking Conference, Poznan, May 2005. 707 34 Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source 708 Mobility in Source Specific Multicast", in K. Kawahara and I. 709 Chong, eds, "Proceedings of ICOIN2006", Vol. 3961 of LNCS, pp. 82- 710 91, Springer-Verlag, Berlin, Heidelberg, 2006. 712 Informative References 714 35 Romdhani, I., Kellil, M., Lach, H.-Y. et. al. "IP Mobile 715 Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), 716 2004. 718 36 Jannetau, C., Tian, Y., Csaba, S. et al "Comparison of Three 719 Approaches Towards Mobile Multicast", IST Mobile Summit 2003, 720 Aveiro, Portugal, 16-18 June 2003, online http://www.comnets.rwth- 721 aachen.de/~o_drive/publications/ist-summit-2003-IPMobileMulticast- 722 paperv2.0.pdf. 724 37 Kellil, M., Romdhani, I., Lach, H.-Y., Bouabdallah, A. and 725 Bettahar, H. "Multicast Receiver and Sender Access Control and its 726 Applicability to Mobile IP Environments: A Survey", IEEE Comm. 727 Surveys & Tutorials 7(2), pp. 46-70, 2005. 729 38 Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- 730 Based Approach", Telecommunication Systems 17(3), 281-297, 2001. 731 Presented at the INET'98, Geneva, Switzerland, July 1998. 733 39 Van Mieghem, P., Hooghiemstra, G., Hofstad, R. "On the Efficiency 734 of Multicast", Transactions on Networking, 9, 6, pp. 719-732, 735 December 2001. 737 40 Chalmers, R.C. and Almeroth, K.C., "On the topology of multicast 738 trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003. 740 41 Van Mieghem, P. "Performance Analysis of Communication Networks 741 and Systems", Cambridge University Press, 2006. 743 42 Janic, M. and Van Mieghem, P. "On properties of multicast routing 744 trees", Int. J. Commun. Syst. 19(1), pp. 95-114, 2006. 746 43 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - 747 Analysis of Handover Performance and Its Implications on IPv6 and 748 Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123- 749 142, November 2005. 751 44 Diot, C. et al. "Deployment Issues for the IP Multicast Service 752 and Architecture", IEEE Network Magazine, spec. issue on 753 Multicasting 14(1), pp. 78-88, 2000. 755 45 Garyfalos, A., Almeroth, K. and Sanzgiri, K. "Deployment 756 Complexity Versus Performance Efficiency in Mobile Multicast", 757 Intern. Workshop on Broadband Wireless Multimedia: Algorithms, 758 Architectures and Applications (BroadWiM), San Jose, California, 759 USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM- 760 04.pdf.gz 762 46 Jelger, C., Noel, T. "Multicast for Mobile Hosts in IP Networks: 763 Progress and Challenges", IEEE Wireless Comm., pp 58-64, Oct. 764 2002. 766 47 Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - 767 On the Evolution of Multicast States under Mobility and an 768 Adaptive Routing Scheme for Mobile SSM Sources", Telecommunication 769 Systems, Vol. 33, No. 1-3, pp. 131-154, Berlin Heidelberg: 770 Springer, December 2006. 772 48 Fenner, B. et al. "Multicast Source Notification of Interest 773 Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress, 774 expired), March 2004. 776 49 Leoleis, G., Prezerakos, G., Venieris, I. "Seamless multicast 777 mobility support using fast MIPv6 extensions", Computer Comm. 29, 778 pp. 3745-3765, 2006. 780 50 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time 781 Applications", RFC 3550, July 2003. 783 Acknowledgments 785 The authors would like to thank Mark Palkow (DaViKo GmbH) and Hans L. 786 Cycon (FHTW Berlin) for valuable discussions and a joyful 787 collaboration. They also thank Stig Venaas (UNINETT) for many 788 advices. 790 Author's Addresses 792 Thomas C. Schmidt 793 HAW Hamburg, Dept. Informatik 794 Berliner Tor 7 795 D-20099 Hamburg, Germany 796 Phone: +49-40-42875-8157 797 Email: Schmidt@informatik.haw-hamburg.de 799 Matthias Waehlisch 800 link-lab 801 H�nowerstr. 35 802 D-10318 Berlin, Germany 803 Email: mw@link-lab.net 805 Intellectual Property Statement 807 The IETF takes no position regarding the validity or scope of any 808 Intellectual Property Rights or other rights that might be claimed to 809 pertain to the implementation or use of the technology described in 810 this document or the extent to which any license under such rights 811 might or might not be available; nor does it represent that it has 812 made any independent effort to identify any such rights. Information 813 on the procedures with respect to rights in RFC documents can be 814 found in BCP 78 and BCP 79. 816 Copies of IPR disclosures made to the IETF Secretariat and any 817 assurances of licenses to be made available, or the result of an 818 attempt made to obtain a general license or permission for the use of 819 such proprietary rights by implementers or users of this 820 specification can be obtained from the IETF on-line IPR repository at 821 http://www.ietf.org/ipr. 823 The IETF invites any interested party to bring to its attention any 824 copyrights, patents or patent applications, or other proprietary 825 rights that may cover technology that may be required to implement 826 this standard. Please address the information to the IETF at ietf- 827 ipr@ietf.org. 829 Copyright Notice 831 Copyright (C) The IETF Trust (2007). This document is subject 832 to the rights, licenses and restrictions contained in BCP 78, and 833 except as set forth therein, the authors retain all their rights. 835 Disclaimer of Validity 837 "This document and the information contained herein are provided on 838 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 839 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF 840 TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 841 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE 842 USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 843 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 845 Acknowledgement 847 Funding of the RFC Editor function is currently provided by the 848 Internet Society.