MobOpts Research Group Thomas C. Schmidt Internet Draft HAW Hamburg Category: Informational Matthias Waehlisch Expires: August 2008 link-lab February 2008 Multicast Mobility in MIPv6: Problem Statement and Brief Survey IPR Statement By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79 [1]. Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This document is a submission of the IRTF MobOpts RG. Comments should be directed to the MobOpts RG mailing list, mobopts@irtf.org. Abstract This document discusses current mobility extensions to IP layer multicast. Problems arising from mobile group communication in general, in the case of multicast listener mobility and for mobile Any Source Multicast as well as Source Specific Multicast senders are documented. Characteristic aspects of multicast routing and deployment issues for fixed IPv6 networks are summarized. Specific properties and interplays with the underlying network access are surveyed w.r.t. the relevant technologies in the wireless domain. It outlines the principal approaches to multicast mobility. In addition to providing a comprehensive exploration of the mobile multicast Schmidt, Waehlisch Expires - August 2008 [Page 1] MMCASTv6-PS February 2008 problem and solution space, this document attempts to draft a conceptual roadmap for initial steps in standardization for the use of future mobile multicast protocol designers. Table of Contents 1. Introduction and Motivation....................................3 1.1 Document Scope..............................................4 2. Problem Description............................................5 2.1 General Issues..............................................5 2.2 Multicast Listener Mobility.................................7 2.2.1 Node & Application Perspective........................7 2.2.2 Network Perspective...................................8 2.3 Multicast Source Mobility...................................9 2.3.1 Any Source Multicast Mobility.........................9 2.3.2 Source Specific Multicast Mobility...................10 2.4 Deployment Issues..........................................11 3. Characteristics of Multicast Routing Trees under Mobility.....11 4. Link Layer Aspects............................................12 4.1 General Background.........................................12 4.2 Multicast for Specific Technologies........................13 4.2.1 802.11 WLAN..........................................13 4.2.2 802.16 WIMAX.........................................14 4.2.3 3GPP.................................................15 4.2.4 DVB-H / DVB-IPDC.....................................15 4.3 Vertical Multicast Handovers...............................16 5. Solutions.....................................................17 5.1 General Approaches.........................................17 5.2 Solutions for Multicast Listener Mobility..................18 5.2.1 Agent Assistance.....................................18 5.2.2 Multicast Encapsulation..............................18 5.2.3 Hybrid Architectures.................................18 5.2.4 MLD Extensions.......................................19 5.3 Solutions for Multicast Source Mobility....................20 5.3.1 Any Source Multicast Mobility Approaches.............20 5.3.2 Source Specific Multicast Mobility Approaches........20 6. Security Considerations.......................................22 7. Summary and Future Steps......................................22 8. IANA Considerations...........................................23 Schmidt, Waehlisch Expires - August 2008 [Page 2] MMCASTv6-PS February 2008 Appendix A. Implicit Source Notification Options.................23 9. References....................................................23 Acknowledgments..................................................30 Author's Addresses...............................................30 Intellectual Property Statement..................................30 Copyright Notice.................................................31 Disclaimer of Validity...........................................31 Acknowledgement..................................................31 1. Introduction and Motivation Group communication forms an integral building block of a wide variety of applications, ranging from content broadcasting and streaming, voice and video conferencing, collaborative environments and massive multiplayer gaming up to the self-organization of distributed systems, services or autonomous networks. Network layer multicast support will be needed, whenever globally distributed, scalable, serverless or instantaneous communication is required. As broadband media delivery emerges as a typical mass scenario, scalability and bandwidth efficiency of multicast routing continuously gain importance. The early idea of Internet multicasting [2] soon lead to a wide adoption of Deering's host group model [3]. Multicast network support will be of particular importance to mobile environments, where users commonly share frequency bands of limited capacity. The rapidly increasing mobile reception of 'infotainment' streams may soon require a wide deployment of mobile multicast services. Multicast mobility consequently has been a concern for about ten years [4] and has led to numerous proposals, but no generally accepted solution. Mobility in IPv6 [5] is standardized in the Mobile IPv6 RFCs [6,7]. MIPv6 [6] only roughly defines multicast mobility, using a remote subscription approach or through bi-directional tunneling via the Home Agent. Remote subscription suffers from slow handovers, as it relies on multicast routing to adapt to handovers, bi-directional tunneling introduces inefficient overheads and delays due to triangular forwarding, i.e., instead of traveling on shortest paths, packets are routed through the Home Agent. Therefore none of the approaches have been optimized for a large scale deployment. A mobile Schmidt, Waehlisch Expires - August 2008 [Page 3] MMCASTv6-PS February 2008 multicast service for a future Internet should provide 'close to optimal' routing at predictable and limited cost, robustness combined with a service quality compliant to real-time media distribution. Intricate multicast routing procedures, though, are not easily extensible to comply with mobility requirements. Any client subscribed to a group while operating mobility handovers, requires traffic to follow to its new location; any mobile source requests the entire delivery tree to comply with or adapt to its changing positions. Significant effort has already been invested in protocol designs for mobile multicast receivers; only limited work has been dedicated to multicast source mobility, which poses the more delicate problem [59]. In multimedia conference scenarios, games or collaborative environments each member commonly operates as receiver and as sender for multicast based group communication. In addition, real-time communication such as conversational voice or video places severe temporal requirement on mobility protocols: Seamless handover scenarios are expected to limit disruptions or delay to less than 100 ms. Jitter disturbances should not exceed 50 ms. Note that 100 ms is about the duration of a spoken syllable in real-time audio. It is the aim of this document, to specify the problem scope for a multicast mobility management, which may be elaborated in future work. The document subdivides the various challenges according to their originating aspects and presents existing proposals for solution, as well as major bibliographic references. 1.1 Document Scope When considering multicast node mobility, two basic scenarios are of interest: Single-hop mobility (as shown in figure 1.a) and multi-hop mobile routing (figure 1.b). This document adopts single-hop mobility as the focal scenario, which coincides with the perspective of MIPv6 [6]. All key issues of mobile multicast membership control, as well as the interplay of mobile and multicast routing will become apparent in this simpler scenario. Multi-hop network mobility is a subsidiary setting. All major aspects are inherited from the single-hop problem, while additional complexity is incurred from traversing a mobile cloud. This may be solved by encapsulation or flooding (cf. [8] for a general overview). Specific issues arising from (nested) tunneling or flooding, especially the preservation of address transparency, require a treatment in analogy to MIPv6. +------+ +------+ Schmidt, Waehlisch Expires - August 2008 [Page 4] MMCASTv6-PS February 2008 | MN | =====> | MN | +------+ +------+ | . | . | . +-------+ +-------+ | LAR 1 | | LAR 2 | +-------+ +-------+ \ / *** *** *** *** * ** ** ** * +------+ +------+ * * | MN | =====> | MN | * Mobile Network * +------+ +------+ * * | . * ** ** ** * | . *** *** *** *** | . | . +-------+ +-------+ +-------+ +-------+ | AR 1 | | AR 2 | | AR 1 | =====> | AR 2 | +-------+ +-------+ +-------+ +-------+ | | | | *** *** *** *** *** *** *** *** * ** ** ** * * ** ** ** * * * * * * Fixed Internet * * Fixed Internet * * * * * * ** ** ** * * ** ** ** * *** *** *** *** *** *** *** *** a) Single-Hop Mobility b) Multi-Hop Mobility Figure 1: Mobility Scenarios 2. Problem Description 2.1 General Issues Multicast mobility is a generic term, which subsumes a collection of quite distinct functions. At first, multicast communication divides into Any Source Multicast (ASM) [3] and Source Specific Multicast (SSM) [9,10]. At second, the roles of senders and receivers are distinct and asymmetric. Both may individually be mobile. Their interaction is facilitated by a multicast routing protocol such as DVMRP [11], PIM-SM/SSM [12,13], Bi-directional PIM [14], formerly CBT [15], BGMP [16], or inter-domain multicast prefix advertisements via MBGP [17], and a client interaction with the multicast listener discovery protocol (MLD and MLDv2) [18,19]. Schmidt, Waehlisch Expires - August 2008 [Page 5] MMCASTv6-PS February 2008 Any multicast mobility solution must take all of these functional blocks into account. It should enable seamless continuity of multicast sessions when moving from one IPv6 subnet to another. It should preserve the multicast nature of packet distribution and approximate optimal routing. It should support per flow handover for multicast traffic, as properties and designations of flows can be of distinct nature. Such distinctions may result from differing QoS/real-time requirements, but may also be caused by network layer conditions, which need not be identical for all groups. The host group model extends the capability of the network layer unicast service. In common with the architecture of fixed networks, multicast mobility management should transparently utilize or smoothly extend the unicast functions of MIPv6 [6], its security extensions [7,20], its expediting schemes FMIPv6 [21] and HMIPv6 [22], its context transfer protocols [23], its multihoming capabilities [24,25], emerging protocols like PMIPv6 [57] or future developments. From the perspective of an integrated mobility architecture it is desirable to avoid multicast-specific as well as unicast-restricted solutions, whenever general approaches jointly supporting unicast and multicast can be derived. Multicast routing dynamically adapts to the topology of the sender(s) and receiver(s) participating in a multicast session, which then may change under mobility. However, depending on the topology and the protocol in use, current multicast routing protocols may require a time close to seconds, or even minutes to converge following a change in receiver or sender location. This is far too slow to support seamless handovers for interactive or real-time media sessions. The actual temporal behavior strongly depends on the multicast routing protocol in use and on the geometry of the current distribution tree. A mobility scheme that re-adjusts routing, i.e., partially changes or fully reconstructs a multicast tree, is forced to comply with the time scale of protocol convergence. Specifically it needs to consider a possible rapid movement of the mobile node, as this may occur at much higher rates than common protocol state updates. IP layer multicast packet distribution is an unreliable service that is bound to connectionless transport protocols. Where applications are sensitive to packet loss, loss recovery, concealment, etc, counter measures must be performed by the multicast transport or application. Mobile multicast handovers though should not introduce significant additional packet drops. Due to statelessness, the bi- casting of multicast flows does not cause foreseeable degradations at the transport layer. Group addresses in general are location transparent, even though they may be scoped and there are methods that embed unicast prefixes or Rendezvous Point addresses [26]. Addresses of sources contributing to Schmidt, Waehlisch Expires - August 2008 [Page 6] MMCASTv6-PS February 2008 a multicast session are interpreted by the routing infrastructure and by receiver applications, which frequently are source address aware. Multicast therefore inherits the mobility address duality problem for source addresses, being a logical node identifier, i.e., the home address (HoA) on the one hand, and a topological locator, the care- of-address (CoA) on the other. At the network layer, the elements that comprise the delivery tree, i.e., multicast senders, forwarders and receivers, need to carefully account for address duality issues, e.g., by using binding caches, extended multicast states or signaling. Multicast sources in general operate decoupled from their receivers in the following sense: A multicast source sends packets to a group of unknown receivers and thus operates without a feedback channel. It neither has means to inquire on properties of its delivery trees, nor will it be able to learn about the state of its receivers. In the event of an inter-tree handover, a mobile multicast source therefore is vulnerable to loosing receivers without taking notice. (Appendix A describes implicit source notification approaches). Applying a MIPv6 mobility binding update or return routability procedure will similarly break the semantic of a receiver group remaining unidentified by the source and thus cannot be applied in unicast analogy. Despite of the complexity of the requirements, multicast mobility management should seek lightweight solutions with easy deployment. Such realistic, sample deployment scenarios and architectures should be provided in future solution documents. 2.2 Multicast Listener Mobility 2.2.1 Node & Application Perspective A mobile multicast listener entering a new IP subnet requires multicast reception subsequent to handover in real-time. It faces the problem of transferring the multicast membership context from its old to its new point of attachment. This can either be achieved by (re- )establishing a tunnel or by transferring the MLD Listening State information of MN's moving interface(s) to the new upstream router(s). In the latter case, it may encounter either one of the following conditions: The new network may not be multicast-enabled or the specific multicast service may be unavailable, e.g. unsupported or prohibited. Alternatively, the requested multicast service may be supported and enabled in the visited network, but the multicast groups under subscription may not be forwarded to it. Then current distribution trees for the desired groups may only be met at large routing distance. The simplest scenario occurs when data of some, or all, of the subscribed groups of the mobile node are already received Schmidt, Waehlisch Expires - August 2008 [Page 7] MMCASTv6-PS February 2008 by one or several group members in the destination network, and thus multicast streams natively flow on MN’s arrival. The problem of achieving seamless multicast listener handovers is thus threefold: o Ensure multicast reception even in visited networks without appropriate multicast support. o Minimize multicast forwarding delay to provide seamless and fast handovers. Dependant on layer 2 and 3 handover performance, the time available for multicast mobility operations is typically bound to a fraction of 100 ms. o Minimize packet loss and reordering that result from multicast handover management. Moreover, in many wireless regimes it is also desirable to minimize multicast related signaling to preserve the limited resources of battery powered mobile devices and the constrained transmission capacities of the networks. This may lead to a need to restrict MLD queries towards the MN. Multihomed MNs may smooth handoffs by a .make-before-break. approach. This requires a per interface subscription, facilitated by a selective MLD JOIN. Encapsulation on the path between the upstream router and the receiver may cause MTU size conflicts, as commonly path-MTU discovery is unavailable for multicast. In the absence of fragmentation at tunnel entry points, this may disable a group distribution service entirely. 2.2.2 Network Perspective Infrastructure providing corresponding multicast services is required to keep traffic following the mobile without having network functionality compromised. Mobility solutions thus have to face the immediate problems: o Realize native multicast forwarding whenever applicable to preserve network resources, facilitate multipoint distribution capabilities at the link layer and avoid data redundancy. o Activate link layer multipoint services, even if the MN performs only a layer 2 / vertical handover. o Ensure routing convergence, even if the mobile node moves rapidly and performs handovers at high frequency. o Avoid avalanche problems and n-casting, which potentially result from replicated tunnel initiation or redundant forwarding at network nodes. Additional implications for the infrastructure remain. In changing its point of attachment, an exclusive mobile receiver may cause initiation and termination of a group distribution service in the new Schmidt, Waehlisch Expires - August 2008 [Page 8] MMCASTv6-PS February 2008 respectively previous network. Mobility management may issue traffic directives that lead to suboptimal routing, i.e., by erroneous subscriptions following predictive handover operations, or by slow effective leaves caused by MLD querying, or by a rapid departure of the mobile without leaving groups in the previous network at all. Finally, packet duplication and re-ordering may follow a change of topology. 2.3 Multicast Source Mobility 2.3.1 Any Source Multicast Mobility A node submitting data to an ASM group either defines the root of a source specific shortest path tree (SPT), distributing data towards a rendezvous point or receivers, or it forwards data directly down a shared tree, e.g., via encapsulated PIM register messages, or using bi-directional PIM routing. Native forwarding along source specific delivery trees will be bound to the source’s topological network address due to reverse path forwarding (RPF) checks. A mobile multicast source moving to a new subnetwork is only able to either inject data into a previously established delivery tree, which may be a rendezvous point based shared tree, or to (re-)initiate the construction of a multicast distribution tree compliant to its new location. In the latter case, the mobile sender will have to precede without controlling the new tree development due to decoupling of sender and receivers. A mobile multicast source consequently must meet address transparency at two layers: To comply with RPF checks, it has to use an address within the IPv6 basic header's source field, which is in topological concordance with the employed multicast distribution tree. For application transparency the logical node identifier, commonly the HoA, must be presented as the packet source address to the transport layer at the receiver side. Conforming to address transparency and temporal handover constraints pose major problems for any route optimizing mobility solution. Additional issues arise from possible packet loss and from multicast scoping. A mobile source away from home must respect scoping restrictions that arise from its home and its visited location [6]. Within intra-domain multicast routing the use of shared trees may reduce mobility-related complexity. Relying upon a static rendezvous point, a mobile source may continuously submit data by encapsulating packets with its previous topologically correct or home source address. Intra-domain mobility is transparently provided by bi- directional shared domain-spanning trees, when using bi-directional PIM, eliminating the need for tunneling to a rendezvous point. Schmidt, Waehlisch Expires - August 2008 [Page 9] MMCASTv6-PS February 2008 Issues arise in inter-domain multicast, whenever notification of source addresses is required between distributed instances of shared trees. A new CoA acquired after a mobility handover will necessarily be subject to inter-domain record exchange. In presence of embedded rendezvous point addresses [26], e.g., for inter-domain PIM-SM, the primary rendezvous point will be globally appointed and the signaling requirements obsolete. 2.3.2 Source Specific Multicast Mobility Source Specific Multicast has been designed for static addresses of multicast senders. The source addresses in a client subscription to an SSM group is directly used for route identification. Any SSM subscriber is thus forced to know the topological address of the contributor to the group it wishes to join. The SSM source identification invalidates, when topological source addresses change under mobility. Hence client implementations of SSM source filtering MUST be MIPv6 aware in the sense that a logical source identifier (HoA) is correctly mapped to its current topological correspondent (CoA). As a direct consequence, source mobility for SSM packet distribution requires a dedicated conceptual treatment beyond the problem scope of mobile ASM. As a listener is subscribed to an (S,G) channel membership and as routers have established an (S,G)-state shortest path tree rooted at source S, any change of source addresses under mobility requests state updates at all routers on the upstream path and at all receivers in the group. On source handover a new SPT needs to be established, which partly will coincide with the previous SPT, e.g., at the receiver side. As the principle multicast decoupling of a sender from its receivers likewise holds for SSM, client updates needed for switching trees turns into a severe problem. An SSM listener may subscribe to or exclude any specific multicast source, and thereby wants to rely on the topological correctness of network operations. The SSM design permits trust in equivalence to the correctness of unicast routing tables. Any SSM mobility solution should preserve this degree of confidence. Binding updates for SSM sources thus should have to prove address correctness in the unicast routing sense, which is equivalent to binding update security with a correspondent node in MIPv6 [6]. All of the above severely add complexity to a robust SSM mobility solution, which should converge to optimal routes and, for efficiency, should avoid data encapsulation. Like ASM, handover management is a time-critical operation. The routing distance between subsequent points of attachment, the 'step size' of the mobile from Schmidt, Waehlisch Expires - August 2008 [Page 10] MMCASTv6-PS February 2008 previous to next designated router, may serve as an appropriate measure of complexity [27,28]. Finally, Source Specific Multicast has been designed as a light- weight approach to group communication. In adding mobility management, it is desirable to preserve the principle leanness of SSM by minimizing additional signaling overheads. 2.4 Deployment Issues IP multicast deployment in general has been hesitant over the past 15 years, even though all major router vendors and operating systems offer implementations that support multicast [29]. While many (walled) domains or enterprise networks operate point-to-multipoint services, IP multicast rollout is currently limited in public inter- domain scenarios [30]. A dispute arose on the appropriate layer, where group communication service should reside, and the focus of the research community turned towards application layer multicast. This debate on "efficiency versus deployment complexity" now overlaps the mobile multicast domain [31]. Garyfalos and Almeroth [32] derived from fairly generic principles that when mobility is introduced the performance gap between IP and application layer multicast widens in different metrics up to a factor of four. Facing deployment complexity, it is desirable that any solution for mobile multicast should leave routing protocols unchanged. Mobility management in such deployment-friendly scheme should preferably be handled at edge nodes, preserving a mobility agnostic routing infrastructure. Future research needs to search for such simple, infrastructure transparent solutions, even though there are reasonable doubts, whether the desired can be achieved in all cases. Nevertheless, multicast services in mobile environments may soon become indispensable, when multimedia distribution services such as DVB-H [33] or IPTV will develop as a strong business cases for IP portables. As IP mobility will unfold dominance and as efficient link utilization will show a larger impact in costly radio environments, the evolution of multicast protocols will naturally follow mobility constraints. 3.Characteristics of Multicast Routing Trees under Mobility Multicast distribution trees have been studied from a focus of network efficiency. Grounded on empirical observations Chuang and Sirbu [34] proposed a scaling power-law for the total number of links in a multicast shortest path tree with m receivers (prop. m^k). The authors consistently identified the scale factor to attain the independent constant k = 0.8. The validity of such universal, heavy- Schmidt, Waehlisch Expires - August 2008 [Page 11] MMCASTv6-PS February 2008 tailed distribution suggests that multicast shortest path trees are of self-similar nature with many nodes of small, but few of higher degrees. Trees consequently would be shaped rather tall than wide. Subsequent empirical and analytical work [35,36] debated the applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. [35] proved that the proposed power law cannot hold for an increasing Internet or very large multicast groups, but is indeed applicable for moderate receiver numbers and the current Internet size N = 10^5 core nodes. Investigating self-similarity Janic and Van Mieghem [37] semi- empirically substantiated that multicast shortest path trees in the Internet can be modeled with reasonable accuracy by uniform recursive trees (URT) [38], provided m remains small compared to N. The mobility perspective on shortest path trees focus on their alteration, i.e., the degree of topological changes induced by movement. For receivers, and more interestingly for sources this may serve as an outer measure for routing complexity. Mobile listeners moving to neighboring networks will only alter tree branches extending over a few hops. Source specific multicast trees subsequently generated from source handover steps are not independent, but highly correlated. They most likely branch to the identical receivers at one or several intersection points. By the self-similar nature, the persistent subtrees (of previous and next distribution tree), rooted at any such intersection point, exhibit again the scaling law behavior, are tall-shaped with nodes of mainly low degree and thus likely to coincide. Tree alterations under mobility have been studied in [28], both analytically and by simulations. It was found that even in large networks and for moderate receiver numbers more than 80 % of the multicast router states remain invariant under a source handover. 4. Link Layer Aspects 4.1 General Background Scalable group data distribution has the highest potential in leaf networks, where large numbers of end systems reside. Consequently, it is not surprising that most LAN network access technologies natively support point-to-multipoint or multicast services. Of focal interest to the mobility domain are wireless access technologies, which always operate on a shared medium of limited frequencies and bandwidth. Several aspects need consideration: First, dissimilar network access radio technologies cause distinct group traffic transmissions. There are: Schmidt, Waehlisch Expires - August 2008 [Page 12] MMCASTv6-PS February 2008 o connection-less link services of broadcast type, which mostly are bound to limited reliability; o connection-oriented link services of point-to-multipoint type, which require more complex control and frequently exhibit reduced efficiency; o connection oriented link services of broadcast type, which are restricted to unidirectional data transmission. Second, point-to-multipoint service activation at the network access layer requires a mapping mechanism from network layer requests. This function is commonly achieved by L3 awareness, i.e., IGMP/MLD snooping [63], which occasionally is complemented by Multicast VLAN Registration (MVR). MVR allows sharing of a single multicast IEEE 802.1Q Virtual LAN in the network, while subscribers remain in separate VLANs. This layer 2 separation of multicast and unicast traffic can be employed as a workaround for point-to-point link models to establish a common multicast link. Thirdly, an address mapping between the layers is needed for common group identification. Address resolution schemes depend on framing details for the technologies in use, but commonly cause a significant address overlap at the lower layer. 4.2 Multicast for Specific Technologies 4.2.1 802.11 WLAN IEEE 802.11 WLAN is a broadcast network of Ethernet type, which inherits multicast address mapping concepts from 802.3. In infrastructure mode an access point operates as repeater, only bridging data between the Base (BSS) and the Extended Service Set (ESS). A mobile node submits multicast data to an access point in point-to-point acknowledged unicast mode (when the ToDS bit is set). An access point receiving multicast data from a MN simply repeats multicast frames to the BSS and propagates them to the ESS as unacknowledged broadcast. Multicast frames received from the ESS are analogously treated. Multicast frame delivery has the following characteristics: o As an unacknowledged service it attains limited reliability. Frames (and hence packet) loss arises from interference, collision, or time-varying channel properties. o Data distribution may be delayed, as unicast power save synchronization via Traffic Indication Messages (TIM) does not apply. Schmidt, Waehlisch Expires - August 2008 [Page 13] MMCASTv6-PS February 2008 Access points buffer multicast packets while waiting for a larger DTIM interval, whenever stations use the power saving mode. o Multipoint data may cause congestion, as the distribution system floods multicast. Without further control, all access points of the same subnet replicate multicast frames. To limit or prevent the latter, many vendors have implemented configurable rate limiting for multicast packets. Additionally, IGMP/MLD snooping may be active at the bridging layer between the BSS and the ESS or at switches interconnecting access points. 4.2.2 802.16 WIMAX IEEE 802.16 WIMAX combines a family of connection-oriented radio transmission services, operating in distinguished, unidirectional channels. The channel assignment is controlled by Base Stations, which assign channel IDs (CIDs) within service flows to the subscriber stations. Service flows may provide an optional Automatic Repeat Request (ARQ) to improve reliability and may operate in point- to-point or point-to-multipoint (without ARQ) mode. A WIMAX Base Station operates as L2 switch in full duplex mode, where switching is based on CIDs. Two possible IPv6 link models for mobile access deployment scenarios exist: Shared IPv6 prefix and point-to- point link model [39]. The latter treats each connection to a mobile node as a single link, which on the IP layer conflicts with a consistent group distribution via a shared medium (cf. section 4.1 for a workaround). To invoke a multipoint data channel, the base station assigns a common CID to all Subscriber Stations in the group. An IPv6 multicast address mapping to these 16 bit IDs is proposed by copying either the 4 lowest bits, while sustaining the scope field, or by utilizing the 8 lowest bits derived from Multicast on Ethernet CS [40]. For selecting group members, a Base Station may implement IGMP/MLD snooping or IGMP/MLD proxying as foreseen in 802.16e-2005 [41]. A Subscriber Station will send multicast data to a Base Station as a point-to-point unicast stream, which is forwarded to the upstream access router. The access router may return multicast data to the downstream Base Station by feeding into a multicast service channel. On reception a Subscriber Station cannot distinguish multicast from unicast streams. Multicast services have the following characteristics: Schmidt, Waehlisch Expires - August 2008 [Page 14] MMCASTv6-PS February 2008 o The mapping of multicast addresses to CIDs needs standardization, since different entities (Access Router, Base Station) may have to perform the mapping. o CID collisions for different multicast groups are very likely due to the short ID space. As a consequence, multicast data transmission may occur in joint point-to-multipoint groups of reduced selectiveness. o The point-to-point link model for mobile access contradicts a consistent mapping of IP layer multicast onto 802.16 point-to- multipoint services. o Multipoint channels cannot operate ARQ service and thus experience a reduced reliability. 4.2.3 3GPP The 3GPP System architecture spans a circuit switched (CS) and a packet switched (PS) domain, the latter General Packet Radio Services (GPRS) incorporates the IP Multimedia Subsystem (IMS) [42]. 3GPP PS is connection-oriented and based on the concept of Packet Data Protocol (PDP) Contexts. PDPs define point-to-point links between the Mobile Terminal and the Gateway GPRS Support Node (GGSN). Internet service types are PPP, IPv4 and IPv6, where the recommendation for IPv6 address assignment associates a prefix to each (primary) PDP context [43]. Current packet filtering practice causes inter-working problems between Mobile IPv6 nodes connected via GPRS [44]. As of UMTS Rel. 6 the IMS has been extended to include Multimedia Broadcast and Multicast Services (MBMS). A point-to-multipoint GPRS connection service is operated on radio links, while the gateway service to Internet multicast is handled at the IGMP/MLD-aware GGSN. Local multicast packet distribution is used within the GPRS IP backbone resulting in the common double encapsulation at GGSN: global IP multicast datagrams over GTP (with multipoint TID) over local IP multicast. The 3GPP MBMS has the following characteristics: o There is no immediate layer 2 source-to-destination transition, resulting in transition of all multicast traffic at the GGSN. o As GGSN commonly are regional, distant entities, triangular routing and encapsulation may cause a significant degradation of efficiency. 4.2.4 DVB-H / DVB-IPDC Schmidt, Waehlisch Expires - August 2008 [Page 15] MMCASTv6-PS February 2008 Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional physical layer broadcasting specification for the efficient delivery of broadband, IP-encapsulated data streams. It was formally adopted as ETSI standard [45] (see http://www.dvb-h.org). DVB uses a mechanism called multi-protocol encapsulation (MPE), which enables a transport of network layer protocols on top of a link layer built from MPEG-2 transport streams and includes a forward error correction (FEC). Thereby DVB cannot only support TV broadcasting, but offers an IP Datacast Service. DVB-IPDC [33] consists of a number of individual, application layer specifications, some of which are still under development. Transport Streams (TS) form the basic logical channels, identified by a 13 bit TS ID (PID). This together with a multiplex service ID is associated with IPv4 or IPv6 addresses [46] and used for selective traffic filtering at receivers. Upstream channels may complement DVB-H by means of alternative technologies. Multicast distribution services are defined by a mapping of groups onto appropriate PIDs, which is managed at the IP Encapsulator [47]. To increase flexibility and avoid collisions, this address resolution is facilitated by dynamic tables, provided within the self-consistent MPEG-2 TS. Mobility is supported in the sense that changes of cell ID, network ID or Transport Stream ID are foreseen [48]. A multicast receiver thus needs to re-locate multicast services it is subscribed to, which is to be done in the synchronization phase, and update its service filters. Its handover decision may depend on service availability. An active service subscription (multicast join) will need initiation at the IP Encapsulator / DVB-H Gateway, which cannot be achieved in a pure DVB-H network setup. 4.3 Vertical Multicast Handovers A mobile multicast node may operate homogeneous (horizontal) or heterogeneous (vertical) layer 2 handovers with or without layer 3 network changes. Consequently, multicast configuration context transfer at network access' needs dedicated treatment. Media Independent Handover (MIH) is addressed in IEEE 802.21 [49], but is relevant also beyond IEEE protocols. Mobility services transport for MIH naturally reside on the network layer and are currently in the process of specification [50]. MIH needs to assist in more than service discovery. Keeping in mind complex, media dependent multicast adaptations, a possible absence of MLD signaling in L2-only transfers and requirements originating from predictive handovers, a multicast mobility services transport needs to be sufficiently comprehensive and abstract to initiate a seamless multicast handoff at network access. Functions required for MIH include: Schmidt, Waehlisch Expires - August 2008 [Page 16] MMCASTv6-PS February 2008 o Service discovery o Service context transformation o Service context transfer o Service invocation. 5. Solutions 5.1 General Approaches Three approaches to mobile Multicast are common [51]: o Bi-directional Tunnelling, in which the mobile node tunnels all multicast data via its home agent. This fundamental multicast solution hides all movement and results in static multicast trees. It may be employed transparently by mobile multicast listeners and sources, at the cost of triangular routing and possibly significant performance degradations due to widely spanned data tunnels. o Remote Subscription forces the mobile node to re-initiate multicast distribution subsequent to handover, e.g., by submitting an MLD listener report within the subnet a receiver newly attaches to. This approach of tree discontinuation relies on multicast dynamics to adapt to network changes. It not only results in rigorous service disruption, but leads to mobility-driven changes of source addresses, and thus cannot support session persistence under multicast source mobility. o Agent-based solutions attempt to balance between the previous two mechanisms. Static agents typically act as local tunnelling proxies, allowing for some inter-agent handover when the mobile node moves. A decelerated inter-tree handover, i.e. 'tree walking', will be the outcome of agent-based multicast mobility, where some extra effort is needed to sustain session persistence through address transparency of mobile sources. MIPv6 [6] introduces bi-directional tunnelling as well as remote subscription as minimal standard solutions. Various publications suggest utilizing remote subscription for listener mobility only, while advising bi-directional tunnelling as the solution for source mobility. Such an approach avoids the 'tunnel convergence' or 'avalanche' problem [51], which refers to the responsibility of the home agent to multiply and encapsulate packets for many receivers of the same group, even if they are located within the same subnetwork. However, it suffers from the drawback that multicast communication roles are not explicitly known at the network layer and may change or mix unexpectedly. Schmidt, Waehlisch Expires - August 2008 [Page 17] MMCASTv6-PS February 2008 None of the above approaches address SSM source mobility, except the bi-directional tunnelling. 5.2 Solutions for Multicast Listener Mobility 5.2.1 Agent Assistance There are proposals for agent assisted handovers for host based mobility, which complement the unicast real-time mobility infrastructure of Fast MIPv6 [21], the M-FMIPv6 [52,53], and of Hierarchical MIPv6 [22], the M-HMIPv6 [54], and to context transfer [55], which have been thoroughly analyzed in [27,56]. Network based mobility management, PMIPv6 [57], at its current stage remains multicast transparent, as the MN experiences a point-to-point home link fixed at its local mobility anchor (LMA). A PMIPv6 domain thereby inherits the tunnel convergence problem; future optimizations and extensions to shared links should foresee native multicast distribution towards the edge network, including context transfer between access gateways to aid the IP-mobility-agnostic MNs. An approach based on dynamically negotiated inter-agent handovers is presented in [58]. Aside from IETF work, countless publications present proposals for seamless multicast listener mobility, e.g. [59] provides a comprehensive overview. 5.2.2 Multicast Encapsulation Encapsulation of multicast data packets is an established method to shield mobility and to enable access to remotely located data services, e.g., streams from the home network. Applying generic packet tunnelling in IPv6 [60] in a unicast point-to-point way will in addition bridge multicast-agnostic domains, but inherits the tunnel convergence problem and may cause traffic multiplication. Multicast enabled environments may take advantage of point-to- multipoint encapsulation, i.e., generic packet tunnelling using an appropriate multicast destination address in the outer header. Such multicast-in-multicast encapsulated packets likewise enable reception of remotely located streams, but do not suffer from the scaling deficiencies of unicast tunnels. For any use of encapsulation, the tunnelling entry point should provide fragmentation to keep data packets within MTU size constraints. 5.2.3 Hybrid Architectures Stimulated by the desire to avoid complexity at the Internet core network, application layer and overlay proposals for (mobile) Schmidt, Waehlisch Expires - August 2008 [Page 18] MMCASTv6-PS February 2008 multicast have recently raised interest. The possibility of integrating multicast distribution on the overlay into the network layer is being considered by the IRTF Scalable Adaptive Multicast Research Group (SAM). An early hybrid architecture of reactively operating proxy-gateways located at the Internet edges was introduced by Garyfalos and Almeroth [32]. The authors present Intelligent Gateway Multicast as a bridge between mobility aware native multicast management in access networks and mobility group distribution services in the Internet core, which may be operated on the network or application layer. For such hybrid architectures, a mobility-agnostic multicast backbone on the overlay has been introduced in the Hybrid Shared Tree approach [61]. Currently SAM is developing general architectural approaches for hybrid multicast solutions [62], which will require detailed design in future work. 5.2.4 MLD Extensions MLD timer defaults [19] cause slow reaction of the multicast routing infrastructure as well as of layer-3-aware access devices [63] on client leaves, which may be disadvantageous for wireless links. This tardy adaptation may be improved by carefully adjusting the Query Interval. Alternatively, vendors have implemented listener node tables at access routers to eliminate query timeouts on leaves (explicit tracking). A MN operating predictive handover, e.g., using FMIPv6, may accelerate multicast service termination in the previous network by submitting an early Done before handoff. MLD router Querying will allow for a possible withdrawal in case of an erroneous prediction. Backward context transfer may be used to ensure leave signalling, otherwise. A further optimization is introduced by Jelger and Noel [64] for the special case of the HA being a multicast router. A Done message received through a tunnel from the mobile end node (through a point-to-point link directly connecting the MN, in general), should not initiate regular MLD membership queries with subsequent timeout. Such explicit treatment of point-to-point links will reduce traffic and accelerate the control protocol. Explicit tracking will cause identical protocol behaviour. While away from home, a MN may wish to rely on a proxy or standby multicast membership service, optionally provided by a HA or proxy agent. Such function relies on the ability to restart fast packet forwarding; it may be desirable for the proxy router to remain part of the multicast delivery tree, even though transmission of group data is paused. To enable such proxy control, the authors in [64] Schmidt, Waehlisch Expires - August 2008 [Page 19] MMCASTv6-PS February 2008 propose to extend MLD by a Listener Hold message exchanged between MN and HA. This idea has been taken up in [54] and further developed to a multicast router attendance control, allowing for a general deployment of group membership proxies. Currently deployed IPTV solutions use such mechanism in combination with a recent (video) frame buffer, to enable fast channel switching (zapping). 5.3 Solutions for Multicast Source Mobility 5.3.1 Any Source Multicast Mobility Approaches Solutions for the multicast source mobility problem can be devided in three categories: o Statically Rooted Distribution Trees: Following a shared tree approach, Romdhani et al. [65] propose to employ Rendezvous Points of PIM-SM as mobility anchors. Mobile senders tunnel their data to these "Mobility-aware Rendezvous Points" (MRPs). When restricted to a single domain this scheme is equivalent to bi-directional tunneling. Focusing on interdomain mobile multicast, the authors design a tunnel- or SSM-based backbone distribution of packets between MRPs. o Reconstruction of Distribution Trees: Several authors propose construction of a completely new distribution tree after the movement of a mobile source and therefore have to compensate routing delays. M-HMIPv6 [54] tunnels data into previously established trees rooted at mobility anchor points to compensate for routing delays until a protocol dependent timer expires. The RBMoM protocol [66] introduces additional Multicast Agents (MA) that advertise their service range. The mobile source registers with the closest MA and tunnels data through it. When moving out of the previous service range, it will perform MA discovery, a re- registration and continue data tunneling with a newly established Multicast Agent in its current vicinity. o Tree Modification Schemes: In the case of DVMRP routing, Chang and Yen [67] propose an algorithm to extend the root of a given delivery tree for incorporating a new source location in ASM. To fix DVMRP forwarding states and heal reverse path forwarding (RPF) check failures, the authors rely on a complex additional signaling protocol. 5.3.2 Source Specific Multicast Mobility Approaches Schmidt, Waehlisch Expires - August 2008 [Page 20] MMCASTv6-PS February 2008 The shared tree approach of [65] has been extended to SSM mobility by introducing the HoA address record to Mobility-aware Rendezvous Points. These MRPs operate on extended multicast routing tables, which simultaneously hold HoA and CoA and are thus enabled to logically identify the appropriate distribution tree. Mobility thus re-introduces rendezvous points to SSM routing. Approaches of reconstructing SPTs in SSM have to rely on client notification for initiating new router state establishment. At the same time they need to preserve address transparency to the client. To account for the latter, Thaler [68] proposes binding caches and obtaining source address transparency analogous to MIPv6 unicast communication. Initial session announcements and changes of source addresses are distributed periodically to clients via an additional multicast control tree rooted at the home agent. Source tree handovers are then activated on listener requests. Jelger and Noel [69] suggest handover improvements by employing anchor points within the source network, supporting continuous data reception during client initiated handovers. Client updates are to be triggered out of band, e.g. by SDR. Receiver-oriented tree construction in SSM thus remains unsynchronized with the source handovers. To address this synchronization problem at the routing layer, several proposals concentrate on direct modification of distribution trees. Based on a multicast Hop-by-Hop protocol, a recursive scheme of loose unicast source routes with branch points, Vida et al [70] optimize SPTs for moving sources on the path between source and first branching point. O'Neill [71] suggests a scheme to overcome RPF check failures originating from multicast source address changes in a rendezvous point scenario by introducing extended routing information, which accompanies data in a Hop-by-Hop option "RPF redirect" header. The Tree Morphing approach of Schmidt and Waehlisch [72] uses source routing to extend the root of a previously established SPT, thereby injecting router state updates in a Hop-by- Hop option header. Using extended RPF checks the elongated tree autonomously initiates shortcuts and smoothly reduces to a new SPT rooted at the relocated source. Lee et al. [73] introduce a state update mechanism for re-using major parts of established multicast trees. The authors start from an initially established distribution state centered at the mobile source's home agent. A mobile leaving its home network will signal a multicast forwarding state update on the path to its home agent and, subsequently, distribution states according to the mobile source's new CoA are implemented along the previous distribution tree. Multicast data then is intended to natively flow in triangular routes via the elongation and updated tree centered at the home agent. Schmidt, Waehlisch Expires - August 2008 [Page 21] MMCASTv6-PS February 2008 6. Security Considerations This document discusses multicast extensions to mobility. It does not define new methods or procedures. Security issues arise from source address binding updates, specifically in the case of source specific multicast. Threats of hijacking unicast sessions will result from any solution jointly operating binding updates for unicast and multicast sessions. Admission control issues may arise with new CoA source addresses being introduced to SSM channels (cf. [74] for a comprehensive discussion). Due to lack of feedback, admissions [75] and binding updates [76] of mobile multicast sources require self- consistent authentication as achievable by CGAs. Future solutions must address the security implications. 7.Summary and Future Steps This memo is intended to support a future design of mobile multicast methods and protocols by o providing a structured overview of the problem space that multicast and mobility jointly generate at the IPv6 layer; o referencing the implications and constraints arising from lower and upper layers, and from deployment; o briefly surveying conceptual ideas for currently available solutions; o including a comprehensive bibliographic reference base. It is recommended that future steps towards extending mobility services to multicast proceed to first solve the following problems: 1. Ensure seamless multicast reception during handovers, meeting the requirements of mobile IPv6 nodes and networks. Thereby address the problems of home subscription without n-tunnels, as well as native multicast reception in those visited networks, which offer a group communication service. 2. Integrate multicast listener support into unicast mobility management schemes and architectural entities to define a consistent mobility service architecture, providing equal supporting for unicast and multicast communication. 3. Provide basic multicast source mobility by designing address duality management at end nodes. Schmidt, Waehlisch Expires - August 2008 [Page 22] MMCASTv6-PS February 2008 8. IANA Considerations There are no IANA considerations introduced by this draft. Appendix A. Implicit Source Notification Options A multicast source will transmit data to a group of receivers without the option of an explicit feedback channel. There are attempts though to implicitly obtain information on listening group members. One proposed approach allowed an IGMP/MLD querier to be informed of the pure existence of receivers. Based on an extension of IGMP, the Multicast Source Notification of Interest Protocol (MSNIP) [77] was designed to allow for the multicast source querying its designated router. However, work on MSNIP has been terminated by IETF. A majority of real-time applications employ RTP [78] as its application layer transport protocol, which is accompanied by its control protocol RTCP. RTP is capable of multicast group distribution and RTCP receiver reports are submitted to the same group in the multicast case. Thus RTCP may be used to monitor, manage and control multicast group operations, as it provides a fairly comprehensive insight into group member statuses. However, RTCP information is neither present at the network layer nor does multicast communication presuppose the use of RTP. 9. References Informative References 1 S. Bradner "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3979, March 2005. 2 Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, ACM Press, June, 1984. 3 S. Deering "Host Extensions for IP Multicasting", RFC 1112, August 1989. 4 G. Xylomenos and G.C. Plyzos "IP Multicast for Mobile Hosts", IEEE Communications Magazine, 35(1), pp. 54-58, January 1997. 5 R. Hinden and S. Deering "Internet Protocol Version 6 Specification", RFC 2460, December 1998. Schmidt, Waehlisch Expires - August 2008 [Page 23] MMCASTv6-PS February 2008 6 D.B. Johnson, C. Perkins and J. Arkko "Mobility Support in IPv6", RFC 3775, June 2004. 7 V. Devarapalli and F. Dupont "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007. 8 Akyildiz, I and Wang, X. "A Survey on Wireless Mesh Networks", IEEE Communications Magazine, 43(9), pp. 23-30, September 2005. 9 S. Bhattacharyya "An Overview of Source-Specific Multicast (SSM)", RFC 3569, July 2003. 10 H. Holbrook, B. Cain "Source-Specific Multicast for IP", RFC 4607, August 2006. 11 D. Waitzman, C. Partridge, S.E. Deering "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988. 12 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M. Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998. 13 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas: "Protocol Independent Multicast - Sparse Mode PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. 14 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October 2007. 15 A. Ballardie "Core Based Trees (CBT version 2) Multicast Routing", RFC 2189, September 1997. 16 D. Thaler "Border Gateway Multicast Protocol (BGMP): Protocol Specification", RFC 3913, September 2004. 17 T. Bates et al. "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007. 18 S. Deering, W. Fenner and B. Haberman "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. 19 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Schmidt, Waehlisch Expires - August 2008 [Page 24] MMCASTv6-PS February 2008 20 Arkko, J., Vogt, C., Haddad, W. "Enhanced Route Optimization for Mobile IPv6", RFC 4866, May 2007. 21 Koodli, R. "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. 22 Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L. "Hierarchical Mobile IPv6 mobility management", RFC 4140, August 2005. 23 Loughney, J., Nakhjiri, M., Perkins, C., Koodli, R. "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 24 Montavont, N., et al. "Analysis of Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-04, Internet Draft - (work in progress), November 2007. 25 Narayanan, V., Thaler, D., Bagnulo, M., Soliman, H. "IP Mobility and Multi-homing Interactions and Architectural Considerations", draft-vidya-ip-mobility-multihoming-interactions-01.txt, Internet Draft - (work in progress), July 2007. 26 Savola, P., Haberman, B. "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004. 27 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive - Analysis of Handover Performance and Its Implications on IPv6 and Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123- 142, November 2005. 28 Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On the Evolution of Multicast States under Mobility and an Adaptive Routing Scheme for Mobile SSM Sources", Telecommunication Systems, Vol. 33, No. 1-3, pp. 131-154, Berlin Heidelberg: Springer, December 2006. 29 Diot, C. et al. "Deployment Issues for the IP Multicast Service and Architecture", IEEE Network Magazine, spec. issue on Multicasting 14(1), pp. 78-88, 2000. 30 Eubanks, M.: http://multicasttech.com/status/, 2007. 31 Garyfalos, A., Almeroth, K. and Sanzgiri, K. "Deployment Complexity Versus Performance Efficiency in Mobile Multicast", Intern. Workshop on Broadband Wireless Multimedia: Algorithms, Architectures and Applications (BroadWiM), San Jose, California, USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM- 04.pdf.gz Schmidt, Waehlisch Expires - August 2008 [Page 25] MMCASTv6-PS February 2008 32 Garyfalos, A., Almeroth, K. "A Flexible Overlay Architecture for Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm., 23 (11), pp. 2194-2205, November 2005. 33 "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of Specifications for Phase 1", ETSI TS 102 468; "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Implementation Guidelines for Mobility", ETSI TS 102 611. 34 Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A Cost- Based Approach", Telecommunication Systems 17(3), 281-297, 2001. Presented at the INET'98, Geneva, Switzerland, July 1998. 35 Van Mieghem, P., Hooghiemstra, G., Hofstad, R. "On the Efficiency of Multicast", Transactions on Networking, 9, 6, pp. 719-732, December 2001. 36 Chalmers, R.C. and Almeroth, K.C., "On the topology of multicast trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003. 37 Janic, M. and Van Mieghem, P. "On properties of multicast routing trees", Int. J. Commun. Syst. 19(1), pp. 95-114, 2006. 38 Van Mieghem, P. "Performance Analysis of Communication Networks and Systems", Cambridge University Press, 2006. 39 Shin, M. et al. "IPv6 Deployment Scenarios in 802.16 Networks", draft-ietf-v6ops-802-16-deployment-scenarios-07, (work in progress), Januar 2008. 40 Kim, S. et al. "Multicast Transport on IEEE 802.16 Networks", draft-sekim-802-16-multicast-01, (work in progress), July 2007. 41 IEEE 802.16e-2005: IEEE Standard for Local and metropolitan area networks Part 16: "Air Interface for Fixed and Mobile Broadband Wireless Access Systems Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operation in Licensed Bands.", New York, February 2006. 42 3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; IP Multimedia Subsystem (IMS); Stage 2, 3GPP TS 23.228, Rel. 5 ff., 2002 – 2007. 43 Wasserman, M. "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002. Schmidt, Waehlisch Expires - August 2008 [Page 26] MMCASTv6-PS February 2008 44 Chen, X., Rinne, J. and Wiljakka, J. "Problem Statement for MIPv6 Interactions with GPRS/UMTS Packet Filtering", draft-chen-mip6- gprs-07.txt, (work in progress), January 2007. 45 ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission System for Handheld Terminals (DVB-H)", European Standard (Telecommunications series), November 2004. 46 Fairhurst, G. and Montpetit, M. "Address Resolution Mechanisms for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007. 47 Montpetit, M. et al. "A Framework for Transmission of IP Datagrams over MPEG-2 Networks", RFC 4259, November 2005. 48 Yang, X., Vare, J., Owens, T. "A Survey of Handover Algorithms in DVB-H", IEEE Comm. Surveys, 8(4), 2006. 49 "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE LAN/MAN Draft IEEE P802.21/D07.00, July 2007. 50 Melia, T. et al. "Mobility Services Transport: Problem Statement", draft-ietf-mipshop-mis-ps-05, (work in progress), November 2007. 51 Jannetau, C., Tian, Y., Csaba, S. et al "Comparison of Three Approaches Towards Mobile Multicast", IST Mobile Summit 2003, Aveiro, Portugal, 16-18 June 2003, online http://www.comnets.rwth- aachen.de/~o_drive/publications/ist-summit-2003-IPMobileMulticast- paperv2.0.pdf. 52 Suh, K., Kwon, D.-H., Suh, Y.-J. and Park, Y. "Fast Multicast Protocol for Mobile IPv6 in the fast handovers environments", Internet Draft - (work in progress, expired), February 2004. 53 Xia, F. and Sarikaya, B. "FMIPv6 extensions for Multicast Handover", draft-xia-mipshop-fmip-multicast-01, (work in progress, expired), March 2007. 54 Schmidt, T.C. and Waehlisch, M. "Seamless Multicast Handover in a Hierarchical Mobile IPv6 Environment(M-HMIPv6)", draft-schmidt- waehlisch-mhmipv6-04.txt, (work in progress, expired), December 2005. 55 Jonas, K. and Miloucheva, I. "Multicast Context Transfer in mobile IPv6", draft-miloucheva-mldv2-mipv6-00.txt, (work in progress, expired), June 2005. Schmidt, Waehlisch Expires - August 2008 [Page 27] MMCASTv6-PS February 2008 56 Leoleis, G., Prezerakos, G., Venieris, I. "Seamless multicast mobility support using fast MIPv6 extensions", Computer Comm. 29, pp. 3745-3765, 2006. 57 Gundavelli, S., et al. "Proxy Mobile IPv6", draft-ietf-netlmm- proxymip6, (work in progress), February 2008. 58 Zhang, H. et al "Mobile IPv6 Multicast with Dynamic Multicast Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in progress), January 2007. 59 Romdhani, I., Kellil, M., Lach, H.-Y. et. al. "IP Mobile Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004. 60 Conta, A, Deering, S. "Generic Packet Tunneling in IPv6 - Specification", RFC 2473, December 1998. 61 Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On Deployable, Efficient, Mobility-agnostic Group Communication Services", Internet Research, 17 (5), pp. 519-534, Emerald Insight, Bingley, UK, November 2007. 62 Buford, J. "Hybrid Overlay Multicast Framework", draft-irtf-sam- hybrid-overlay-framework-01.txt, Internet Draft (work in progress), January 2007. 63 Christensen, M., Kimball, K. and Solensky, F. "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006. 64 Jelger, C., Noel, T. "Multicast for Mobile Hosts in IP Networks: Progress and Challenges", IEEE Wirel. Comm., pp 58-64, Oct. 2002. 65 Romdhani, I., Bettahar, H. and Bouabdallah, A. "Transparent handover for mobile multicast sources", in P. Lorenz and P. Dini, eds, 'Proceedings of the IEEE ICN'06', IEEE Press, 2006. 66 Lin, C.R. et al., "Scalable Multicast Protocol in IP-Based Mobile Networks", Wireless Networks and Applications, 5, pp. 259-271, 2000. 67 Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with Dynamic Tree Adjustment for Mobile IPv6", Journ. Information Science and Engineering 20, pp. 1109-1124, 2004. Schmidt, Waehlisch Expires - August 2008 [Page 28] MMCASTv6-PS February 2008 68 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings of ietf meeting Dec. 2001, individual. URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf 69 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6 (MSSMSv6)", Internet Draft (work in progress, expired), January 2002. 70 Vida, R., Costa, L., Fdida, S. "M-HBH - Efficient Mobility Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 2002. 71 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill- mip-multicast-00.txt, (work in progress, expired), July 2002. 72 Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 - Problems, Solutions and Improvements", Computational Methods in Science and Technology 11(2), pp. 147-152. Selected Papers from TERENA Networking Conference, Poznan, May 2005. 73 Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source Mobility in Source Specific Multicast", in K. Kawahara and I. Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp. 82-91, Springer-Verlag, Berlin, Heidelberg, 2006. 74 Kellil, M., Romdhani, I., Lach, H.-Y., Bouabdallah, A. and Bettahar, H. "Multicast Receiver and Sender Access Control and its Applicability to Mobile IP Environments: A Survey", IEEE Comm. Surveys & Tutorials 7(2), pp. 46-70, 2005. 75 Castellucia, C., Montenegro, G. "Securing Group Management in IPv6 with Cryptographically Based Addresses", Proc. 8th IEEE Int'l Symp. Comp. and Commun., Turkey, July 2003, pp. 588-93. 76 Christ, O., Schmidt, T.C., Waehlisch, M. "A Light-Weight Implementation Scheme of the Tree Morphing Protocol for Mobile Multicast Sources ", Proc. of 33rd Euromicro Conf., pp. 149-156, IEEE/CS Press, Sept. 2007. 77 Fenner, B. et al. "Multicast Source Notification of Interest Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress, expired), March 2004. 78 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time Applications", RFC 3550, July 2003. Schmidt, Waehlisch Expires - August 2008 [Page 29] MMCASTv6-PS February 2008 Acknowledgments Work on exploring the problem space for mobile multicast has been pioneered by Greg Daley and Gopi Kurup within their early draft "Requirements for Mobile Multicast Clients" (draft-daley-magma- mobile). Since then, many people have actively discussed the different issues and contributed to the enhancement of this memo. The authors would like to thank (in alphabetical order) Kevin C. Almeroth, Hans L. Cycon, Hui Deng, Gorry Fairhurst, Zhigang Huang, Christophe Jelger, Rajeev Koodli, Mark Palkow, Imed Romdhani, Hesham Soliman and last but not least very special thanks to Stig Venaas for his frequent and thorough advice. Author's Addresses Thomas C. Schmidt HAW Hamburg, Dept. Informatik Berliner Tor 7 D-20099 Hamburg, Germany Phone: +49-40-42875-8157 Email: Schmidt@informatik.haw-hamburg.de Matthias Waehlisch link-lab Hoenowerstr. 35 D-10318 Berlin, Germany Email: mw@link-lab.net Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Schmidt, Waehlisch Expires - August 2008 [Page 30] MMCASTv6-PS February 2008 Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Copyright Notice Copyright (C) The IETF Trust (2007) This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding of the RFC Editor function is currently provided by the Internet Society. Schmidt, Waehlisch Expires - August 2008 [Page 31]