MobOpts Research Group                             Thomas C. Schmidt
   Internet Draft                                           HAW Hamburg
                                                     Matthias Waehlisch
   Expires: September 2007                                     link-lab
                                                             March 2007


              Multicast Mobility in MIPv6: Problem Statement
                <draft-schmidt-mobopts-mmcastv6-ps-02.txt>

IPR Statement

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

Status of this Memo

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

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

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



Abstract

   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. Characteristic aspects of multicast routing and
   deployment issues are summarized. The principal approaches to the
   multicast mobility problems are outlined subsequently.




Schmidt, Waehlisch     Expires - September 2007               [Page 1]


                             MMCASTv6-PS                   March 2007



Table of Contents


   1. Introduction and Motivation....................................3

   2. Problem Description............................................4
      2.1 Generals...................................................4
      2.2 Multicast Listener Mobility................................5
      2.3 Multicast Source Mobility..................................6
         2.3.1 Any Source Multicast Mobility.........................6
         2.3.2 Source Specific Multicast Mobility....................7
      2.4 Deployment Issues..........................................8

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

   4. Solutions......................................................9
      4.1 General Approaches.........................................9
      4.2 Solutions for Multicast Listener Mobility.................10
      4.3 Solutions for Multicast Source Mobility...................10
         4.3.1 Any Source Multicast Mobility Approaches.............10
         4.3.2 Source Specific Multicast Mobility Approaches........11

   5. Security Considerations.......................................12

   6. IANA Considerations...........................................12

   Appendix A. Implicit Source Notification Options.................12

   7. References....................................................13

   Acknowledgments..................................................17

   Author's Addresses...............................................17

   Intellectual Property Statement..................................18

   Copyright Notice.................................................18

   Disclaimer of Validity...........................................18

   Acknowledgement..................................................18









Schmidt, Waehlisch     Expires - September 2007               [Page 2]


                             MMCASTv6-PS                   March 2007


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. The
   idea of Internet multicasting already arose in the early days [2],
   its realization will be of particular importance to mobile
   environments, where users commonly share frequency bands of limited
   capacity. The rapidly increasing mobile reception of 'infotainment'
   streams may soon require a wide deployment of mobile multicast
   services. Multicast mobility consequently has been a concern for
   about ten years [3] and led to innumerous proposals, but no generally
   accepted solution.

   The fundamental approach to deal with mobility in IPv6 [4] is stated
   in the Mobile IPv6 RFCs [5,6]. MIPv6 [5] 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 none of the approaches can 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 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 [35].

   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.


Schmidt, Waehlisch     Expires - September 2007               [Page 3]


                             MMCASTv6-PS                   March 2007



   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) [7]
   and Source Specific Multicast (SSM) [8,9]. At second, the roles of
   senders and receivers are asymmetric and need distinction. Both may
   individually be mobile. Their interaction is facilitated by a
   multicast routing function such as DVMRP [10], PIM-SM/SSM [11,12],
   Bi-directional PIM [13] or CBT [14] and the multicast listener
   discovery protocol [15,16].

   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 distinct
   nature.

   Multicast routing dynamically adapts to session topologies, which
   then may change under mobility. However, depending on the topology
   and the protocol in use, routing convergence arrives at a time scale
   close to seconds, or 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



Schmidt, Waehlisch     Expires - September 2007               [Page 4]


                             MMCASTv6-PS                   March 2007


   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 [17]. Addresses of sources 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, i.e., the home address
   (HoA) at the one hand and a topological locator, the care-of-address
   (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 and thus operates 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
   event of an inter-tree handover, a mobile multicast source therefore
   is vulnerable to loosing receivers without taking notice. (Cf.
   Appendix A for implicit source notification approaches). Applying a
   mobility binding update or return routability procedure will likewise
   break the semantic of a receiver group remaining unidentified by the
   source and thus cannot be applied in unicast analogy.

2.2 Multicast Listener Mobility

   A mobile multicast listener entering a new IP subnet faces the
   problem of transferring the multicast membership context to its new
   point of attachment. It thereby 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 data of 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
   flow natively.

   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.


Schmidt, Waehlisch     Expires - September 2007               [Page 5]


                             MMCASTv6-PS                   March 2007



   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 either defines the root of a
   source specific shortest path tree (SPT), distributing data towards a
   rendezvous point or receivers, or it forwards data directly down a
   shared tree, e.g., via encapsulated PIM register messages. Aside from
   tunneling or shared trees, forwarding along source specific delivery
   trees 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, which may be a rendezvous point based shared tree, 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
   topological concordance 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 major problems 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 [5].

   Within intra-domain multicast routing the employment of shared trees
   may considerably relax mobility related complexity. Relying upon a
   static rendezvous point, a mobile source may continuously submit data
   by encapsulating packets with its previous topologically correct or
   home source address. Constraints even weaken, when bi-directional PIM
   is used. Intra-domain mobility is transparently covered by bi-
   directional shared trees, eliminating the need for tunneling data to
   reach the rendezvous point.

   However, issues arise in inter-domain multicast scenarios, whenever
   notification of source addresses is required between distributed


Schmidt, Waehlisch     Expires - September 2007               [Page 6]


                             MMCASTv6-PS                   March 2007


   instances of shared trees. A new CoA acquired after a mobility
   handover will necessarily be subject to inter-domain record exchange.
   In presence of embedded rendezvous point addresses [17], e.g., for
   inter-domain PIM-SM, the primary rendezvous point will be globally
   appointed and the signaling requirements obsolete.

2.3.2 Source Specific Multicast Mobility

   Fundamentally, Source Specific Multicast has been designed for static
   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
   mobility. Hence client implementations of SSM source filtering MUST
   be MIPv6 aware in the sense that a logical source identifier (HoA) is
   correctly mapped to its current topological correspondent (CoA).

   Consequently source mobility for SSM packet distribution requires a
   dedicated conceptual treatment 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. On source
   handover a new SPT needs to be established, which partly will
   coincide with the previous SPT, e.g., at the receiver side. As the
   principle multicast decoupling of a sender from its receivers
   likewise holds for SSM, client updates needed for switching trees
   turns into a severe problem.

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

   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 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 [43,47].

   Finally, Source Specific Multicast has been designed as a light-
   weight approach to group communication. In adding mobility


Schmidt, Waehlisch     Expires - September 2007               [Page 7]


                             MMCASTv6-PS                   March 2007


   management, it is desirable to preserve the principle leanness of SSM
   by minimizing additional signaling overheads.

2.4 Deployment Issues

   IP multicast deployment in general has been hesitant over the past 15
   years, even though all major router vendors and operating systems
   offer a wide variety of implementations to support multicast [44]. 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 into the mobile multicast
   domain [45]. Hereunto Garyfalos and Almeroth [24] derived from fairly
   generic principles that when mobility is introduced the performance
   gap between IP and application layer multicast widens in different
   metrics up to a factor of four.

   Therefore it is desirable that any solution to mobile multicast
   should leave routing protocols unchanged. Mobility management in such
   deployment-friendly schemes should preferably be handled at edge
   nodes, preserving the routing infrastructure in mobility agnostic
   condition. Facing the current state of proposals, the urge remains
   open to search for such simple, infrastructure transparent solutions,
   even though there are reasonable doubts, whether the desired can be
   achieved in all cases.

   Nevertheless, multicast services in mobile environments may soon
   become indispensable, when multimedia distribution services such as
   DVB will develop as a strong business case for IP portables. As IP
   mobility will unfold dominance and as efficient link utilization will
   show a larger impact in costly radio environments, the evolution of
   multicast protocols will naturally follow mobility constraints.

3.Characteristics of Multicast Routing Trees under Mobility

   Multicast distribution trees have been studied well under the focus
   of network efficiency. Grounded on empirical observations Chuang and
   Sirbu [38] proposed a scaling power-law for the total number of links
   in a multicast shortest path tree with m receivers (prop. m^k). The
   authors consistently identified the scale factor to attain the
   independent constant k = 0.8. The validity of such universal, heavy-
   tailed distribution suggests that multicast shortest path trees are
   of self-similar nature with many nodes of small, but few of higher
   degrees. Trees consequently would be shaped rather tall than wide.

   Subsequent empirical and analytical work, cf. [39,40], debated the
   applicability of the Chuang and Sirbu scaling law. Van Mieghem et al.
   [39] proved that the proposed power law cannot hold for an increasing
   Internet or very large multicast groups, but is indeed applicable for


Schmidt, Waehlisch     Expires - September 2007               [Page 8]


                             MMCASTv6-PS                   March 2007


   moderate receiver numbers and the current Internet size N = 10^5 core
   nodes. Investigating on self-similarity Janic and Van Mieghem [42]
   semi-empirically substantiated that multicast shortest path trees in
   the Internet can be modeled with reasonable accuracy by uniform
   recursive trees (URT) [41], provided m remains small compared to N.

   The mobility perspective on shortest path trees focuses on their
   alteration, i.e., the degree of topological changes induced by
   movement. For receivers, and more interestingly for sources this may
   serve as an outer measure for routing complexity. Source specific
   multicast trees subsequently generated from mobility handover steps
   are not independent, but highly correlated. They most likely branch
   to the identical receivers at one or several intersection points. By
   the self-similar nature, the persistent subtrees (of previous and
   next distribution tree), rooted at any such intersection point,
   exhibit again the scaling law behavior, are tall-shaped with nodes of
   mainly low degree and thus likely to coincide. Tree alterations under
   mobility have been studied in [43], 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. Solutions

4.1 General Approaches

   Three approaches to mobile Multicast are commonly around [36]:

    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 may be
   employed transparently by mobile multicast listeners and 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 by submitting an MLD
   listener report within the subnet it newly attached to. This approach
   of tree discontinuation relies on multicast dynamics to adapt to
   network changes. It not only results in rigorous service disruption,
   but leads to mobility driven changes of source addresses, and thus
   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



Schmidt, Waehlisch     Expires - September 2007               [Page 9]


                             MMCASTv6-PS                   March 2007


   effort is needed to sustain session persistence through address
   transparency of mobile sources.

   MIPv6 [5] 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 approach suffers from the drawback that multicast
   communication roles are not explicitly known at the network layer and
   may change or mix unexpectedly.

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


4.2 Solutions for Multicast Listener Mobility

   There are proposals of agent assisted handovers compliant to the
   unicast real-time mobility infrastructure of Fast MIPv6 [18], the M-
   FMIPv6 [19,20], and of Hierarchical MIPv6 [21], the M-HMIPv6 [22],
   and to context transfer [23], which have been thoroughly analyzed in
   [43,49]. A hybrid architecture of reactively operating proxy-gateways
   located at the Internet edges is introduced in [24]. An approach
   based on dynamically negotiated inter-agent handovers is presented in
   [25]. Aside from IETF work countless publications present proposals
   for seamless multicast listener mobility, cf. [35] for a
   comprehensive overview.

4.3 Solutions for Multicast Source Mobility

4.3.1 Any Source Multicast Mobility Approaches

   Solutions for the multicast source mobility problem can be sorted in
   three categories:

    o Statically Rooted Distribution Trees:

   Following a shared tree approach, Romdhani et al. [26] propose to
   employ Rendezvous Points of PIM-SM as mobility anchors. Mobile
   senders tunnel their data to these "Mobility-aware Rendezvous Points"
   (MRPs), whence in restriction to a single domain this scheme is
   equivalent to the bi-directional tunneling. Focusing on interdomain
   mobile multicast, the authors design a tunnel- or SSM-based backbone
   distribution of packets between MRPs.

    o Reconstruction of Distribution Trees:

   Several authors propose to construct a completely new distribution
   tree after the movement of a mobile source and thereby have to


Schmidt, Waehlisch     Expires - September 2007              [Page 10]


                             MMCASTv6-PS                   March 2007


   compensate routing delays. M-HMIPv6 [22] tunnels data into previously
   established trees rooted at mobility anchor points to compensate for
   routing delays until a protocol dependent timer expires. The RBMoM
   protocol [27] introduces additional Multicast Agents (MA), which
   advertise their service range. The mobile source registers with the
   closest MA and tunnels its data through it. When moving out of the
   previous service range, it will perform a MA discovery, a re-
   registration and continue data tunneling with its newly established
   Multicast Agent in its current vicinity.

    o Tree Modification Schemes:

   In the case of DVMRP routing, Chang and Yen [28] propose an algorithm
   to extend the root of a given delivery tree for incorporating a new
   source location in ASM. To fix DVMRP forwarding states and heal
   reverse path forwarding (RPF) check failures, the authors rely on a
   complex additional signaling protocol.

4.3.2 Source Specific Multicast Mobility Approaches

   The shared tree approach of [26] has been extended to SSM mobility by
   introducing the HoA address record to Mobility-aware Rendezvous
   Points. These MRPs operate on extended multicast routing tables,
   which simultaneously hold HoA and CoA and are thus enabled to
   logically identify the appropriate distribution tree. Mobility thus
   re-introduces rendezvous points to SSM routing.

   Approaches of reconstructing SPTs in SSM have to rely on client
   notification for initiating new router state establishment. At the
   same time they need to preserve address transparency to the client.
   To account for the latter, Thaler [29] proposes to employ binding
   caches and to obtain source address transparency analogous to MIPv6
   unicast communication. Initial session announcements and changes of
   source addresses are to be distributed periodically to clients via an
   additional multicast control tree based at the home agent. Source
   tree handovers are then activated on listener requests.
   Jelger and Noel [30] suggest handover improvements by employing
   anchor points within the source network, supporting a continuous data
   reception during client initiated handovers. Client updates are to be
   triggered out of band, e.g. by SDR. Receiver oriented tree
   construction in SSM thus remains unsynchronized with source
   handovers.

   Addressing this synchronization problem at the routing layer, several
   proposals concentrate on direct modification of distribution trees.
   Based on a multicast Hop-by-Hop protocol, a recursive scheme of loose
   unicast source routes with branch points, Vida et al [31] optimize
   SPTs for moving sources on the path between source and first
   branching point. O'Neill [32] suggests a scheme to overcome RPF check


Schmidt, Waehlisch     Expires - September 2007              [Page 11]


                             MMCASTv6-PS                   March 2007


   failures originating from multicast source address changes in a
   rendezvous point scenario by introducing extended routing
   information, which accompanies data in a Hop-by-Hop option "RPF
   redirect" header. The Tree Morphing approach of Schmidt and Waehlisch
   [33] uses source routing to extend the root of a previously
   established SPT, thereby injecting router state updates in a Hop-by-
   Hop option header. Using extended RPF checks the elongated tree
   autonomously initiates shortcuts and smoothly reduces to a new SPT
   rooted at the relocated source. Lee et al. [34] introduce a state
   update mechanism for re-using major parts of established multicast
   trees. The authors start from initially established distribution
   states centered at the mobile source's home agent. A mobile leaving
   its home network will signal a multicast forwarding state update on
   the path to its home agent and, subsequently, distribution states
   according to the mobile source's new CoA are implemented along the
   previous distribution tree. Multicast data then is intended to
   natively flow in triangular routes via the elongation and updated
   tree centered at the home agent. Consequently this mechanism refrains
   from using shortest path trees. Unfortunately the authors do not
   address the problem of RPF check failures in their paper.

5. Security Considerations

   This document discusses multicast extensions to mobility. Security
   issues arise from source address binding updates, specifically in the
   case of source specific multicast. Threats of hijacking unicast
   sessions will result from any solution jointly operating binding
   updates for unicast and multicast sessions. Admission control issues
   may arise with new CoA source addresses being introduced to SSM
   channels (cf. [37] for a comprehensive discussion). Future solutions
   must address the security implications.

6. IANA Considerations

   There are no IANA considerations introduced by this draft.

Appendix A. Implicit Source Notification Options

   A multicast source will transmit data to a group of receivers without
   any option of an explicit feedback channel. There are attempts though
   to implicitly obtain information on listening group members. One
   approach has been dedicated to inquire designated routers on the pure
   existence of receivers. Based on an extension of IGMP, the Multicast
   Source Notification of Interest Protocol (MSNIP) [48] was designed to
   allow for the multicast source querying its designated router.
   However, work on MSNIP has been terminated by IETF.

   A majority of real-time applications employ RTP [50] as its
   application layer transport protocol, which is accompanied by its


Schmidt, Waehlisch     Expires - September 2007              [Page 12]


                             MMCASTv6-PS                   March 2007


   control protocol RTCP. RTP is capable of multicast group distribution
   and RTCP receiver reports are submitted to the same group in the
   multicast case. Thus RTCP may be used to monitor, manage and control
   multicast group operations, as it provides a fairly comprehensive
   insight into group member statuses. However, RTCP information is
   neither present at the network layer nor does multicast communication
   presuppose the use of RTP.


7. References

Normative References

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

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

   3 G. Xylomenos and G.C. Plyzos "IP Multicast for Mobile Hosts", IEEE
      Communications Magazine, pp. 54-58, January 1997.

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

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

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

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

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

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

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

   11 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
      Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei "Protocol




Schmidt, Waehlisch     Expires - September 2007              [Page 13]


                             MMCASTv6-PS                   March 2007



      Independent Multicast-Sparse Mode (PIM-SM): Protocol
      Specification", RFC 2362, June 1998.

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

   13 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano "Bi-directional
      Protocol Independent Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-
      09.txt, (work in progress), February 2007.

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

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

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

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

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

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

   20 Xia, F. and Sarikaya, B. "FMIPv6 extensions for Multicast
      Handover", draft-xia-mipshop-fmip-multicast-00.txt, (work in
      progress), September 2006.

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

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

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





Schmidt, Waehlisch     Expires - September 2007              [Page 14]


                             MMCASTv6-PS                   March 2007



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

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

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

   27 Lin, C.R. et al., "Scalable Multicast Protocol in IP-Based Mobile
      Networks", Wireless Networks and Applications, 5, pp. 259-271,
      2000.

   28 Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with
      Dynamic Tree Adjustment for Mobile IPv6", Journ. Information
      Science and Engineering 20, 1109-1124, 2004.

   29 Thaler, D. "Supporting Mobile SSM Sources for IPv6", Proceedings
      of ietf meeting Dec. 2001, individual.
      URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf

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

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

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

   33 Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 -
      Problems, Solutions and Improvements", Computational Methods in
      Science and Technology 11(2), 147-152. Selected Papers from TERENA
      Networking Conference, Poznan, May 2005.

   34 Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source
      Mobility in Source Specific Multicast", in K. Kawahara and I.
      Chong, eds, "Proceedings of ICOIN2006", Vol. 3961 of LNCS, pp. 82-
      91, Springer-Verlag, Berlin, Heidelberg, 2006.






Schmidt, Waehlisch     Expires - September 2007              [Page 15]


                             MMCASTv6-PS                   March 2007


Informative References

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

   36 Jannetau, C., Tian, Y., Csaba, S. et al "Comparison of Three
      Approaches Towards Mobile Multicast", IST Mobile Summit 2003,
      Aveiro, Portugal, 16-18 June 2003, online http://www.comnets.rwth-
      aachen.de/~o_drive/publications/ist-summit-2003-IPMobileMulticast-
      paperv2.0.pdf.

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

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

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

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

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

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

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

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

   45 Garyfalos, A., Almeroth, K. and Sanzgiri, K. "Deployment
      Complexity Versus Performance Efficiency in Mobile Multicast",
      Intern. Workshop on Broadband Wireless Multimedia: Algorithms,
      Architectures and Applications (BroadWiM), San Jose, California,
      USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM-
      04.pdf.gz


Schmidt, Waehlisch     Expires - September 2007              [Page 16]


                             MMCASTv6-PS                   March 2007



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

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

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

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

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


Acknowledgments

   The authors would like to thank Mark Palkow (DaViKo GmbH) and Hans L.
   Cycon (FHTW Berlin) for valuable discussions and a joyful
   collaboration. They also thank Stig Venaas (UNINETT) for many
   advices.


Author's Addresses

   Thomas C. Schmidt
   HAW Hamburg, Dept. Informatik
   Berliner Tor 7
   D-20099 Hamburg, Germany
   Phone: +49-40-42875-8157
   Email: Schmidt@informatik.haw-hamburg.de


   Matthias Waehlisch
   link-lab
   Hönowerstr. 35
   D-10318 Berlin, Germany
   Email: mw@link-lab.net





Schmidt, Waehlisch     Expires - September 2007              [Page 17]

                             MMCASTv6-PS                   March 2007



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
   http://www.ietf.org/ipr.

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

Copyright Notice

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

Disclaimer of Validity

   "This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF
   TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
   EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE
   USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."

Acknowledgement

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