MobOpts Research Group                             Thomas C. Schmidt
   Internet Draft                                           HAW Hamburg
                                                     Matthias Waehlisch
   Expires: April 2006                                      FHTW Berlin
                                                           October 2005

              Multicast Mobility in MIPv6: Problem Statement

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.

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,


   In this document we discuss mobility extensions to current IP layer
   multicast solutions. Problems arising from mobile group communication
   in general, in the case of multicast listener mobility and for mobile
   Any Source Multicast as well as Source Specific Multicast senders are
   documented subsequently. The principal approaches to multicast
   mobility are introduced in brief.

Schmidt, Waehlisch       Expires - April 2006                 [Page 1]

                               MMCASTv6-PS                   October 2005

Table of Contents

   1. Introduction and Motivation....................................2

   2. Problem Description............................................3
      2.1 Generals...................................................3
      2.2 Multicast Listener Mobility................................5
      2.3 Multicast Source Mobility..................................5
         2.3.1 Any Source Multicast Mobility.................. ......5
         2.3.2 Source Specific Multicast Mobility.............. .....6

   3. Solutions......................................................7

   4. Security Considerations........................................7

   5. IANA Considerations............................................8

   6. References.....................................................8


   Author's Addresses...............................................10

   Intellectual Property Statement..................................10

   Copyright Notice.................................................11

   Disclaimer of Validity...........................................11


1. Introduction and Motivation

   Group communication forms an integral building block of a wide
   variety of applications, ranging from public content distribution and
   streaming over voice and video conferencing, collaborative
   environments and gaming up to the self-organization of distributed
   systems. Its support by network layer multicast will be needed,
   whenever globally distributed, scalable, serverless or instantaneous
   communication is required. As broadband media delivery more and more
   emerges to be a typical mass scenario, scalability and bandwidth
   efficiency of multicast routing continuously gains relevance.
   Internet multicasting will be of particular importance to mobile

Schmidt, Waehlisch       Expires - April 2006                 [Page 2]

                               MMCASTv6-PS                   October 2005

   environments, where users commonly share frequency bands of limited
   capacity. The rapidly increasing mobile reception of 'infotainment'
   streams may soon require a wide deployment of mobile multicast

   The fundamental approach to deal with mobility in IPv6 [2] is stated
   in the Mobile IPv6 RFCs [3,4]. MIPv6 [3] only roughly treats
   multicast mobility, in a pure remote subscription approach or through
   bi-directional tunneling via the Home Agent. Whereas the remote
   subscription suffers from slow handovers, as it relies on multicast
   routing to adapt to handovers, bi-directional tunneling introduces
   inefficient overheads and delays due to triangular forwarding.
   Therefore both approaches cannot be considered solutions for a
   deployment on large scale. A mobile multicast service for a future
   Internet should admit 'close to optimal' routing at predictable and
   limited cost, robustness combined with a service quality compliant to
   real-time media distribution.

   Intricate multicast routing procedures, though, are not easily
   extensible to comply with mobility requirements. Any client
   subscribed to a group while in motion, requires delivery branches to
   pursue its new location; any mobile source requests the entire
   delivery tree to adapt to its changing positions. Significant effort
   has been already invested in protocol designs for mobile multicast
   receivers. Only limited work has been dedicated to multicast source
   mobility, which poses the more delicate problem [21].

   In multimedia conference scenarios each member commonly operates as
   receiver and as sender for multicast based group communication. In
   addition, real-time communication such as voice or video over IP
   places severe temporal requirement on mobility protocols: Seamless
   handover scenarios need to limit disruptions or delay to less than
   100 ms. Jitter disturbances are not to exceed 50 ms. Note that 100 ms
   is about the duration of a spoken syllable in real-time audio.

   It is the aim of this document, to specify the problem scope for a
   multicast mobility management as to be refined in future work. The
   attempt is made to subdivide the various challenges according to
   their originating aspects and to present existing proposals for
   solution, as well as major bibliographic references.

2. Problem Description

2.1 Generals

   Multicast mobility must be considered as a generic term, which
   subsumes a collection of quite distinct functions. At first,
   multicast communication divides into Any Source Multicast (ASM) [5]

Schmidt, Waehlisch       Expires - April 2006                 [Page 3]

                               MMCASTv6-PS                   October 2005

   and Source Specific Multicast (SSM) [6,7]. At second, multicast
   communication is asymmetric, so the roles of senders and receivers
   need distinction. Both individually may be mobile. Their interaction
   is facilitated by a multicast routing function s.a. DVMRP [8], PIM-
   SM/SSM [9,10] or CBT [11] and the multicast listener discovery
   protocol [12,13].

   Any multicast mobility solution must account for all of these
   functional blocks. It should enable seamless continuity of multicast
   sessions when moving from one IPv6 subnet to another. It should
   preserve the multicast nature of packet distribution and approximate
   optimal routing. It should support per flow handover for multicast
   traffic, as properties and designations of flows may be of individual

   Multicast routing dynamically adapts to session topologies, which
   then may change under mobility. However, routing convergence arrives
   at a time scale of seconds, even minutes and is far too slow to
   support seamless handovers for interactive or real-time media
   sessions. The actual temporal behavior strongly depends on the
   routing protocol in use and on the geometry of the current
   distribution tree. A mobility scheme that arranges for adjustments,
   i.e. partial changes or full reconstruction, of multicast trees is
   forced to make provision for time buffers sufficient for protocol
   convergence. Special attention is needed with a possible rapid
   movement of the mobile node, as this may occur at much higher rates
   than compatible with protocol convergence.

   IP layer multicast packet distribution is an unreliable service,
   which is bound to connectionless transport protocols. Packet loss
   thus will not be handled in a predetermined fashion. Mobile multicast
   handovers should not cause significant packet drops. Due to
   statelessness the bi-casting of multicast flows does not cause
   foreseeable degradations of the transport layer.

   Group addresses in general are location transparent, even though
   there are proposals to embed unicast prefixes or Rendezvous Point
   addresses [14]. Source addresses contributing to a multicast session
   are interpreted by the routing infrastructure and by receiver
   applications, which frequently are source address aware. Multicast
   therefore inherits the mobility address duality problem for source
   addresses, being a logical node identifier (HoA) at the one hand and
   a topological locator (CoA) at the other.

   Multicast sources in general operate decoupled from their receivers
   in the following sense: A multicast source submits data to a group of
   unknown receivers, thus operating without any feedback channel. It
   neither has means to inquire on properties of its delivery trees, nor
   will it be able to learn about the state of its receivers. In the

Schmidt, Waehlisch       Expires - April 2006                 [Page 4]

                               MMCASTv6-PS                   October 2005

   event of an inter-tree handover, a mobile multicast source therefore
   is vulnerable to loosing receivers without taking notice.

2.2 Multicast Listener Mobility

   A mobile multicast listener entering a new IP subnet may encounter
   either one of the following conditions: The new network may not be
   multicast enabled or the specific multicast service in use may be
   unsupported or prohibited. Alternatively the requested multicast
   service may be supported and enabled in the new network, but the
   multicast groups under subscription may not be forwarded to it. Then
   current distribution trees for the desired groups may reside at large
   routing distance. It may as well occur that some or all groups under
   subscription of the mobile node are received by one or several local
   group members at the instance of arrival and that multicast streams
   natively flow.

   The problem of achieving seamless multicast listener handovers is
   thus threefold:
     o Ensure multicast reception even in visited networks without
       appropriate multicast support.
     o Expedite primary multicast forwarding to comply with a seamless
       timescale at handovers.
     o Realize native multicast forwarding whenever applicable to
       preserve network resources and avoid data redundancy.

   Additional aspects related to infrastructure remain. In changing its
   point of attachment a mobile receiver may not have enough time to
   leave groups in the previous network. Also, packet duplication and
   disorder may result from the change of topology.

2.3 Multicast Source Mobility

2.3.1 Any Source Multicast Mobility

   A node submitting data to an ASM group defines the root of either a
   shared or source specific delivery tree. Beside root location
   forwarding along this delivery tree will be bound to a topological
   network address due to reverse path forwarding (RPF) checks. A mobile
   multicast source moving away is solely enabled to either inject data
   into a previously established delivery tree by using its previous
   topologically correct source address, or to (re-)define a multicast
   distribution tree compliant to its new location. In pursuing the
   latter the mobile sender will have to proceed without control of the
   new tree construction due to decoupling of sender and receivers.

   A mobile multicast source consequently must meet address transparency
   at two layers: In order to comply with RPF checks, it has to use an
   address within the IPv6 basic header's source field, which is in

Schmidt, Waehlisch       Expires - April 2006                 [Page 5]

                               MMCASTv6-PS                   October 2005

   topological accordance with the employed multicast distribution tree.
   For application transparency the logical node identifier, commonly
   the HoA, must be presented as packet's source address to the socket
   layer at the receiver side.

   Conforming to address transparency and temporal handover constraints
   will be the key problem for any route optimizing mobility solution.
   Additional issues arrive from possible packet loss and from multicast
   scoping. A mobile source away from home must attend scoping
   restrictions which arise from its home and its visited location [3].

   In presence of inter- domain multicast routing a change of address
   must trigger the exchange of a new multicast source record.

2.3.2 Source Specific Multicast Mobility

   Fundamentally Source Specific Multicast has been designed for
   changeless addresses of multicast senders. Source addresses in client
   subscription to SSM groups are directly used for route
   identification. Any SSM subscriber is thus forced to know the
   topological address of its group contributors. SSM source
   identification invalidates, when source addresses change under

   Consequently source mobility for SSM packet distribution introduces a
   significant conceptual complexity in addition to the problems of
   mobile ASM. As a listener is subscribed to an (S,G) channel
   membership and as routers have established an (S,G)-state shortest
   path tree rooted at source S, any change of source addresses under
   mobility requests for state updates at all routers and all receivers.
   A moving source would have to update its change of CoA with all
   listeners, which subsequently had to newly subscribe and initiate
   corresponding source-specific trees. As the principle multicast
   decoupling of a sender from its receivers likewise holds for SSM, the
   need for client update turns into a severe problem.

   An SSM listener subscribing to or excluding any specific multicast
   source, may want to rely on the 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 [3].

   All of the above severely add complexity to a robust SSM mobility
   solution, which should converge to optimal routes and, for the sake
   of efficiency, should avoid data encapsulation, as well. Like in ASM
   handover delays are to be considered critical. The distance of

Schmidt, Waehlisch       Expires - April 2006                 [Page 6]

                               MMCASTv6-PS                   October 2005

   subsequent points of attachment, the ’step size’ of the mobile, may
   serve as an appropriate measure of complexity.

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

3. Solutions

   Three approaches to mobility in Any Source Multicast are commonly

    o Bi-directional Tunnelling guides the mobile node to tunnel all
   multicast data via its home agent. This principle multicast solution
   hides all movement and results in static multicast trees. It
   transparently may be employed by mobile multicast sources, on the
   price of triangular routing and possibly significant performance
   degradations due to widely spanned data tunnels.

    o Remote Subscription forces the mobile node to re-initiate
   multicast distribution subsequent to handover, using its current
   Care-of Address. This approach of tree discontinuation relies on
   multicast dynamics to adapt to network changes. It not only results
   in rigorous service disruption, but leads to mobility driven changes
   of source addresses, and thus disregards 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 while the mobile node moves
   away. 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.

   There are proposals of agent based approaches compliant to the
   unicast real-time mobility infrastructure of Fast MIPv6 [15], the M-
   FMIPv6 [16], and of Hierarchical MIPv6 [17], the M-HMIPv6 [18], and
   to context transfer [19]. An approach based on dynamically negotiated
   inter-agent handovers is presented in [20].

   It should be noted that none of the above approaches addresses SSM
   source mobility, except the bi-directional tunnelling.

4. Security Considerations

   This document discusses multicast extensions to mobility. Security
   issues arise from source address binding updates, specifically in the

Schmidt, Waehlisch       Expires - April 2006                 [Page 7]

                               MMCASTv6-PS                   October 2005

   case of source specific multicast. Threats of hijacking unicast
   sessions will result from any solution jointly operating binding
   updates for unicast and multicast sessions. Future solutions must
   address the security implications.

5. IANA Considerations

   There are no IANA considerations introduced by this draft.

6. References

Normative References

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

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

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

   4  Arkko, J., Devarapalli, V., Dupont, F "Using IPsec to Protect
      Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC
      3776, June 2004.

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

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

   7  H. Holbrook, B. Cain "Source-Specific Multicast for IP", draft-
      ietf-ssm-arch-07.txt (work in progress), October 2005.

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

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

   10 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas: "Protocol
      Independent Multicast - Sparse Mode PIM-SM): Protocol
      Specification(Revised)", draft-ietf-pim-sm-v2-new-11.txt (work in
      progress), October 2004.

Schmidt, Waehlisch       Expires - April 2006                 [Page 8]

                               MMCASTv6-PS                   October 2005

   11 A. Ballardie " Core Based Trees (CBT version 2) Multicast
      Routing", RFC 2189, September 1997.

   12 S. Deering, W. Fenner and B. Haberman "Multicast Listener
      Discovery (MLD) for IPv6", RFC 2710, October 1999.

   13 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version
      2 (MLDv2) for IPv6", RFC3810, June 2004.

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

   15 Koodli, R. "Fast Handovers for Mobile IPv6", RFC 4068, July 2004.

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

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

   18 Schmidt, T.C. and Waehlisch, M. "Seamless Multicast Handover in a
      Hierarchical Mobile IPv6 Environment(M-HMIPv6)", draft-schmidt-
      waehlisch-mhmipv6-03.txt, (work in progress), April 2005.

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

   20 Zhang, H. et al "Mobile IPv6 Multicast with Dynamic Multicast
      Agent" draft-zhang-mipshop-multicast-dma-01.txt, (work in
      progress), September 2005.

Informative References

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

   22 Jannetau, C., Tian, Y., Csaba, S. et al "Comparison of Three
      Approaches Towards Mobile Multicast", IST Mobile Summit 2003,
      Aveiro, Portugal, 16-18 June 2003, online http://www.comnets.rwth-

Schmidt, Waehlisch       Expires - April 2006                 [Page 9]

                               MMCASTv6-PS                   October 2005

   23 Mieghem, P., Hooghiemstra, G., Hofstad, R. "On the Efficiency of
      Multicast", Transactions on Networking, 9, 6, pp. 719 - 732,
      December 2001.

   24 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/2/3, Springer
      2005, in print.

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


   The authors would like to thank Mark Palkow (DaViKo GmbH) and Hans L.
   Cycon (FHTW Berlin) for valuable discussions and a joyful

Author's Addresses

   Thomas C. Schmidt
   HAW Hamburg, Dept. Informatik
   Berliner Tor 7
   D-20099 Hamburg
   Phone: +49-40-42875-8157

   Matthias Waehlisch
   FHTW Berlin, HRZ
   Treskowallee 8
   D-10318 Berlin

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

Schmidt, Waehlisch       Expires - April 2006                [Page 10]

                               MMCASTv6-PS                   October 2005

   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 Internet Society (2005). This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Disclaimer of Validity

   "This document and the information contained herein are provided on


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

Schmidt, Waehlisch       Expires - April 2006                [Page 11]