Skip to main content

Multicast Mobility in Mobile IP Version 6 (MIPv6): Problem Statement and Brief Survey
draft-irtf-mobopts-mmcastv6-ps-09

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5757.
Authors Matthias Wählisch , Thomas C. Schmidt , Gorry Fairhurst
Last updated 2015-10-14 (Latest revision 2009-10-19)
RFC stream Internet Research Task Force (IRTF)
Intended RFC status Informational
Formats
Additional resources Mailing list discussion
Stream IRTF state (None)
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 5757 (Informational)
Action Holders
(None)
Telechat date (None)
Responsible AD Jari Arkko
Send notices to (None)
draft-irtf-mobopts-mmcastv6-ps-09
MobOpts Research Group                             Thomas C. Schmidt 
   Internet Draft                                           HAW Hamburg 
   Intended Status: Informational                    Matthias Waehlisch 
   Expires: April 22, 2010                                     link-lab 
                                                       Godred Fairhurst 
                                                 University of Aberdeen 
                                                       October 20, 2009 
    
    
      Multicast Mobility in MIPv6: Problem Statement and Brief Survey 
                  <draft-irtf-mobopts-mmcastv6-ps-09.txt> 
    
    
    
Status of this Memo 
    
   This Internet-Draft is submitted to IETF in full conformance with the 
   provisions of BCP 78 and BCP 79. 
    
   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 Internet-Draft will expire on April 22, 2010. 
    
Copyright Notice 
    
   Copyright (c) 2009 IETF Trust and the persons identified as the 
   document authors. All rights reserved. 
    
   This document is subject to BCP 78 and the IETF Trust's Legal 
   Provisions Relating to IETF Documents in effect on the date of 
   publication of this document (http://trustee.ietf.org/license-info). 
   Please review these documents carefully, as they describe your rights 
   and restrictions with respect to this document. 
    
    
    

 
                         
Schmidt, et al.          Expires - April 2010                 [Page 1] 

                             MMCASTv6-PS                 October 2009 
 
 
Abstract 
    
   This document discusses current mobility extensions to IP layer 
   multicast. It describes problems arising from mobile group 
   communication in general, the case of multicast listener mobility, 
   and for mobile senders using Any Source Multicast and Source Specific 
   Multicast. 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 with 
   respect to the relevant technologies in the wireless domain. It 
   outlines the principal approaches to multicast mobility, together 
   with a comprehensive exploration of the mobile multicast problem and 
   solution space. This document concludes with a conceptual roadmap for 
   initial steps in standardization for use by future mobile multicast 
   protocol designers. This document is a product of the IP Mobility 
   Optimizations (MobOpts) Research Group. 
    
    
Table of Contents 
    

   1. Introduction and Motivation....................................3 
     1.1 Document Scope..............................................4 

   2. Problem Description............................................6 
     2.1 General Issues..............................................6 
     2.2 Multicast Listener Mobility.................................8 
         2.2.1 Node & Application Perspective........................8 
         2.2.2 Network Perspective...................................9 
     2.3 Multicast Source Mobility..................................10 
         2.3.1 Any Source Multicast Mobility........................10 
         2.3.2 Source Specific Multicast Mobility...................11 
     2.4 Deployment Issues..........................................12 

   3. Characteristics of Multicast Routing Trees under Mobility.....13 

   4. Link Layer Aspects............................................13 
     4.1 General Background.........................................14 
     4.2 Multicast for Specific Technologies........................14 
         4.2.1 802.11 WLAN..........................................15 
         4.2.2 802.16 WIMAX.........................................15 
         4.2.3 3GPP/3GPP2...........................................17 
         4.2.4 DVB-H / DVB-IPDC.....................................17 
         4.2.5 TV Broadcast and Satellite Networks..................18 
     4.3 Vertical Multicast Handovers...............................18 

   5. Solutions.....................................................19 
     5.1 General Approaches.........................................19 
     5.2 Solutions for Multicast Listener Mobility..................20 
 
 
Schmidt, et al.          Expires - April 2010                 [Page 2] 

                             MMCASTv6-PS                 October 2009 
 
 
         5.2.1 Agent Assistance.....................................20 
         5.2.2 Multicast Encapsulation..............................21 
         5.2.3 Hybrid Architectures.................................21 
         5.2.4 MLD Extensions.......................................22 
     5.3 Solutions for Multicast Source Mobility....................22 
         5.3.1 Any Source Multicast Mobility Approaches.............23 
         5.3.2 Source Specific Multicast Mobility Approaches........23 

   6. Security Considerations.......................................24 

   7. Summary and Future Steps......................................25 

   8. IANA Considerations...........................................26 

   Appendix A. Implicit Source Notification Options.................26 

   References.......................................................27 

   Acknowledgments..................................................34 

   Author's Addresses...............................................34 

    
    
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.  
    
   The early idea of Internet multicasting [1] soon led to a wide 
   adoption of Deering's host group model [2]. Broadband media delivery 
   is emerging as a typical mass scenario that demands scalability and 
   bandwidth efficiency from multicast routing. Although multicast 
   mobility has been a concern for about ten years [3] and has led to 
   numerous proposals, there is as yet no generally accepted solution. 
   Multicast network support will be of particular importance to mobile 
   environments, where users commonly share frequency bands of limited 
   capacity. Reception of 'infotainment' streams may soon require wide 
   deployment of mobile multicast services. 
    
   Mobility in IPv6 [4] is standardized in the Mobile IPv6 RFCs [5,6], 
   and addresses the scenario of network layer changes while moving 
   between wireless domains. MIPv6 [5] only roughly defines multicast 
   mobility for Mobile Nodes (MN), using a remote subscription approach 
 
 
Schmidt, et al.          Expires - April 2010                 [Page 3] 

                             MMCASTv6-PS                 October 2009 
 
 
   or through bi-directional tunneling via the Home Agent (HA). Remote 
   subscription suffers from slow handovers, relying on multicast 
   routing to adapt to handovers. Bi-directional tunneling introduces 
   inefficient overhead and delay due to triangular forwarding, i.e., 
   instead of traveling on shortest paths, packets are routed through 
   the Home Agent. Therefore these approaches have not been optimized 
   for a large scale deployment. A mobile multicast service for a future 
   Internet should provide 'close to optimal' routing at predictable and 
   limited cost, offering robustness combined with a service quality 
   compliant to real-time media distribution.  
    
   Intricate multicast routing procedures are not easily extensible to 
   satisfy the requirements for mobility. A client subscribed to a group 
   while performing mobility handovers, requires the multicast traffic 
   to follow to its new location; a mobile source needs the entire 
   delivery tree to comply with or to adapt to its changing position. 
   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 
   [65]. 
    
   In multimedia conference scenarios, games or collaborative 
   environments each member commonly operates as a receiver and as a 
   sender for multicast group communication. In addition, real-time 
   communication such as conversational voice or video places severe 
   temporal requirements on mobility protocols: Typical seamless 
   handover scenarios are expected to limit disruptions or delay to less 
   than 100 - 150 ms [7]. Jitter disturbances should not exceed 50 ms. 
   Note that 100 ms is about the duration of a spoken syllable in real-
   time audio. This problem statement is intended to also be applicable 
   to a range of other scenarios with a range of delivery requirements 
   appropriate to the general Internet. 
    
   This document represents the consensus of the MobOpts Research Group. 
   It has been reviewed by the Research Group members active in the 
   specific area of work. In addition, this document has been 
   comprehensively reviewed by multiple active contributors to the IETF 
   MEXT, MBONED, and PIM Working Groups. 
    
1.1 Document Scope 
    
   This document defines the problem scope for multicast mobility 
   management, which may be elaborated in future work. It is subdivided 
   to present the various challenges according to their originating 
   aspects, and identifies existing proposals and major bibliographic 
   references. 
    
   When considering multicast node mobility, the network layer is 
   complemented by some wireless access technology. Two basic scenarios 
 
 
Schmidt, et al.          Expires - April 2010                 [Page 4] 

                             MMCASTv6-PS                 October 2009 
 
 
   are of interest: Single-hop mobility (shown in figure 1.a) and multi-
   hop mobile routing (figure 1.b). Single-hop mobility is the focus of 
   this document, which coincides with the perspective of MIPv6 [5]. The 
   key issues of mobile multicast membership control, and the interplay 
   of mobile and multicast routing will be illustrated using this simple 
   scenario. 
    
   Multi-hop network mobility is a subsidiary scenario. 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 either encapsulation or flooding ([8] provides a general 
   overview). Specific issues arising from (nested) tunneling or 
   flooding, especially the preservation of address transparency, 
   require treatment analogous to MIPv6. 
    
                                           +------+           +------+ 
                                           |  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 
    

 
 
Schmidt, et al.          Expires - April 2010                 [Page 5] 

                             MMCASTv6-PS                 October 2009 
 
 
     Figure 1: Mobility Scenarios - A Mobile Node (MN) Directly 
   attaching to Fixed Access Routers (AR) or attached via Local Access 
   Routers (LAR) 
    
    
2. Problem Description 
    
2.1 General Issues 
    
   Multicast mobility is a generic term, which subsumes a collection of 
   distinct functions. First, multicast communication is divided into 
   Any Source Multicast (ASM) [2] and Source Specific Multicast (SSM) 
   [9,10]. 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], or inter-domain multicast 
   prefix advertisements via MBGP [15]. IPv6 clients interact using the 
   multicast listener discovery protocol (MLD and MLDv2) [16,17]. 
    
   Any solution for multicast mobility needs to 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 
   is desired to preserve the multicast nature of packet distribution 
   and approximate optimal routing. It should support per-flow handover 
   for multicast traffic, because the properties and designations of 
   flows can be distinct. Such distinctions may result from differing 
   QoS/real-time requirements, but may also be caused by network 
   conditions that may differ for different 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 [5], its security 
   extensions [6,18], its expediting schemes FMIPv6 [19] and HMIPv6 
   [20], its context transfer protocols [21], its multihoming 
   capabilities [22,23], emerging protocols like PMIPv6 [62] 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 can be 
   derived that can jointly support unicast and multicast.  
    
   Multicast routing dynamically adapts to the network topology at the 
   locations 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 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 
 
 
Schmidt, et al.          Expires - April 2010                 [Page 6] 

                             MMCASTv6-PS                 October 2009 
 
 
   multicast routing protocol in use, the configuration of routers, 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 for 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.  
    
   The mobility of hosts using IP multicast can impact the service 
   presented to the higher-layer protocols. IP layer multicast packet 
   distribution is an unreliable service that is bound to connectionless 
   transport protocols. Where applications are sensitive to packet loss 
   or jitter, countermeasures need to be performed (loss recovery, 
   content recoding, concealment, etc) by the multicast transport or 
   application. Mobile multicast handovers should not introduce 
   significant additional packet drops. Due to statelessness, the bi-
   casting of multicast flows does not cause degradations at the 
   transport layer, and applications should implement mechanisms to 
   detect and correctly respond to duplicate datagrams. Nevertheless, 
   individual application programs may not be robust with respect to 
   repeated reception of duplicate streams. 
    
   IP multicast applications can be designed to adapt the multicast 
   stream to prevailing network conditions (adapting the sending rate to 
   the level of congestion, adaptive tuning of clients in response to 
   measured delay, dynamic suppression of feedback messages, etc). An 
   adaptive application may also use more than one multicast group 
   (e.g., layered multicast in which a client selects a set of multicast 
   groups based on perceived available network capacity). A mobility 
   handover may temporarily disrupt the operation of these higher-layer 
   functions. The handover can invalidate assumptions about the 
   forwarding path (e.g., acceptable delivery rate, round trip delay), 
   which could impact an application and level of network traffic. Such 
   effects need to be considered in the design of multicast applications 
   and in the design of network-layer mobility. Specifically, mobility 
   mechanisms need to be robust to transient packet loss that may result 
   from invalid path expectations following a handover of an MN to a 
   different network. 
    
   Group addresses in general are location transparent, even though they 
   may be scoped and methods can embed unicast prefixes or Rendezvous 
   Point addresses [24]. The addresses of sources contributing to a 
   multicast session are interpreted by the routing infrastructure and 
   by receiver applications, which frequently are aware of source 
   addresses. Multicast therefore inherits the mobility address duality 
   problem of MIPv6 for source addresses: 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., 
 
 
Schmidt, et al.          Expires - April 2010                 [Page 7] 

                             MMCASTv6-PS                 October 2009 
 
 
   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 receivers that are unknown at the network layer, and thus operates 
   without a feedback channel. It neither has means to inquire about the 
   properties of its delivery trees, nor is it able to learn about the 
   network-layer state of its receivers. In the event of an inter-tree 
   handover, a mobile multicast source therefore is vulnerable to losing 
   connectivity to receivers without noticing. (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 the complexity of the requirements, multicast mobility 
   management should seek lightweight solutions with easy deployment. 
   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 following a handover in real-time. This needs to 
   transfer 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 the MN's moving interface(s) to the new upstream 
   router(s). In the latter case, it may encounter either one of the 
   following conditions:  
     o In the simplest scenario, packets of some, or all, of the  
       subscribed groups of the mobile node are already received by one 
       or several other group members in the new network, and thus  
       multicast streams natively flow after the MN arrives at the new  
       network. 
     o 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, e.g., groups may be scoped or  
       administratively prohibited. This means that current distribution  
       trees for the desired groups may only be re-joined at a (possibly  
       large) routing distance. 
     o The new network may not be multicast-enabled or the specific  
       multicast service may be unavailable, e.g., unsupported or  
       prohibited. This means that current distribution trees for the  
       desired groups need to be re-joined at a large routing distance  
 
 
Schmidt, et al.          Expires - April 2010                 [Page 8] 

                             MMCASTv6-PS                 October 2009 
 
 
       by (re) establishing a tunnel to a multicast-enabled network  
       node. 
    
   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 for real-time services. Dependant on layer 2  
       and 3 handover performance, the time available for multicast  
       mobility operations is typically bound the total handover time  
       left after IPv6 connectivity is regained. In real-time scenarios  
       this may be significantly less than 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 desire to restrict MLD 
   queries towards the MN. Multihomed MNs may ensure smooth handoffs by 
   using a 'make-before-break' approach, which requires a per interface 
   subscription, facilitated by an MLD JOIN operating on a pre-selected 
   IPv6 interface. 
    
   Encapsulation on the path between the upstream router and the 
   receiver may result in MTU size conflicts, since path-MTU discovery 
   is often not supported for multicast and can reduce scalability in 
   networks with many different MTU sizes or introduce potential denial 
   of service vulnerabilities (since the originating addresses of ICMPv6 
   messages can not be verified for multicast). In the absence of 
   fragmentation at tunnel entry points, this may prevent the group 
   being forwarded to the destination.  
    
2.2.2 Network Perspective 
    
   The infrastructure providing multicast services is required to keep 
   traffic following the MN without compromising network functionality. 
   Mobility solutions thus have to face some immediate problems:  
    
     o Realize native multicast forwarding, and where applicable  
       conserve network resources and utilize link layer multipoint  
       distribution to avoid data redundancy. 
     o Activate link multipoint services, even if the MN performs  
       only a layer 2 / vertical handover.  
     o Ensure routing convergence, even when the MN moves rapidly 
       and performs handovers at a high frequency. 

 
 
Schmidt, et al.          Expires - April 2010                 [Page 9] 

                             MMCASTv6-PS                 October 2009 
 
 
     o Avoid avalanche problems and stream multiplication (n-casting), 
       which potentially result from replicated tunnel initiation or  
       redundant forwarding at network nodes.  
    
   There are additional implications for the infrastructure: In changing 
   its point of attachment, an exclusive mobile receiver may cause 
   initiation in the new network and termination of a group distribution 
   service in the previous network. Mobility management may impact 
   multicast routing by, e.g., erroneous subscriptions following 
   predictive handover operations, or slow traffic termination at leaf 
   nodes resulting from MLD query timeouts, or by departure of the MN 
   from a previous network without leaving the subscribed groups. 
   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 forms the root of a 
   source specific shortest path tree (SPT), distributing data towards a 
   rendezvous point (RP) 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 for its new network 
   location. In the latter case, the mobile sender will have to proceed 
   without knowing whether the new tree has regained ability to forward 
   traffic to the group, due to the decoupling of sender and receivers. 
    
   A mobile multicast source must therefore provide address transparency 
   at two layers: To comply with RPF checks, it has to use an address 
   within the source field of the IPv6 basic header, which is in 
   topological agreement 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.  
    
   The address transparency and temporal handover constraints pose major 
   problems for route optimizing mobility solutions. 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 [5]. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 10] 

                             MMCASTv6-PS                 October 2009 
 
 
   Intra-domain multicast routing may allow the use of shared trees that 
   can reduce mobility-related complexity. A static rendezvous point may 
   allow a mobile source to continuously send data to the group by 
   encapsulating packets to the RP 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 the corresponding RP (in contrast to IPv4, IPv6 ASM 
   multicast groups are associated with a specific RP/RPs). 
    
   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 the presence of an 
   embedded rendezvous point address [24], e.g., the primary rendezvous 
   point for inter-domain PIM-SM will be globally appointed, and a newly 
   attached mobile source can contact the RP without prior signaling 
   (like a new source) and transmit data in the PIM register tunnel. 
   Multicast route optimization (e.g., PIM 'shortcuts') will require 
   multicast routing protocol operations equivalent to serving a new 
   source.  
    
2.3.2 Source Specific Multicast Mobility 
    
   Source Specific Multicast has been designed for multicast senders 
   with static source addresses. The source addresses in a client 
   subscription to an SSM group is directly used to 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 becomes invalid when the 
   topological source address changes 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 consequence, source mobility for SSM requires a conceptual 
   treatment beyond the problem scope of mobile ASM. A listener 
   subscribes to an (S,G) channel membership and routers establish an 
   (S,G)-state shortest path tree rooted at source S, therefore any 
   change of source addresses under mobility requires 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 that will share 
   paths with the previous SPT, e.g., at the receiver side. As the 
   principle of multicast decoupling of a sender from its receivers 
   holds for SSM, the client updates needed for switching trees become a 
   severe burden. 
    
   An SSM listener may subscribe to or exclude any specific multicast 
   source, and thereby wants to rely on the topological correctness of 
 
 
Schmidt, et al.          Expires - April 2010                [Page 11] 

                             MMCASTv6-PS                 October 2009 
 
 
   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 [5]. 
    
   The above methods could add significant complexity to a solution for 
   robust SSM mobility, which needs to converge to optimal routes and, 
   for efficiency, is desired to 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 previous to next designated router, may serve as an 
   appropriate measure of complexity [25,26]. 
    
   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 leanness of SSM by 
   minimizing additional signaling overhead. 
    
2.4 Deployment Issues 
    
   IP multicast deployment in general has been slow over the past 15 
   years, even though all major router vendors and operating systems 
   offer implementations that support multicast [27]. While many 
   (walled) domains or enterprise networks operate point-to-multipoint 
   services, IP multicast roll-out is currently limited in public inter-
   domain scenarios [28]. 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 [29]. Garyfalos and Almeroth [30] 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 does not change the routing protocols. Mobility 
   management in such a 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 this can be achieved in all cases.  
    
   Nevertheless, multicast services in mobile environments may soon 
   become indispensable, when multimedia distribution services such as 
   DVB-H [31,32] or IPTV develop a strong business case for portable IP-
   based devices. As IP mobility becomes an important service and as 
   efficient link utilization is of a larger impact in costly radio 
 
 
Schmidt, et al.          Expires - April 2010                [Page 12] 

                             MMCASTv6-PS                 October 2009 
 
 
   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 [33] proposed a scaling power-law for the total number of links 
   in a multicast shortest path tree with m receivers (proportional to 
   m^k). The authors consistently identified the scale factor to attain 
   the independent constant k = 0.8. The validity of such universal, 
   heavy-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 [34,35] debated the 
   applicability of the Chuang and Sirbu scaling law. Van Mieghem et al. 
   [34] 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 of N = 10^5 
   core nodes. Investigating self-similarity Janic and Van Mieghem [36] 
   semi-empirically substantiated that multicast shortest path trees in 
   the Internet can be modeled with reasonable accuracy by uniform 
   recursive trees (URT) [37], provided m remains small compared to N. 
    
   The mobility perspective on shortest path trees focuses 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 
   identical receivers at one or several intersection points. By the 
   self-similar nature, the persistent sub-trees (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 [26], 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 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 13] 

                             MMCASTv6-PS                 October 2009 
 
 
4.1 General Background 
    
   Scalable group data distribution has the highest potential in edge 
   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. Wireless access 
   technologies inherently support broadcast/multicast at L2 and operate 
   on a shared medium with limited frequency and bandwidth. 
    
   Several aspects need consideration: First, dissimilar network access 
   radio technologies cause distinct group traffic transmissions. There 
   are: 
    
    o connection-less link services of a broadcast type, which mostly 
      are bound to limited reliability; 
    
    o connection-oriented link services of a point-to-multipoint type, 
      which require more complex control and frequently exhibit reduced  
      efficiency; 
    
    o connection-oriented link services of a broadcast type, which are 
      restricted to unidirectional data transmission. 
    
   In addition, multicast may be distributed via multiple point-to-point 
   unicast links without use of a dedicated multipoint radio channel. A 
   fundamental difference between unicast and group transmission arises 
   from power management. Some radio technologies adjust transmit power 
   to be as small as possible based on link-layer feedback from the 
   receiver which is not done in multipoint mode. They consequently 
   incur a 'multicast tax', making multicast less efficient than unicast 
   unless the number of receivers is larger than some threshold.  
    
   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 [70] or proxy [38], 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.  
    
   Third, 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 
    
 
 
Schmidt, et al.          Expires - April 2010                [Page 14] 

                             MMCASTv6-PS                 October 2009 
 
 
4.2.1 802.11 WLAN 
    
   IEEE 802.11 WLAN is a broadcast network of Ethernet type. This 
   inherits multicast address mapping concepts from 802.3. In 
   infrastructure mode, an access point operates as a 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 
   receive similar treatment. 
    
   Multicast frame delivery has the following characteristics: 
    
    o As an unacknowledged service it offers limited reliability. 
      Frames (and hence packet) loss arise from interference,  
      collision, or time-varying channel properties. 
    
    o Data distribution may be delayed, as unicast power saving  
      synchronization via Traffic Indication Messages (TIM) does not 
      operate in multicast mode. 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, because 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 a 
   configurable rate limit for forwarding multicast packets. 
   Additionally, an IGMP/MLD snooping or proxy 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 that can operate in single-hop point-to-
   multipoint (PMP) or in mesh mode. The latter does not support 
   multipoint transmission and currently has no deployment. PMP operates 
   between Base and Subscriber Stations in distinguished, unidirectional 
   channels. The channel assignment is controlled by the Base Station, 
   which assigns 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 (restricted to downlink and without 
   ARQ) mode. 
    
 
 
Schmidt, et al.          Expires - April 2010                [Page 15] 

                             MMCASTv6-PS                 October 2009 
 
 
   A WIMAX Base Station operates as a full-duplex L2 switch, with 
   switching based on CIDs. Two IPv6 link models for mobile access 
   scenarios exist: A shared IPv6 prefix for IP over Ethernet CS [39] 
   provides MAC separation within a shared prefix. A second, point-to-
   point link model [40] is recommended in the IPv6 Convergence Sublayer 
   [41], which treats each connection to a mobile node as a single link. 
   The point-to-point link model conflicts with a consistent group 
   distribution at the IP layer when using a shared medium (cf. section 
   4.1 for MVR as 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 [42]. For 
   selecting group members, a Base Station may implement IGMP/MLD 
   snooping or proxy as foreseen in 802.16e-2005 [43].  
    
   A Subscriber Station multicasts IP packets to a Base Station as a 
   point-to-point unicast stream. When the IPv6 CS is used, these are 
   forwarded to the upstream access router. The access router (or the 
   Base Station for IP over Ethernet CS) may send downstream multicast 
   packets by feeding them to the multicast service channel. On 
   reception, a Subscriber Station cannot distinguish multicast from 
   unicast streams at the link layer.  
    
   Multicast services have the following characteristics: 
    
    o Multicast CIDs are unidirectional and available only in the  
      downlink direction. Thus a native broadcast-type forwarding model  
      is not available. 
    
    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 may occur due 
      to the short ID space. This can result in several point-to- 
      multipoint groups sharing the same CID, reducing the ability of 
      a receiver to filter unwanted L2 traffic. 
    
    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. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 16] 

                             MMCASTv6-PS                 October 2009 
 
 
4.2.3 3GPP/3GPP2 
    
   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) [44]. The 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 [45]. 
    
   In UMTS Rel. 6 the IMS was 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 transit 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.  
    
   In 3GPP2, the MBMS has been extended to the Broadcast and Multicast 
   Service (BCMCS) [46], which on the routing layer operates very 
   similar to MBMS. In both 3GPP and 3GPP2 multicast can either be sent 
   using point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and 
   there is support for switching between PTP and PTM. PTM uses an 
   unidirectional common channel, operating in unacknowledged mode 
   without adjustment of power levels and no reporting on lost packets. 
    
4.2.4 DVB-H / DVB-IPDC 
    
   Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional 
   physical layer broadcasting specification for the efficient delivery 
   of broadband, IP-encapsulated data streams, and published as an ETSI 
   standard [47] (see http://www.dvb-h.org). This uses multi-protocol 
   encapsulation (MPE) to transport IP packets over an MPEG-2 Transport 
   Stream (TS) with link forward error correction (FEC). Each stream is 
   identified by a 13 bit TS ID (PID), which together with a multiplex 
   service ID, is associated with IPv4 or IPv6 addresses [48] and used 
   for selective traffic filtering at receivers. Upstream channels may 
 
 
Schmidt, et al.          Expires - April 2010                [Page 17] 

                             MMCASTv6-PS                 October 2009 
 
 
   complement DVB-H using other transmission technologies. The IP 
   Datacast Service, DVB-IPDC [31] specifies a set of applications that 
   can use the DVB-H transmission network. 
    
   Multicast distribution services are defined by a mapping of groups 
   onto appropriate PIDs, which is managed at the IP Encapsulator [49]. 
   To increase flexibility and avoid collisions, this address resolution 
   is facilitated by dynamic tables, provided within the self-contained 
   MPEG-2 TS. Mobility is supported in the sense that changes of cell 
   ID, network ID or Transport Stream ID are foreseen [50]. A multicast 
   receiver thus needs to re-locate the 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) 
   requires initiation at the IP Encapsulator / DVB-H Gateway, which 
   cannot be signaled in a pure DVB-H network.  
    
4.2.5 TV Broadcast and Satellite Networks 
    
   IP multicast may be enabled in TV broadcast networks, including those 
   specified by DVB, ATSC, and related standards [49]. These standards 
   are also used for one and two-way satellite IP services. Networks 
   based on the MPEG-2 Transport Stream may support either the multi-
   protocol encapsulation (MPE) or the unidirectional lightweight 
   encapsulation (ULE) [51]. The second generation DVB standards allow 
   the Transport Stream to be replaced with a Generic Stream, using the 
   generic stream encapsulation (GSE) [52]. These encapsulation formats 
   all support multicast operation. 
    
   In MPEG-2 transmission networks, multicast distribution services are 
   defined by a mapping of groups onto appropriate PIDs, which is 
   managed at the IP Encapsulator [49]. The addressing issues resemble 
   those for DVB-H (section 4.2.4) [48]. The issues for using GSE 
   resemble those for ULE (except the PID is not available as a 
   mechanism for filtering traffic). Networks that provide bidirectional 
   connectivity may allow active service subscription (multicast join) 
   to initiate forwarding from the upstream IP Encapsulator / gateway. 
   Some kind of filtering can be achieved using the Input Stream 
   Identifier (ISI) field. 
    
    
4.3 Vertical Multicast Handovers 
    
   A mobile multicast node may change its point of layer 2 attachment 
   within homogeneous access technologies (horizontal handover) or 
   between heterogeneous links (vertical handover). In either case, a 
   layer 3 network change may or may not take place, but multicast-aware 
   links always need information about group traffic demands. 
   Consequently, a dedicated context transfer of multicast subscriptions 
 
 
Schmidt, et al.          Expires - April 2010                [Page 18] 

                             MMCASTv6-PS                 October 2009 
 
 
   is required at the network access. Such Media Independent Handover 
   (MIH) is addressed in IEEE 802.21 [53], but is relevant also beyond 
   IEEE protocols. Mobility services transport for MIH are required as 
   an abstraction for layer 2 multicast service transfer in an Internet 
   context [54] and are specified in [55]. 
    
   MIH needs to assist in more than service discovery: There is a need 
   for complex, media dependent multicast adaptation, 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: 
    
    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 [56]:  
    
    o Bi-directional Tunneling, 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 degradation from widely spanned  
      data tunnels. 
    
    o Remote Subscription forces the mobile node to re-initiate  
      multicast distribution following handover, e.g., by submitting an  
      MLD listener report to the subnet where a receiver attaches. This  
      approach of tree discontinuation relies on multicast dynamics to  
      adapt to network changes. It not only results in significant  
      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 tunneling  
      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,  
 
 
Schmidt, et al.          Expires - April 2010                [Page 19] 

                             MMCASTv6-PS                 October 2009 
 
 
      where some extra effort is needed to sustain session persistence  
      through address transparency of mobile sources. 
    
   MIPv6 [5] introduces bi-directional tunneling as well as remote 
   subscription as minimal standard solutions. Various publications 
   suggest utilizing remote subscription for listener mobility only, 
   while advising bi-directional tunneling as the solution for source 
   mobility. Such an approach avoids the 'tunnel convergence' or 
   'avalanche' problem [56], 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, this suffers from the drawback that multicast communication 
   roles are not explicitly known at the network layer and may change 
   unexpectedly. 
    
   None of the above approaches address SSM source mobility, except the 
   use of bi-directional tunneling. 
    
5.2 Solutions for Multicast Listener Mobility 
    
5.2.1 Agent Assistance 
    
   There are proposals for agent-assisted handover for host-based 
   mobility, which complement the unicast real-time mobility 
   infrastructure of Fast MIPv6 [19], the M-FMIPv6 [57,58], and of 
   Hierarchical MIPv6 [20], the M-HMIPv6 [59], and to context transfer 
   [60], which have been thoroughly analyzed in [25,61].  
    
   All these solutions presume the context state was stored within a 
   network node that is reachable before and after a move. But there 
   could be cases were the MN is no longer in contact with the previous 
   network, when at the new location. In this case, the network itself 
   cannot assist in the context transfer. Such scenarios may occur when 
   moving from one (walled) operator to another and will require a 
   backwards compatible way to recover from loss of connectivity and 
   context based on the node alone.  
    
   Network based mobility management, PMIPv6 [62], is multicast 
   transparent in the sense that the MN experiences a point-to-point 
   home link fixed at its (static) Local Mobility Anchor (LMA). This 
   virtual home link is composed of a unicast tunnel between the LMA and 
   the current Mobile Access Gateway (MAG), and a point-to-point link 
   connecting the current MAG to the MN. A PMIPv6 domain thereby 
   inherits MTU-size problems from spanning tunnels at the receiver 
   site. Furthermore, two avalanche problem points can be identified: 
   The LMA may be required to tunnel data to a large number of MAGs, 
   while a MAG may be required to forward the same multicast stream to 
   many MNs via individual point-to-point links [63]. Future 
   optimizations and extensions to shared links preferably adapt native 
 
 
Schmidt, et al.          Expires - April 2010                [Page 20] 

                             MMCASTv6-PS                 October 2009 
 
 
   multicast distribution towards the edge network, possibly using a 
   local routing option, including context transfer between access 
   gateways to assist IP-mobility-agnostic MNs.  
    
   An approach based on dynamically negotiated inter-agent handovers is 
   presented in [64]. Aside from IETF work, numerous publications 
   present proposals for seamless multicast listener mobility, e.g. [65] 
   provides a comprehensive overview of the work prior to 2004. 
    
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 tunneling in IPv6 [66] using a unicast point-to-point method 
   will also allow multicast-agnostic domains to be transited, but does 
   inherit the tunnel convergence problem and may result in traffic 
   multiplication. 
    
   Multicast enabled environments may take advantage of point-to-
   multipoint encapsulation, i.e., generic packet tunneling using an 
   appropriate multicast destination address in the outer header. Such 
   multicast-in-multicast encapsulated packets similarly enable 
   reception of remotely located streams, but do not suffer from the 
   scaling overhead from using unicast tunnels. 
    
   The tunnel entry point performing encapsulation should provide 
   fragmentation of data packets to avoid issues resulting from MTU size 
   constraints within the network(s) supporting the tunnel(s).  
    
5.2.3 Hybrid Architectures 
 
   There has been recent interest in seeking method that avoid the 
   complexity at the Internet core network, e.g. application layer and 
   overlay proposals for (mobile) multicast. The possibility of 
   integrating multicast distribution on the overlay into the network 
   layer is also being considered by the IRTF Scalable Adaptive 
   Multicast (SAM) Research Group. 
    
   An early hybrid architecture using reactively operating proxy-
   gateways located at the Internet edges was introduced by Garyfalos 
   and Almeroth [30]. The authors presented an 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. The Hybrid Shared Tree approach [67] introduced 
   a mobility-agnostic multicast backbone on the overlay. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 21] 

                             MMCASTv6-PS                 October 2009 
 
 
   Current work in the SAM RG is developing general architectural 
   approaches for hybrid multicast solutions [68] and a common multicast 
   API for a transparent access of hybrid multicast [69] that will 
   require a detailed design in future work. 
    
5.2.4 MLD Extensions 
    
   The default timer values specified in MLD [17] were not designed for 
   the mobility context. This results in a slow reaction of the 
   multicast routing infrastructure (including layer-3-aware access 
   devices [70]) following a client leave. This may be a disadvantage 
   for wireless links, where performance may be improved by carefully 
   tuning the Query Interval. Some vendors have optimized performance by 
   implementing a listener node table at the access router that can 
   eliminate the need for query timeouts when receiving leave messages 
   (explicit receiver tracking).  
    
   A MN operating predictive handover, e.g., using FMIPv6, may 
   accelerate multicast service termination when leaving the previous 
   network by submitting an early Done message before handoff. MLD 
   router querying will allow the multicast forwarding state to be 
   restored in case of an erroneous prediction (i.e., an anticipated 
   move to a network that has not taken place). Backward context 
   transfer may otherwise ensure a leave is signaled. A further 
   optimization was introduced by Jelger and Noel [71] for the special 
   case when the HA is 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 
   standard MLD membership queries (with a subsequent timeout). Such 
   explicit treatment of point-to-point links will reduce traffic and 
   accelerate the control protocol. Explicit tracking will cause 
   identical protocol behavior. 
    
   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 
   router. Such functions rely 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 when transmission of group data 
   is paused. To enable such proxy control, the authors in [71] propose 
   an extension to MLD, introducing a Listener Hold message that is 
   exchanged between the MN and the HA. This idea was developed in [59] 
   to propose multicast router attendance control, allowing for a 
   general deployment of group membership proxies. Some currently 
   deployed IPTV solutions use such a mechanism in combination with a 
   recent (video) frame buffer, to enable fast channel switching between 
   several IPTV multicast flows (zapping).  
    
5.3 Solutions for Multicast Source Mobility 
    
 
 
Schmidt, et al.          Expires - April 2010                [Page 22] 

                             MMCASTv6-PS                 October 2009 
 
 
5.3.1 Any Source Multicast Mobility Approaches 
    
   Solutions for multicast source mobility can be divided into three 
   categories: 
    
    o Statically Rooted Distribution Trees. These methods follow a 
      shared tree approach. Romdhani et al. [72] proposed employing 
      the 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 designed a tunnel- or SSM-based 
      backbone distribution of packets between MRPs. 
    
    o Reconstruction of Distribution Trees. Several authors have  
      proposed the construction of a completely new distribution tree 
      after the movement of a mobile source and therefore have to  
      compensate for the additional routing (tree-building) delay.  
      M-HMIPv6 [59] tunnels data into a previously established tree 
      rooted at mobility anchor points to compensate for the routing 
      delay until a protocol dependent timer expires. The RBMoM  
      protocol [73] introduces an additional Multicast Agent (MA) that 
      advertises its service range. A 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 new current vicinity. 
    
    o Tree Modification Schemes. In the case of DVMRP routing,  
      Chang and Yen [74] propose an algorithm to extend the root of a 
      given delivery tree for incorporating a new source location in 
      ASM. The authors rely on a complex additional signaling protocol 
      to fix DVMRP forwarding states and heal failures in the reverse 
      path forwarding (RPF) checks. 
    
5.3.2 Source Specific Multicast Mobility Approaches 
    
   The shared tree approach of [72] has been extended to support SSM 
   mobility by introducing the HoA address record to the Mobility-aware 
   Rendezvous Points. The MRPs operate using extended multicast routing 
   tables that simultaneously hold the HoA and CoA and thus can 
   logically identify the appropriate distribution tree. Mobility thus 
   may re-introduce the concept of rendezvous points to SSM routing. 
    
   Approaches for reconstructing SPTs in SSM rely on a client 
   notification to establish new router state. It also needs to preserve 
   address transparency for the client. Thaler [75] proposed introducing 
   a binding cache and providing source address transparency analogous 
   to MIPv6 unicast communication. Initial session announcements and 
 
 
Schmidt, et al.          Expires - April 2010                [Page 23] 

                             MMCASTv6-PS                 October 2009 
 
 
   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 [76] suggest handover improvements employing anchor 
   points within the source network, supporting continuous data 
   reception during client initiated handovers. Client updates are 
   triggered out of band, e.g. by SDR/SAP [77]. Receiver-oriented tree 
   construction in SSM thus remains unsynchronized with source 
   handovers. 
    
   To address the synchronization problem at the routing layer, several 
   proposals have focused on direct modification of the distribution 
   trees. A recursive scheme may use loose unicast source routes with 
   branch points, based on a multicast Hop-by-Hop protocol. Vida et al 
   [78] optimized SPT for a moving source on the path between the source 
   and first branching point. O'Neill [79] suggested a scheme to 
   overcome RPF check failures that originate from multicast source 
   address changes with 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 [80] used 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. An enhanced version of this 
   protocol abandoned the initial source routing and could be proved to 
   comply with rapid source movement [81]. Lee et al. [82] introduced 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 along 
   the previous distribution tree. Multicast data is then intended to 
   flow natively using triangular routes via the elongation and an 
   updated tree centered on the home agent. Based on Host Identity 
   Protocol identifiers, Kovacshazi and Vida [83] introduce multicast 
   routing states that remain independent of IP addresses. Drawing upon 
   a similar scaling law argument, parts of these states may then be re-
   used after source address changes.  
    
    
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 
 
 
Schmidt, et al.          Expires - April 2010                [Page 24] 

                             MMCASTv6-PS                 October 2009 
 
 
   solution jointly operating binding updates for unicast and multicast 
   sessions.  
    
   Multicast protocols exhibit a risk of network-based traffic 
   amplification. For example, an attacker may abuse mobility signaling 
   to inject unwanted traffic into a previously established multicast 
   distribution infrastructure. These threats are partially mitigated by 
   reverse path forwarding checks by multicast routers. However, a 
   multicast or mobility agent that explicitly replicates multicast 
   streams, e.g., Home Agent that n-casts data, may be vulnerable to 
   denial of service attacks. In addition to source authentication, a 
   rate control of the replicator may be required to protect the agent 
   and the downstream network. 
    
   Mobility protocols need to consider the implications and requirements 
   for Authentication, Authorization and Accounting (AAA). A MN may have 
   been authorized to receive a specific multicast group when using one 
   mobile network, but this may not be valid when attaching to a 
   different network. In general, the AAA association for an MN may 
   change between attachments, or may be individually chosen prior to 
   network (re-)association. The most appropriate network path may be 
   one that satisfies user preferences, e.g., to use/avoid a specific 
   network, minimize monetary cost, etc, rather than one that only 
   minimizes the routing cost. Consequently, AAA bindings may need to be 
   considered when performing context transfer. 
    
   Admission control issues may arise with new CoA source addresses are 
   introduced to SSM channels [84]. Due to lack of feedback, the 
   admission [85] and binding updates [86] of mobile multicast sources 
   require autonomously verifiable authentication. This can be achieved 
   by, for instance, Cryptographically Generated Addresses (CGAs).  
    
   Modification to IETF protocols (e.g. routing, membership, session 
   announcement and control) as well as the introduction of new 
   entities, e.g., multicast mobility agents, can introduce security 
   vulnerabilities and require consideration of issues such as 
   authentication of network entities, methods to mitigate denial of 
   service (in terms of unwanted network traffic, unnecessary 
   consumption of router/host resources and router/host state/buffers). 
   Future solutions must therefore analyze and address the security 
   implications of supporting mobile multicast. 
    
    
7. Summary and Future Steps 
    
   This document is intended to provide a basis for the future design of 
   mobile IPv6 multicast methods and protocols by: 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 25] 

                             MMCASTv6-PS                 October 2009 
 
 
        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 of 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.  
    
    
8. IANA Considerations 
    
   There are no IANA considerations introduced by this draft. 
    
    
Appendix A. Implicit Source Notification Options 
    
   An IP multicast source transmits data to a group of receivers without 
   requiring any explicit feedback from the group. Sources therefore are 
   unaware at the network-layer of whether any receivers have subscribed 
   to the group, and unconditionally send multicast packets which 
   propagate in the network to the first-hop router (often known in PIM 
   as the designated router). There have been attempts to implicitly 
   obtain information about the listening group members, e.g. extending 
   an IGMP/MLD querier to inform the source of the existence of 
   subscribed receivers. Multicast Source Notification of Interest 
   Protocol (MSNIP) [87] was such a suggested method that allowed a 
   multicast source to querying the upstream designated router. However, 
   this work did not progress within the IETF mboned working group and 
   was terminated by IETF.  
 
 
Schmidt, et al.          Expires - April 2010                [Page 26] 

                             MMCASTv6-PS                 October 2009 
 
 
    
   Multicast sources may also be controlled at the session or transport 
   layer using end-to-end control protocols. A majority of real-time 
   applications employ the Realtime Transport Protocol (RTP) [88].  The 
   accompanying control protocol RTCP [81] allows receivers to report 
   information about multicast group membership and associated 
   performance data. In multicast, the RTCP reports are submitted to the 
   same group and thus may be monitored by the source to monitor, manage 
   and control multicast group operations. The Real Time Streaming 
   Protocol (RTSP), (RFC 2326) provides session layer control that may 
   be used to control a multicast source. However, RTCP and RTSP 
   information is intended for end-to-end control and is not necessarily 
   visible at the network layer. Application designers may chose to 
   implement any appropriate control plane for their multicast 
   applications (e.g. reliable multicast transport protocols_), and 
   therefore a network-layer mobility mechanism must not assume the 
   presence of a specific transport or session protocols. 
    
References 
 
Informative References 
                     
   1  Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM 
      SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63, 
      ACM Press, June, 1984. 
    
   2  S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 
      August 1989. 
    
   3  G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts", 
      IEEE Communications Magazine, 35(1), pp. 54-58, January 1997. 
    
   4  R. Hinden and S. Deering, "Internet Protocol Version 6 
      Specification", RFC 2460, December 1998. 
    
   5  D.B. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6", 
      RFC 3775, June 2004. 
    
   6  V. Devarapalli and F. Dupont, "Mobile IPv6 Operation with IKEv2 
      and the Revised IPsec Architecture", RFC 4877, April 2007. 
    
   7  ITU-T Recommendation, "G.114 - One-way transmission time", 
      Telecommunication Union Standardization Sector, 05/2003. 
    
   8  Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks", 
      IEEE Communications Magazine, 43(9), pp. 23-30, September 2005. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 27] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
   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 T. Bates et al. "Multiprotocol Extensions for BGP-4", RFC 4760, 
      January 2007. 
    
   16 S. Deering, W. Fenner and B. Haberman "Multicast Listener 
      Discovery (MLD) for IPv6", RFC 2710, October 1999. 
    
   17 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version 
      2 (MLDv2) for IPv6", RFC 3810, June 2004. 
    
   18 Arkko, J, Vogt, C, Haddad, W. "Enhanced Route Optimization for 
      Mobile IPv6", RFC 4866, May 2007. 
    
   19 Koodli, R. "Mobile IPv6 Fast Handovers", RFC 5568, July 2009. 
    
   20 Soliman, H, Castelluccia, C, El-Malki, K, Bellier, L. 
      "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC 5380, 
      October 2008. 
    
   21 Loughney, J, Nakhjiri, M, Perkins, C, Koodli, R. "Context Transfer 
      Protocol (CXTP)", RFC 4067, July 2005. 
    
   22 Montavont, N, et al. "Analysis of Multihoming in Mobile IPv6", 
      draft-ietf-monami6-mipv6-analysis-05, Internet Draft (work in 
      progress), May 2008. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 28] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
   23 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, expired), July 2007. 
    
   24 Savola, P, Haberman, B. "Embedding the Rendezvous Point (RP) 
      Address in an IPv6 Multicast Address", RFC 3956, November 2004. 
    
   25 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. 
    
   26 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, December 2006. 
    
   27 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. 
    
   28 Eubanks, M. http://multicasttech.com/status/, 2008. 
    
   29 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 
    
   30 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. 
    
   31 "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of 
      Specifications for Phase 1", ETSI TS 102 468; 
    
   32 ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast 
      over DVB-H: Implementation Guidelines for Mobility)", European 
      Standard (Telecommunications series), November 2004. 
    
   33 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. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 29] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
   34 Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of 
      Multicast", IEEE/ACM Trans. Netw., 9, 6, pp. 719-732, Dec. 2001. 
    
   35 Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast 
      trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003. 
    
   36 Janic, M. and Van Mieghem, P. "On properties of multicast routing 
      trees", Int. J. Commun. Syst. 19(1), pp. 95-114, Feb. 2006. 
    
   37 Van Mieghem, P. "Performance Analysis of Communication Networks 
      and Systems", Cambridge University Press, 2006. 
    
   38 Fenner, B, He, H, Haberman, B, Sandick, H. "Internet Group 
      Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-
      Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, 
      August 2006. 
    
   39 Jeon, H., Riegel, M. and Jeong, S. "Transmission of IP over 
      Ethernet over IEEE 802.16 Networks ", draft-ietf-16ng-ip-over-
      ethernet-over-802-dot-16-12.txt, (work in progress), September 
      2009. 
    
   40 Shin, M. et al. "IPv6 Deployment Scenarios in 802.16 Networks", 
      RFC 5181, May 2008. 
    
   41 Patil, B. et al. "Transmission of IPv6 via the IPv6 Convergence 
      Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008. 
    
   42 Kim, S. et al. "Multicast Transport on IEEE 802.16 Networks", 
      draft-sekim-802-16-multicast-01, (work in progress, expired), July 
      2007. 
    
   43 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. 
    
   44 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. 
    
   45 Wasserman, M. "Recommendations for IPv6 in Third Generation 
      Partnership Project (3GPP) Standards", RFC 3314, September 2002. 
    
   46 3GPP2, www.3gpp2.org,  
      "X.S0022-A, Broadcast and Multicast Service in cdma2000 Wireless 

 
 
Schmidt, et al.          Expires - April 2010                [Page 30] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
      IP Network, Rev. A.", 
      http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007. 
    
   47 ETSI EN 302 304, "Digital Video Broadcasting (DVB); Transmission 
      System for Handheld Terminals (DVB-H)", European Standard 
      (Telecommunications series), November 2004. 
    
   48 Fairhurst, G. and Montpetit, M. "Address Resolution Mechanisms for 
      IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007. 
    
   49 Montpetit, M. et al. "A Framework for Transmission of IP Datagrams 
      over MPEG-2 Networks", RFC 4259, November 2005. 
    
   50 Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in 
      DVB-H", IEEE Comm. Surveys, 8(4), 2006. 
    
   51 Fairhurst, G., and Collini-Nocker, B. "Unidirectional Lightweight 
      Encapsulation (ULE) for Transmission of IP Datagrams over an MPEG-
      2 Transport Stream (TS)", RFC 4326, December 2005. 
    
   52 Fairhurst, G., and Collini-Nocker, B. "Extension Formats for 
      Unidirectional Lightweight Encapsulation (ULE) and the Generic 
      Stream Encapsulation (GSE)", RFC 5163, April 2008. 
    
   53 "Draft IEEE Standard for Local and Metropolitan Area Networks: 
      Media Independent Handover Services", IEEE LAN/MAN Draft IEEE 
      P802.21/D07.00, July 2007. 
    
   54 Melia, T. et al. "Mobility Services Transport: Problem Statement", 
      RFC 5164, March 2008. 
    
   55 Melia, T. et al. "IEEE 802.21 Mobility Services Framework Design 
      (MSFD)", draft-ietf-mipshop-mstp-solution-12, January 2009. 
    
   56 Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three 
      Approaches Towards Mobile Multicast", IST Mobile Summit 2003, 
      Aveiro, Portugal, 16-18 June 2003. 
    
   57 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. 
    
   58 Xia, F. and Sarikaya, B, "FMIPv6 extensions for Multicast 
      Handover", draft-xia-mipshop-fmip-multicast-01, (work in progress, 
      expired), March 2007. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 31] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
   59 Schmidt, T.C. and Waehlisch, M, "Seamless Multicast Handover in a 
      Hierarchical Mobile IPv6 Environment (M-HMIPv6)", draft-schmidt-
      waehlisch-mhmipv6-04, (work in progress, expired), December 2005. 
    
   60 Jonas, K. and Miloucheva, I, "Multicast Context Transfer in mobile 
      IPv6", draft-miloucheva-mldv2-mipv6-00.txt, (work in progress, 
      expired), June 2005. 
    
   61 Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast 
      mobility support using fast MIPv6 extensions", Computer Comm. 29, 
      pp. 3745-3765, 2006. 
    
   62 Gundavelli, S, et al. "Proxy Mobile IPv6", RFC 5213, August 2008. 
    
   63 Deng, H, Schmidt, T.C., Seite, P., and Yang, P. "Multicast Support 
      Requirements for Proxy Mobile IPv6", draft-deng-multimob-pmip6-
      requirement-02, (work in progress), July 2009. 
    
   64 Zhang, H. et al. "Mobile IPv6 Multicast with Dynamic Multicast 
      Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in 
      progress, expired), January 2007. 
    
   65 Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile Multicast: 
      Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004. 
    
   66 Conta, A, Deering, S, "Generic Packet Tunneling in IPv6 - 
      Specification", RFC 2473, December 1998. 
    
   67 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. 
    
   68 Buford, J. "Hybrid Overlay Multicast Framework", draft-irtf-sam-
      hybrid-overlay-framework-02.txt, Internet Draft (work in 
      progress), February 2008. 
    
   69 Waehlisch, M., Schmidt, T.C. "A Common API for Transparent Hybrid 
      Multicast", draft-waehlisch-sam-common-api, October 2009. 
    
   70 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. 
    
   71 Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks: 
      Progress and Challenges", IEEE Wirel. Comm, pp 58-64, Oct. 2002. 
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 32] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
   72 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. 
    
   73 Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile 
      Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002. 
    
   74 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. 
    
   75 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings 
      of ietf meeting, Dec. 2001.  
      URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf 
    
   76 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6 
      (MSSMSv6)", Internet Draft (work in progress, expired), January 
      2002. 
    
   77 Handley, M, Perkins, C, Whelan, E. "Session Announcement 
      Protocol", RFC 2974, October 2000.  
    
   78 Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility 
      Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press 
      2002. 
    
   79 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill-
      mip-multicast-00.txt, (work in progress, expired), July 2002. 
    
   80 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. 
    
   81 Schmidt, T.C., Waehlisch, M., and Wodarz, M. "Fast Adaptive 
      Routing Supporting Mobile Senders in Source Specific Multicast", 
      Telecommunication Systems, 2009, http://dx.doi.org/10.1007/s11235-
      009-9200-y 
    
   82 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. 
    
   83 Kovacshazi, Z. and Vida, R. "Host Identity Specific Multicast", 
      Third International Conference on Networking and Services ICNS, 
      IEEE Press, pp. 1-1, June 2007. 

 
 
Schmidt, et al.          Expires - April 2010                [Page 33] 

                             MMCASTv6-PS                 October 2009 
 
 
                                                                         
    
   84 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. 
    
   85 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. 
    
   86 Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G. "AuthoCast - 
      a mobility-compliant protocol framework for multicast sender 
      authentication", Security and Communication Networks, 1(6),  
      pp. 495 - 509, 2008. 
    
   87 Fenner, B. et al. "Multicast Source Notification of Interest 
      Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress, 
      expired), March 2004. 
    
   88 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time 
      Applications", RFC 3550, July 2003. 
    
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, Lachlan 
   Andrew, Jari Arkko, Cedric Baudoin, Hans L. Cycon, Hui Deng, Marshall 
   Eubanks, Zhigang Huang, Christophe Jelger, Andrei Gutov, Rajeev 
   Koodli, Mark Palkow, Craig Partridge, Imed Romdhani, Hesham Soliman, 
   Dave Thaler and last, but not least, very special thanks to Stig 
   Venaas for his frequent and thorough advice. 
    
    
Author's Addresses 
    
   Thomas C. Schmidt 
   Dept. Informatik 
   Hamburg University of Applied Sciences,  
   Berliner Tor 7 
   D-20099 Hamburg, Germany 
   Phone: +49-40-42875-8157 

 
 
Schmidt, et al.          Expires - April 2010                [Page 34] 

                             MMCASTv6-PS                 October 2009 
 
 
   Email: schmidt@informatik.haw-hamburg.de 
     
    
   Matthias Waehlisch 
   link-lab 
   Hoenower Str. 35 
   D-10318 Berlin, Germany 
   Email: mw@link-lab.net 
    
   Godred Fairhurst 
   School of Engineering, 
   University of Aberdeen, 
   Aberdeen, AB24 3UE, UK 
   EMail: gorry@erg.abdn.ac.uk 
    
    
    

 
 
Schmidt, et al.          Expires - April 2010                [Page 35]