MobOpts Research Group                             Thomas C. Schmidt
   Internet Draft                                           HAW Hamburg
   Intended Status: Informational                    Matthias Waehlisch
   Expires: January 2009                                       link-lab
                                                       Godred Fairhurst
                                                 University of Aberdeen
                                                              July 2008

      Multicast Mobility in MIPv6: Problem Statement and Brief Survey

IPR Statement

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79 [1].

Status of this Memo

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   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
   The list of Internet-Draft Shadow Directories can be accessed at

   This document is a submission of the IRTF MobOpts RG. Comments should
   be directed to the MobOpts RG mailing list,


   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

Schmidt, Waehlisch      Expires - January 2009                [Page 1]

                             MMCASTv6-PS                    July 2008

   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.

Table of Contents

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

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

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

   4. Link Layer Aspects............................................13
     4.1 General Background.........................................13
     4.2 Multicast for Specific Technologies........................14
         4.2.1 802.11 WLAN..........................................14
         4.2.2 802.16 WIMAX.........................................14
         4.2.3 3GPP.................................................16
         4.2.4 DVB-H / DVB-IPDC.....................................16
     4.3 Vertical Multicast Handovers...............................17

   5. Solutions.....................................................17
     5.1 General Approaches.........................................17
     5.2 Solutions for Multicast Listener Mobility..................18
         5.2.1 Agent Assistance.....................................18
         5.2.2 Multicast Encapsulation..............................19
         5.2.3 Hybrid Architectures.................................19
         5.2.4 MLD Extensions.......................................20
     5.3 Solutions for Multicast Source Mobility....................21
         5.3.1 Any Source Multicast Mobility Approaches.............21
         5.3.2 Source Specific Multicast Mobility Approaches........21

   6. Security Considerations.......................................22

   7. Summary and Future Steps......................................23

Schmidt, Waehlisch      Expires - January 2009                [Page 2]

                             MMCASTv6-PS                    July 2008

   8. IANA Considerations...........................................24

   Appendix A. Implicit Source Notification Options.................24

   9. References....................................................24


   Author's Addresses...............................................31

   Intellectual Property Statement..................................32

   Copyright Notice.................................................32

   Disclaimer of Validity...........................................33


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 [2] soon lead to a wide
   adoption of Deering's host group model [3]. 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 [4] 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 [5] is standardized in the Mobile IPv6 RFCs [6,7].
   MIPv6 [6] only roughly defines multicast mobility for Mobile Nodes
   (MN), using a remote subscription approach 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

Schmidt, Waehlisch      Expires - January 2009                [Page 3]

                             MMCASTv6-PS                    July 2008

   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

   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 requirement on mobility protocols: Typical seamless handover
   scenarios are expected to limit disruptions or delay to less than 100
   ms. Jitter disturbances should not exceed 50 ms. Note that 100 ms is
   about the duration of a spoken syllable in real-time audio. 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.

1.1Document 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

   When considering multicast node mobility, two basic scenarios 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 [6]. The key
   issues of mobile multicast membership control, and the interplay of
   mobile and multicast routing will be illustrated using this simple

   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

Schmidt, Waehlisch      Expires - January 2009                [Page 4]

                             MMCASTv6-PS                    July 2008

   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

                      Figure 1: Mobility Scenarios

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) [3] 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-

Schmidt, Waehlisch      Expires - January 2009                [Page 5]

                             MMCASTv6-PS                    July 2008

   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]. Other
   multicast routing protocols without significant current deployment
   include CBT [18], BGMP [19].

   Any multicast mobility solution must take all of these functional
   blocks into account. It should enable seamless continuity of
   multicast sessions when moving from one IPv6 subnet to another. It
   should preserve the multicast nature of packet distribution and
   approximate optimal routing. It should support per-flow handover for
   multicast traffic, 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 [6], its security
   extensions [7,20], its expediting schemes FMIPv6 [21] and HMIPv6
   [22], its context transfer protocols [23], its multihoming
   capabilities [24,25], emerging protocols like PMIPv6 [61] 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 topology of the sender(s)
   and receiver(s) participating in a multicast session, which then may
   change under mobility. However, depending on the topology and the
   protocol in use, current multicast routing protocols may require a
   time close to seconds, or even minutes, to converge following a
   change in receiver or sender location. This is far too slow to
   support seamless handovers for interactive or real-time media
   sessions. The actual temporal behavior strongly depends on the
   multicast routing protocol in use, 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 must be performed (loss recovery, content

Schmidt, Waehlisch      Expires - January 2009                [Page 6]

                             MMCASTv6-PS                    July 2008

   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 foreseeable degradations at
   the transport layer.

   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 [26]. 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
   addreses. 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.,
   multicast senders, forwarders and receivers, need to carefully
   account for address duality issues, e.g., by using binding caches,
   extended multicast states or signaling.

   Multicast sources in general operate decoupled from their receivers
   in the following sense: A multicast source sends packets to a group
   of unknown receivers and thus operates without a feedback channel. It
   neither has means to inquire 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 loosing 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.

Schmidt, Waehlisch      Expires - January 2009                [Page 7]

                             MMCASTv6-PS                    July 2008

   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: The new network may not be multicast-enabled or
   the specific multicast service may be unavailable, e.g. unsupported
   or prohibited. Alternatively, the requested multicast service may be
   supported and enabled in the visited network, but the multicast
   groups under subscription may not be forwarded to it. This means that
   current distribution trees for the desired groups may only be re-
   joined at a large routing distance. The simplest scenario is when
   packets of some, or all, of the subscribed groups of the mobile node
   are already received by one or several group members in the
   destination network, and thus multicast streams natively flow after
   the MN arrives at the new network.

   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 to a fraction of 100 ms.
     o Minimize packet loss and reordering that result from multicast
       handover management.

   Moreover, in many wireless regimes it is also desirable to minimize
   multicast-related signaling to preserve the limited resources of
   battery powered mobile devices and the constrained transmission
   capacities of the networks. This may lead to a 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.

Schmidt, Waehlisch      Expires - January 2009                [Page 8]

                             MMCASTv6-PS                    July 2008

   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.
     o Avoid avalanche problems and 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 issue
   traffic directives that lead to suboptimal routing, i.e., erroneous
   subscriptions following predictive handover operations, or slow
   effective leaves caused by MLD querying, 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

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

Schmidt, Waehlisch      Expires - January 2009                [Page 9]

                             MMCASTv6-PS                    July 2008

   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 precede
   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 [6].

   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 [26], e.g., the primary rendezvous
   point for inter-domain PIM-SM will be globally appointed and the
   signaling requirements obsolete.

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

Schmidt, Waehlisch      Expires - January 2009               [Page 10]

                             MMCASTv6-PS                    July 2008

   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 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
   network operations. The SSM design permits trust in equivalence to
   the correctness of unicast routing tables. Any SSM mobility solution
   should preserve this degree of confidence. Binding updates for SSM
   sources thus should have to prove address correctness in the unicast
   routing sense, which is equivalent to binding update security with a
   correspondent node in MIPv6 [6].

   The above methods add significant complexity to provide a robust SSM
   mobility solution, which needs to converge to optimal routes and, for
   efficiency, should avoid data encapsulation. Like ASM, handover
   management is a time-critical operation. The routing distance between
   subsequent points of attachment, the 'step size' of the mobile from
   previous to next designated router, may serve as an appropriate
   measure of complexity [27,28].

   Finally, Source Specific Multicast has been designed as a light-
   weight approach to group communication. In adding mobility
   management, it is desirable to preserve the leanness of SSM by
   minimizing additional signaling overhead.

2.4 Deployment Issues

   IP multicast deployment in general has been hesitant over the past 15
   years, even though all major router vendors and operating systems
   offer implementations that support multicast [29]. While many
   (walled) domains or enterprise networks operate point-to-multipoint
   services, IP multicast rollout is currently limited in public inter-
   domain scenarios [30]. A dispute arose on the appropriate layer,
   where group communication service should reside, and the focus of the
   research community turned towards application layer multicast. This
   debate on "efficiency versus deployment complexity" now overlaps the
   mobile multicast domain [31]. Garyfalos and Almeroth [32] derived

Schmidt, Waehlisch      Expires - January 2009               [Page 11]

                             MMCASTv6-PS                    July 2008

   from fairly generic principles that when mobility is introduced, the
   performance gap between IP and application layer multicast widens in
   different metrics up to a factor of four.

   Facing deployment complexity, it is desirable that any solution for
   mobile multicast should leave routing protocols unchanged. Mobility
   management in such 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 [33,34] or IPTV develop a strong business case for IP
   portables. As IP mobility becomes an important service and as
   efficient link utilization is of a larger impact in costly radio
   environments, the evolution of multicast protocols will naturally
   follow mobility constraints.

3.Characteristics of Multicast Routing Trees under Mobility

   Multicast distribution trees have been studied from a focus of
   network efficiency. Grounded on empirical observations Chuang and
   Sirbu [35] 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

   Subsequent empirical and analytical work [36,37] debated the
   applicability of the Chuang and Sirbu scaling law. Van Mieghem et al.
   [36] proved that the proposed power law cannot hold for an increasing
   Internet or very large multicast groups, but is indeed applicable for
   moderate receiver numbers and the current Internet size N = 10^5 core
   nodes. Investigating self-similarity Janic and Van Mieghem [38] semi-
   empirically substantiated that multicast shortest path trees in the
   Internet can be modeled with reasonable accuracy by uniform recursive
   trees (URT) [39], provided m remains small compared to N.

   The mobility perspective on shortest path trees focus on their
   alteration, i.e., the degree of topological changes induced by
   movement. For receivers, and more interestingly for sources this may
   serve as an outer measure for routing complexity. Mobile listeners
   moving to neighboring networks will only alter tree branches

Schmidt, Waehlisch      Expires - January 2009               [Page 12]

                             MMCASTv6-PS                    July 2008

   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 [28], both analytically and by
   simulations. It was found that even in large networks and for
   moderate receiver numbers more than 80 % of the multicast router
   states remain invariant under a source handover.

4. Link Layer Aspects

4.1 General Background

   Scalable group data distribution has the highest potential in leaf
   networks, where large numbers of end systems reside. Consequently, it
   is not surprising that most LAN network access technologies natively
   support point-to-multipoint or multicast services. Of focal interest
   to the mobility domain are wireless access technologies, which always
   operate on a shared medium with limited frequency and bandwidth.

   Several aspects need consideration: First, dissimilar network access
   radio technologies cause distinct group traffic transmissions. There

    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

    o connection-oriented link services of a broadcast type, which are
      restricted to unidirectional data transmission.

   Second, point-to-multipoint service activation at the network access
   layer requires a mapping mechanism from network layer requests. This
   function is commonly achieved by L3 awareness, i.e., IGMP/MLD
   snooping [67] or proxy [40], 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.

Schmidt, Waehlisch      Expires - January 2009               [Page 13]

                             MMCASTv6-PS                    July 2008

   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

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 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, operating in distinguished, unidirectional
   channels. The channel assignment is controlled by Base Stations,
   which assign channel IDs (CIDs) within service flows to the
   subscriber stations. Service flows may provide an optional Automatic

Schmidt, Waehlisch      Expires - January 2009               [Page 14]

                             MMCASTv6-PS                    July 2008

   Repeat Request (ARQ) to improve reliability and may operate in point-
   to-point or point-to-multipoint (restricted to downlink and without
   ARQ) mode.

   A WIMAX Base Station operates as a L2 switch in full duplex mode,
   where switching is based on CIDs. Two possible IPv6 link models for
   mobile access deployment scenarios exist: Shared IPv6 prefix and
   point-to-point link model [41]. The latter treats each connection to
   a mobile node as a single link and is recommended in the IPv6
   Convergence Sublayer [42], while MAC separation within a shared
   prefix is applied in the IP over Ethernet CS [43]. The point-to-point
   link model on the IP layer conflicts with a consistent group
   distribution via a shared medium (cf. section 4.1 for MVR as a

   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 [44]. For
   selecting group members, a Base Station may implement IGMP/MLD
   snooping or proxy as foreseen in 802.16e-2005 [45].

   A Subscriber Station will send multicast data to a Base Station as a
   point-to-point unicast stream, which - in the presence of the IPv6 CS
   - is forwarded to the upstream access router. The access router or -
   in the presence of the IP over Ethernet CS - the Base Station may
   return multicast data to the downstream Base Station by feeding into
   a multicast service channel. On reception, a Subscriber Station
   cannot distinguish multicast from unicast streams.

   Multicast services have the following characteristics:

    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 are very likely due
      to the short ID space. As a consequence, multicast data
      transmission may occur in joint point-to-multipoint groups of
      reduced selectiveness.

    o The point-to-point link model for mobile access contradicts a
      consistent mapping of IP layer multicast onto 802.16
      point-to-multipoint services.

Schmidt, Waehlisch      Expires - January 2009               [Page 15]

                             MMCASTv6-PS                    July 2008

    o Multipoint channels cannot operate ARQ service and thus
      experience a reduced reliability.

4.2.3 3GPP

   The 3GPP System architecture spans a circuit switched (CS) and a
   packet switched (PS) domain, the latter General Packet Radio Services
   (GPRS) incorporates the IP Multimedia Subsystem (IMS) [46]. 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 [47]. Current packet filtering practice causes inter-working
   problems between Mobile IPv6 nodes connected via GPRS [48].

   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

   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

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 [49] (see DVB uses a mechanism called
   multi-protocol encapsulation (MPE), which enables a transport of
   network layer protocols on top of a link layer built from MPEG-2
   transport streams and includes link forward error correction (FEC).
   In this model, DVB transmission networks not only support TV
   broadcasting, but also offer an IP Datacast Service. DVB-IPDC [33]
   consists of a number of individual, application layer specifications,
   some of which continue to be developed. Transport Streams (TS) form
   the basic logical channels, identified by a 13 bit TS ID (PID). This,

Schmidt, Waehlisch      Expires - January 2009               [Page 16]

                             MMCASTv6-PS                    July 2008

   together with a multiplex service ID, is associated with IPv4 or IPv6
   addresses [50] and used for selective traffic filtering at receivers.
   Upstream channels may complement DVB-H using alternative transmission

   Multicast distribution services are defined by a mapping of groups
   onto appropriate PIDs, which is managed at the IP Encapsulator [51].
   To increase flexibility and avoid collisions, this address resolution
   is facilitated by dynamic tables, provided within the self-consistent
   MPEG-2 TS. Mobility is supported in the sense that changes of cell
   ID, network ID or Transport Stream ID are foreseen [52]. 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.3 Vertical Multicast Handovers

   A mobile multicast node may operate homogeneous (horizontal) or
   heterogeneous (vertical) layer 2 handovers with or without layer 3
   network changes. Consequently, a dedicated context transfer of
   multicast configuration is required at network access. Media
   Independent Handover (MIH) is addressed in IEEE 802.21 [53], but is
   relevant also beyond IEEE protocols. Mobility services transport for
   MIH naturally reside on the network layer and are currently in the
   process of specification [54].

   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 [55]:

Schmidt, Waehlisch      Expires - January 2009               [Page 17]

                             MMCASTv6-PS                    July 2008

    o Bi-directional Tunnelling, in which the mobile node tunnels all
      multicast data via its home agent. This fundamental multicast
      solution hides all movement and results in static multicast
      trees. It may be employed transparently by mobile multicast
      listeners and sources, at the cost of triangular routing and
      possibly significant performance 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 tunnelling
      proxies, allowing for some inter-agent handover when the mobile
      node moves. A decelerated inter-tree handover, i.e. 'tree
      walking', will be the outcome of agent-based multicast mobility,
      where some extra effort is needed to sustain session persistence
      through address transparency of mobile sources.

   MIPv6 [6] introduces bi-directional tunnelling as well as remote
   subscription as minimal standard solutions. Various publications
   suggest utilizing remote subscription for listener mobility only,
   while advising bi-directional tunnelling as the solution for source
   mobility. Such an approach avoids the 'tunnel convergence' or
   'avalanche' problem [55], 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

   None of the above approaches address SSM source mobility, except the
   use of bi-directional tunnelling.

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 [21], the M-FMIPv6 [56,57], and of

Schmidt, Waehlisch      Expires - January 2009               [Page 18]

                             MMCASTv6-PS                    July 2008

   Hierarchical MIPv6 [22], the M-HMIPv6 [58], and to context transfer
   [59], which have been thoroughly analyzed in [27,60].

   Network based mobility management, PMIPv6 [61], at its current stage
   of evolution is multicast transparent, as the MN experiences a point-
   to-point home link fixed at its local mobility anchor (LMA). A PMIPv6
   domain thereby inherits the tunnel convergence problem; future
   optimizations and extensions to shared links should foresee native
   multicast distribution towards the edge network, including context
   transfer between access gateways to assist IP-mobility-agnostic MNs.

   An approach based on dynamically negotiated inter-agent handovers is
   presented in [62]. Aside from IETF work, countless publications
   present proposals for seamless multicast listener mobility, e.g. [63]
   provides a comprehensive overview.

5.2.2 Multicast Encapsulation

   Encapsulation of multicast data packets is an established method to
   shield mobility and to enable access to remotely located data
   services, e.g., streams from the home network. Applying generic
   packet tunnelling in IPv6 [64] 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

   Multicast enabled environments may take advantage of point-to-
   multipoint encapsulation, i.e., generic packet tunnelling using an
   appropriate multicast destination address in the outer header. Such
   multicast-in-multicast encapsulated packets 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 [32]. The authors presented an Intelligent Gateway

Schmidt, Waehlisch      Expires - January 2009               [Page 19]

                             MMCASTv6-PS                    July 2008

   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 [65] introduced
   a mobility-agnostic multicast backbone on the overlay.

   Current work in the SAM RG is developing general architectural
   approaches for hybrid multicast solutions [66] 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 [67]) 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 optimised performance by
   implementing a listener node table at the access router that can
   eliminate query timeouts on leaves (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 is not fulfilled). Backward context transfer
   may otherwise ensure a leave is signaled. A further optimization was
   introduced by Jelger and Noel [68] 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 regular 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

   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 [68] propose
   an extension to MLD, introducing a Listener Hold message that is
   exchanged between the MN and the HA. This idea was developed in [58]
   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

Schmidt, Waehlisch      Expires - January 2009               [Page 20]

                             MMCASTv6-PS                    July 2008

   recent (video) frame buffer, to enable fast channel switching between
   several IPTV multicast flows (zapping).

5.3 Solutions for Multicast Source Mobility

5.3.1 Any Source Multicast Mobility Approaches

   Solutions for multicast source mobility can be divided in to three

    o Statically Rooted Distribution Trees. These methods follow a
      shared tree approach. Romdhani et al. [69] 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 [58] 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 [70] 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 [71] 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 [69] 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
   re-introduces the concept of rendezvous points to SSM routing.

Schmidt, Waehlisch      Expires - January 2009               [Page 21]

                             MMCASTv6-PS                    July 2008

   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 [72] proposed introducing
   a binding cache and providing source address transparency analogous
   to MIPv6 unicast communication. Initial session announcements and
   changes of source addresses are distributed periodically to clients
   via an additional multicast control tree rooted at the home agent.
   Source tree handovers are then activated on listener requests.

   Jelger and Noel [73] 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 [74]. Receiver-oriented tree
   construction in SSM thus remains unsynchronized with source

   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
   [75] optimized SPT for a moving source on the path between the source
   and first branching point. O'Neill [76] 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 [77] 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. Lee et al. [78] 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.

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, Waehlisch      Expires - January 2009               [Page 22]

                             MMCASTv6-PS                    July 2008

   solution jointly operating binding updates for unicast and multicast

   Admission control issues may arise with new CoA source addresses
   being introduced to SSM channels (cf. [79] for a comprehensive
   discussion). Due to lack of feedback, the admission [80] and binding
   updates [81] of mobile multicast sources require self-consistent
   authentication as achievable by Cryptographically Generated Addresses

   Modification to IETF protocols (e.g. routing, membership, session
   announcement and control) 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:

        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

        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.

Schmidt, Waehlisch      Expires - January 2009               [Page 23]

                             MMCASTv6-PS                    July 2008

     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 multicats 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) [82] 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.

   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) [83].  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
   visble 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.

9. References

Informative References

   1  S. Bradner, "Intellectual Property Rights in IETF Technology", BCP
      79, RFC 3979, March 2005.

Schmidt, Waehlisch      Expires - January 2009               [Page 24]

                             MMCASTv6-PS                    July 2008

   2  Aguilar, L. "Datagram Routing for Internet Multicasting", In ACM
      SIGCOMM '84 Communications Architectures and Protocols, pp. 58-63,
      ACM Press, June, 1984.

   3  S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
      August 1989.

   4  G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts",
      IEEE Communications Magazine, 35(1), pp. 54-58, January 1997.

   5  R. Hinden and S. Deering, "Internet Protocol Version 6
      Specification", RFC 2460, December 1998.

   6  D.B. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
      RFC 3775, June 2004.

   7  V. Devarapalli and F. Dupont, "Mobile IPv6 Operation with IKEv2
      and the Revised IPsec Architecture", RFC 4877, April 2007.

   8  Akyildiz, I and Wang, X. "A Survey on Wireless Mesh Networks",
      IEEE Communications Magazine, 43(9), pp. 23-30, September 2005.

   9  S. Bhattacharyya, "An Overview of Source-Specific Multicast
      (SSM)", RFC 3569, July 2003.

   10 H. Holbrook, B. Cain, "Source-Specific Multicast for IP", RFC
      4607, August 2006.

   11 D. Waitzman, C. Partridge, S.E. Deering, "Distance Vector
      Multicast Routing Protocol", RFC 1075, November 1988.

   12 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
      Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei, "Protocol
      Independent Multicast-Sparse Mode (PIM-SM): Protocol
      Specification", RFC 2362, June 1998.

   13 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol
      Independent Multicast - Sparse Mode PIM-SM): Protocol
      Specification (Revised)", RFC 4601, August 2006.

   14 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano, "Bidirectional
      Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October

   15 T. Bates et al. "Multiprotocol Extensions for BGP-4", RFC 4760,
      January 2007.

Schmidt, Waehlisch      Expires - January 2009               [Page 25]

                             MMCASTv6-PS                    July 2008

   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 A. Ballardie "Core Based Trees (CBT version 2) Multicast Routing",
      RFC 2189, September 1997.

   19 D. Thaler "Border Gateway Multicast Protocol (BGMP): Protocol
      Specification", RFC 3913, September 2004.

   20 Arkko, J, Vogt, C, Haddad, W. "Enhanced Route Optimization for
      Mobile IPv6", RFC 4866, May 2007.

   21 Koodli, R. "Mobile IPv6 Fast Handovers", RFC 5268, June 2008.

   22 Soliman, H, Castelluccia, C, El-Malki, K, Bellier, L.
      "Hierarchical Mobile IPv6 mobility management", RFC 4140, August

   23 Loughney, J, Nakhjiri, M, Perkins, C, Koodli, R. "Context Transfer
      Protocol (CXTP)", RFC 4067, July 2005.

   24 Montavont, N, et al. "Analysis of Multihoming in Mobile IPv6",
      draft-ietf-monami6-mipv6-analysis-05, Internet Draft (work in
      progress), May 2008.

   25 Narayanan, V, Thaler, D, Bagnulo, M, Soliman, H. "IP Mobility and
      Multi-homing Interactions and Architectural Considerations",
      draft-vidya-ip-mobility-multihoming-interactions-01.txt, Internet
      Draft (work in progress), July 2007.

   26 Savola, P, Haberman, B. "Embedding the Rendezvous Point (RP)
      Address in an IPv6 Multicast Address", RFC 3956, November 2004.

   27 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive -
      Analysis of Handover Performance and Its Implications on IPv6 and
      Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123-
      142, November 2005.

   28 Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On
      the Evolution of Multicast States under Mobility and an Adaptive
      Routing Scheme for Mobile SSM Sources", Telecommunication Systems,
      Vol. 33, No. 1-3, pp. 131-154, December 2006.

Schmidt, Waehlisch      Expires - January 2009               [Page 26]

                             MMCASTv6-PS                    July 2008

   29 Diot, C. et al. "Deployment Issues for the IP Multicast Service
      and Architecture", IEEE Network Magazine, spec. issue on
      Multicasting 14(1), pp. 78-88, 2000.

   30 Eubanks, M., 2008.

   31 Garyfalos, A, Almeroth, K. and Sanzgiri, K. "Deployment Complexity
      Versus Performance Efficiency in Mobile Multicast", Intern.
      Workshop on Broadband Wireless Multimedia: Algorithms,
      Architectures and Applications (BroadWiM), San Jose, California,
      USA, October 2004. Online:

   32 Garyfalos, A, Almeroth, K. "A Flexible Overlay Architecture for
      Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm, 23
      (11), pp. 2194-2205, November 2005.

   33 "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of
      Specifications for Phase 1", ETSI TS 102 468;

   34 ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast
      over DVB-H: Implementation Guidelines for Mobility)", European
      Standard (Telecommunications series), November 2004.

   35 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.

   36 Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency of
      Multicast", IEEE/ACM Trans. Netw., 9, 6, pp. 719-732, Dec. 2001.

   37 Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast
      trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003.

   38 Janic, M. and Van Mieghem, P. "On properties of multicast routing
      trees", Int. J. Commun. Syst. 19(1), pp. 95-114, Feb. 2006.

   39 Van Mieghem, P. "Performance Analysis of Communication Networks
      and Systems", Cambridge University Press, 2006.

   40 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.

   41 Shin, M. et al. "IPv6 Deployment Scenarios in 802.16 Networks",
      RFC 5181, May 2008.

Schmidt, Waehlisch      Expires - January 2009               [Page 27]

                             MMCASTv6-PS                    July 2008

   42 Patil, B. et al. "Transmission of IPv6 via the IPv6 Convergence
      Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.

   43 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.16-06.txt, (work in progress), April 2008.

   44 Kim, S. et al. "Multicast Transport on IEEE 802.16 Networks",
      draft-sekim-802-16-multicast-01, (work in progress), July 2007.

   45 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.

   46 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.

   47 Wasserman, M. "Recommendations for IPv6 in Third Generation
      Partnership Project (3GPP) Standards", RFC 3314, September 2002.

   48 Chen, X, Rinne, J. and Wiljakka, J. "Problem Statement for MIPv6
      Interactions with GPRS/UMTS Packet Filtering", draft-chen-mip6-
      gprs-07.txt, (work in progress), January 2007.

   49 ETSI EN 302 304, "Digital Video Broadcasting (DVB); Transmission
      System for Handheld Terminals (DVB-H)", European Standard
      (Telecommunications series), November 2004.

   50 Fairhurst, G. and Montpetit, M. "Address Resolution Mechanisms for
      IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.

   51 Montpetit, M. et al. "A Framework for Transmission of IP Datagrams
      over MPEG-2 Networks", RFC 4259, November 2005.

   52 Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in
      DVB-H", IEEE Comm. Surveys, 8(4), 2006.

   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.

Schmidt, Waehlisch      Expires - January 2009               [Page 28]

                             MMCASTv6-PS                    July 2008

   55 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, online http://www.comnets.rwth-

   56 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.

   57 Xia, F. and Sarikaya, B, "FMIPv6 extensions for Multicast
      Handover", draft-xia-mipshop-fmip-multicast-01, (work in progress,
      expired), March 2007.

   58 Schmidt, T.C. and Waehlisch, M, "Seamless Multicast Handover in a
      Hierarchical Mobile IPv6 Environment(M-HMIPv6)", draft-schmidt-
      waehlisch-mhmipv6-04.txt, (work in progress, expired), December

   59 Jonas, K. and Miloucheva, I, "Multicast Context Transfer in mobile
      IPv6", draft-miloucheva-mldv2-mipv6-00.txt, (work in progress,
      expired), June 2005.

   60 Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast
      mobility support using fast MIPv6 extensions", Computer Comm. 29,
      pp. 3745-3765, 2006.

   61 Gundavelli, S, et al. "Proxy Mobile IPv6", draft-ietf-netlmm-
      proxymip6-18.txt, (work in progress), May 2008.

   62 Zhang, H. et al. "Mobile IPv6 Multicast with Dynamic Multicast
      Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in
      progress), January 2007.

   63 Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile Multicast:
      Challenges and Solutions", IEEE Comm. Surveys, 6(1), 2004.

   64 Conta, A, Deering, S, "Generic Packet Tunneling in IPv6 -
      Specification", RFC 2473, December 1998.

   65 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.

Schmidt, Waehlisch      Expires - January 2009               [Page 29]

                             MMCASTv6-PS                    July 2008

   66 Buford, J. "Hybrid Overlay Multicast Framework", draft-irtf-sam-
      hybrid-overlay-framework-02.txt, Internet Draft (work in
      progress), February 2008.

   67 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.

   68 Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks:
      Progress and Challenges", IEEE Wirel. Comm, pp 58-64, Oct. 2002.

   69 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.

   70 Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based Mobile
      Networks", Wireless Networks, 8 (1), pp. 27-36, January, 2002.

   71 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.

   72 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings
      of ietf meeting, Dec. 2001.

   73 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6
      (MSSMSv6)", Internet Draft (work in progress, expired), January

   74 Handley, M, Perkins, C, Whelan, E. "Session Announcement
      Protocol", RFC 2974, October 2000.

   75 Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility
      Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press

   76 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill-
      mip-multicast-00.txt, (work in progress, expired), July 2002.

   77 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.

   78 Lee, H, Han, S. and Hong, J. "Efficient Mechanism for Source
      Mobility in Source Specific Multicast", in K. Kawahara and I.

Schmidt, Waehlisch      Expires - January 2009               [Page 30]

                             MMCASTv6-PS                    July 2008

      Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp. 82-91,
      Springer-Verlag, Berlin, Heidelberg, 2006.

   79 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.

   80 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.

   81 Christ, O, Schmidt, T.C, Waehlisch, M. "A Light-Weight
      Implementation Scheme of the Tree Morphing Protocol for Mobile
      Multicast Sources ", Proc. of 33rd Euromicro Conf, pp. 149-156,
      IEEE/CS Press, Sept. 2007.

   82 Fenner, B. et al. "Multicast Source Notification of Interest
      Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress,
      expired), March 2004.

   83 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time
      Applications", RFC 3550, July 2003.


   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-

   Since then, many people have actively discussed the different issues
   and contributed to the enhancement of this memo. The authors would
   like to thank (in alphabetical order) Kevin C. Almeroth, Hans L.
   Cycon, Hui Deng, Zhigang Huang, Christophe Jelger, Rajeev Koodli,
   Mark Palkow, 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
   Hamburg University of Applied Sciences,

Schmidt, Waehlisch      Expires - January 2009               [Page 31]

                             MMCASTv6-PS                    July 2008

   Dept. Informatik
   Berliner Tor 7
   D-20099 Hamburg, Germany
   Phone: +49-40-42875-8157

   Matthias Waehlisch
   Hoenower Str. 35
   D-10318 Berlin, Germany

   Godred Fairhurst
   School of Engineering,
   University of Aberdeen,
   Aberdeen, AB24 3UE, UK

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights. Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-

Copyright Notice

   Copyright (C) The IETF Trust (2008) This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.

Schmidt, Waehlisch      Expires - January 2009               [Page 32]

                             MMCASTv6-PS                    July 2008

Disclaimer of Validity

   This document and the information contained herein are provided on an


   Funding of the RFC Editor function is currently provided by the
   Internet Society.

Schmidt, Waehlisch      Expires - January 2009               [Page 33]