GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5757

Internet Research Task Force (IRTF) T. Schmidt Request for Comments: 5757 HAW Hamburg Category: Informational M. Waehlisch ISSN: 2070-1721 link-lab

                                                          G. Fairhurst
                                                University of Aberdeen
                                                         February 2010
         Multicast Mobility in Mobile IP Version 6 (MIPv6):
                 Problem Statement and Brief Survey

Abstract

 This document discusses current mobility extensions to IP-layer
 multicast.  It describes problems arising from mobile group
 communication in general, the case of multicast listener mobility,
 and problems for mobile senders using Any Source Multicast and
 Source-Specific Multicast.  Characteristic aspects of multicast
 routing and deployment issues for fixed IPv6 networks are summarized.
 Specific properties and interplays with the underlying network access
 are surveyed with respect to the relevant technologies in the
 wireless domain.  It outlines the principal approaches to multicast
 mobility, together with a comprehensive exploration of the mobile
 multicast problem and solution space.  This document concludes with a
 conceptual road map for initial steps in standardization for use by
 future mobile multicast protocol designers.  This document is a
 product of the IP Mobility Optimizations (MobOpts) Research Group.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Research Task Force
 (IRTF).  The IRTF publishes the results of Internet-related research
 and development activities.  These results might not be suitable for
 deployment.  This RFC represents the consensus of the MobOpts
 Research Group of the Internet Research Task Force (IRTF).  Documents
 approved for publication by the IRSG are not a candidate for any
 level of Internet Standard; see Section 2 of RFC 5741.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc5757.

Schmidt, et al. Informational [Page 1] RFC 5757 MMCASTv6-PS February 2010

Copyright Notice

 Copyright (c) 2010 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.

Schmidt, et al. Informational [Page 2] RFC 5757 MMCASTv6-PS February 2010

Table of Contents

 1. Introduction and Motivation .....................................4
    1.1. Document Scope .............................................5
 2. Problem Description .............................................6
    2.1. General Issues .............................................6
    2.2. Multicast Listener Mobility ................................9
         2.2.1. Node and Application Perspective ....................9
         2.2.2. Network Perspective ................................10
    2.3. Multicast Source Mobility .................................11
         2.3.1. Any Source Multicast Mobility ......................11
         2.3.2. Source-Specific Multicast Mobility .................12
    2.4. Deployment Issues .........................................13
 3. Characteristics of Multicast Routing Trees under Mobility ......14
 4. Link Layer Aspects .............................................15
    4.1. General Background ........................................15
    4.2. Multicast for Specific Technologies .......................16
         4.2.1. 802.11 WLAN ........................................16
         4.2.2. 802.16 WIMAX .......................................16
         4.2.3. 3GPP/3GPP2 .........................................18
         4.2.4. DVB-H / DVB-IPDC ...................................19
         4.2.5. TV Broadcast and Satellite Networks ................19
    4.3. Vertical Multicast Handovers ..............................20
 5. Solutions ......................................................20
    5.1. General Approaches ........................................20
    5.2. Solutions for Multicast Listener Mobility .................21
         5.2.1. Agent Assistance ...................................21
         5.2.2. Multicast Encapsulation ............................22
         5.2.3. Hybrid Architectures ...............................23
         5.2.4. MLD Extensions .....................................23
    5.3. Solutions for Multicast Source Mobility ...................24
         5.3.1. Any Source Multicast Mobility Approaches ...........24
         5.3.2. Source-Specific Multicast Mobility Approaches ......25
 6. Security Considerations ........................................26
 7. Summary and Future Steps .......................................27
 Appendix A. Implicit Source Notification Options...................29
 Informative References.............................................29
 Acknowledgments....................................................37

Schmidt, et al. Informational [Page 3] RFC 5757 MMCASTv6-PS February 2010

1. Introduction and Motivation

 Group communication forms an integral building block of a wide
 variety of applications, ranging from content broadcasting and
 streaming, voice and video conferencing, collaborative environments
 and massive multiplayer gaming, up to the self-organization of
 distributed systems, services, or autonomous networks.  Network-layer
 multicast support will be needed whenever globally distributed,
 scalable, serverless, or instantaneous communication is required.
 The early idea of Internet multicasting [1] soon led to a wide
 adoption of Deering's host group model [2].  Broadband media delivery
 is emerging as a typical mass scenario that demands scalability and
 bandwidth efficiency from multicast routing.  Although multicast
 mobility has been a concern for about ten years [3] and has led to
 numerous proposals, there is as yet no generally accepted solution.
 Multicast network support will be of particular importance to mobile
 environments, where users commonly share frequency bands of limited
 capacity.  Reception of "infotainment" streams may soon require wide
 deployment of mobile multicast services.
 Mobility in IPv6 [4] is standardized in the Mobile IPv6 RFCs [5][6],
 and it addresses the scenario of network-layer changes while moving
 between wireless domains.  MIPv6 [5] only roughly defines multicast
 mobility for Mobile Nodes (MNs) using a remote subscription approach
 or through bidirectional tunneling via the Home Agent (HA).  Remote
 subscription suffers from slow handovers relying on multicast routing
 to adapt to handovers.  Bidirectional tunneling introduces
 inefficient overhead and delay due to triangular forwarding, i.e.,
 instead of traveling on shortest paths, packets are routed through
 the Home Agent.  Therefore, these approaches have not been optimized
 for a large scale deployment.  A mobile multicast service for a
 future Internet should provide "close-to-optimal" routing at
 predictable and limited cost, offering robustness combined with a
 service quality compliant to real-time media distribution.
 Intricate multicast routing procedures are not easily extensible to
 satisfy the requirements for mobility.  A client subscribed to a
 group while performing mobility handovers requires the multicast
 traffic to follow to its new location; a mobile source needs the
 entire delivery tree to comply with or to adapt to its changing
 position.  Significant effort has already been invested in protocol
 designs for mobile multicast receivers; only limited work has been
 dedicated to multicast source mobility, which poses the more delicate
 problem [65].

Schmidt, et al. Informational [Page 4] RFC 5757 MMCASTv6-PS February 2010

 In multimedia conference scenarios, games, or collaborative
 environments, each member commonly operates as a receiver and as a
 sender for multicast group communication.  In addition, real-time
 communication such as conversational voice or video places severe
 temporal requirements on mobility protocols: Typical seamless
 handover scenarios are expected to limit disruptions or delay to less
 than 100 - 150 ms [7].  Jitter disturbances should not exceed 50 ms.
 Note that 100 ms is about the duration of a spoken syllable in real-
 time audio.  This problem statement is intended to also be applicable
 to a range of other scenarios with a range of delivery requirements
 appropriate to the general Internet.
 This document represents the consensus of the MobOpts Research Group.
 It has been reviewed by the Research Group members active in the
 specific area of work.  In addition, this document has been
 comprehensively reviewed by multiple active contributors to the IETF
 MEXT, MBONED, and PIM Working Groups.

1.1. Document Scope

 This document defines the problem scope for multicast mobility
 management, which may be elaborated in future work.  It is subdivided
 to present the various challenges according to their originating
 aspects, and identifies existing proposals and major bibliographic
 references.
 When considering multicast node mobility, the network layer is
 complemented by some wireless access technology.  Two basic scenarios
 are of interest: single-hop mobility (shown in Figure 1.a) and multi-
 hop mobility (shown in Figure 1.b).  Single-hop mobility is the focus
 of this document, which coincides with the perspective of MIPv6 [5].
 The key issues of mobile multicast membership control and the
 interplay of mobile and multicast routing will be illustrated using
 this simple scenario.
 Multi-hop network mobility is a subsidiary scenario.  All major
 aspects are inherited from the single-hop problem, while additional
 complexity is incurred from traversing a mobile cloud.  This may be
 solved by either encapsulation or flooding ([8] provides a general
 overview).  Specific issues arising from (nested) tunneling or
 flooding, especially the preservation of address transparency,
 require treatment analogous to MIPv6.

Schmidt, et al. Informational [Page 5] RFC 5757 MMCASTv6-PS February 2010

                                     +------+           +------+
                                     |  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 - A Mobile Node (MN) Directly Attaching
 to Fixed Access Routers (ARs) or Attached via Local Access Routers
 (LARs)

2. Problem Description

2.1. General Issues

 Multicast mobility is a generic term, which subsumes a collection of
 distinct functions.  First, the multicast communication is divided
 into Any Source Multicast (ASM) [2] and Source-Specific Multicast
 (SSM) [9][10].  Second, the roles of senders and receivers are
 distinct and asymmetric.  Both may individually be mobile.  Their
 interaction is facilitated by a multicast routing protocol such as
 the Distance Vector Multicast Routing Protocol (DVMRP) [11], the

Schmidt, et al. Informational [Page 6] RFC 5757 MMCASTv6-PS February 2010

 Protocol Independent Multicast - Sparse Mode / Source-Specific
 Multicast (PIM-SM/SSM) [12][13], the Bidirectional PIM [14], or the
 inter-domain multicast prefix advertisements via Multiprotocol
 Extensions for BGP-4 (MBGP) [15].  IPv6 clients interact using the
 multicast listener discovery protocol (MLD and MLDv2) [16][17].
 Any solution for multicast mobility needs to take all of these
 functional blocks into account.  It should enable seamless continuity
 of multicast sessions when moving from one IPv6 subnet to another.
 It is desired to preserve the multicast nature of packet distribution
 and approximate optimal routing.  It should support per-flow handover
 for multicast traffic because the properties and designations of
 flows can be distinct.  Such distinctions may result from differing
 Quality-of-Service (QoS) / real-time requirements, but may also be
 caused by network conditions that may differ for different groups.
 The host group model extends the capability of the network-layer
 unicast service.  In common with the architecture of fixed networks,
 multicast mobility management should transparently utilize or
 smoothly extend the unicast functions of MIPv6 [5], its security
 extensions [6][18], its expediting schemes FMIPv6 [19] and
 Hierarchical Mobile IPv6 Environment (HMIPv6) [20], its context
 transfer protocols [21], its multihoming capabilities [22][23],
 emerging protocols like PMIPv6 [62], or future developments.  From
 the perspective of an integrated mobility architecture, it is
 desirable to avoid multicast-specific as well as unicast-restricted
 solutions, whenever general approaches can be derived that can
 jointly support unicast and multicast.
 Multicast routing dynamically adapts to the network topology at the
 locations of the sender(s) and receiver(s) participating in a
 multicast session, which then may change under mobility.  However,
 depending on the topology and the protocol in use, current multicast
 routing protocols may require a time close to seconds to converge
 following a change in receiver or sender location.  This is far too
 slow to support seamless handovers for interactive or real-time media
 sessions.  The actual temporal behavior strongly depends on the
 multicast routing protocol in use, the configuration of routers, and
 on the geometry of the current distribution tree.  A mobility scheme
 that readjusts 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 a

Schmidt, et al. Informational [Page 7] RFC 5757 MMCASTv6-PS February 2010

 connectionless transport service.  Where applications are sensitive
 to packet loss or jitter, countermeasures need to be performed (loss
 recovery, content recoding, concealment, etc.) by the multicast
 transport or application.  Mobile multicast handovers should not
 introduce significant additional packet drops.  Due to statelessness,
 the bi-casting of multicast flows does not cause degradations at the
 transport layer, and applications should implement mechanisms to
 detect and correctly respond to duplicate datagrams.  Nevertheless,
 individual application programs may not be robust with respect to
 repeated reception of duplicate streams.
 IP multicast applications can be designed to adapt the multicast
 stream to prevailing network conditions (adapting the sending rate to
 the level of congestion, adaptive tuning of clients in response to
 measured delay, dynamic suppression of feedback messages, etc.).  An
 adaptive application may also use more than one multicast group
 (e.g., layered multicast in which a client selects a set of multicast
 groups based on perceived available network capacity).  A mobility
 handover may temporarily disrupt the operation of these higher-layer
 functions.  The handover can invalidate assumptions about the
 forwarding path (e.g., acceptable delivery rate, round-trip delay),
 which could impact an application and level of network traffic.  Such
 effects need to be considered in the design of multicast applications
 and in the design of network-layer mobility.  Specifically, mobility
 mechanisms need to be robust to transient packet loss that may result
 from invalid path expectations following a handover of an MN to a
 different network.
 Group addresses, in general, are location transparent, even though
 they may be scoped and methods can embed unicast prefixes or
 Rendezvous Point addresses [24].  The addresses of sources
 contributing to a multicast session are interpreted by the routing
 infrastructure and by receiver applications, which frequently are
 aware of source addresses.  Multicast therefore inherits the mobility
 address duality problem of MIPv6 for source addresses: addresses
 being a logical node identifier, i.e., the home address (HoA) on the
 one hand, and a topological locator, the care-of address (CoA), on
 the other.  At the network layer, the elements that comprise the
 delivery tree, i.e., multicast senders, forwarders, and receivers,
 need to carefully account for address duality issues, e.g., by using
 binding caches, extended multicast states, or signaling.
 Multicast sources, in general, operate decoupled from their receivers
 in the following sense: a multicast source sends packets to a group
 of receivers that are unknown at the network layer and thus operates
 without a feedback channel.  It neither has means to inquire about
 the properties of its delivery trees, nor the ability to learn about
 the network-layer state of its receivers.  In the event of an inter-

Schmidt, et al. Informational [Page 8] RFC 5757 MMCASTv6-PS February 2010

 tree handover, a mobile multicast source therefore is vulnerable to
 losing connectivity to receivers without noticing.  (Appendix A
 describes implicit source notification approaches).  Applying a MIPv6
 mobility binding update or return routability procedure will
 similarly break the semantic of a receiver group remaining
 unidentified by the source and thus cannot be applied in unicast
 analogy.
 Despite the complexity of the requirements, multicast mobility
 management should seek lightweight solutions with easy deployment.
 Realistic, sample deployment scenarios and architectures should be
 provided in future solution documents.

2.2. Multicast Listener Mobility

2.2.1. Node and 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 any one of the
 following conditions:
    o In the simplest scenario, packets of some, or all, of the
      subscribed groups of the mobile node are already received by one
      or several other group members in the new network, and thus
      multicast streams natively flow after the MN arrives at the new
      network.
    o The requested multicast service may be supported and enabled in
      the visited network, but the multicast groups under subscription
      may not be forwarded to it, e.g., groups may be scoped or
      administratively prohibited.  This means that current
      distribution trees for the desired groups may only be re-joined
      at a (possibly large) routing distance.
    o The new network may not be multicast-enabled or the specific
      multicast service may be unavailable, e.g., unsupported or
      prohibited.  This means that current distribution trees for the
      desired groups need to be re-joined at a large routing distance
      by (re-)establishing a tunnel to a multicast-enabled network
      node.
 The problem of achieving seamless multicast listener handovers is
 thus threefold:

Schmidt, et al. Informational [Page 9] RFC 5757 MMCASTv6-PS February 2010

    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.  Dependent on Layer 2 (L2) and
      Layer 3 (L3) handover performance, the time available for
      multicast mobility operations is typically bound by the total
      handover time left after IPv6 connectivity is regained.  In
      real-time scenarios, this may be significantly less than 100 ms.
    o Minimize packet loss and reordering that result from multicast
      handover management.
 Moreover, in many wireless regimes, it is also desirable to minimize
 multicast-related signaling to preserve the limited resources of
 battery-powered mobile devices and the constrained transmission
 capacities of the networks.  This may lead to a desire to restrict
 MLD queries towards the MN.  Multihomed MNs may ensure smooth
 handoffs by using a "make-before-break" approach, which requires a
 per-interface subscription, facilitated by an MLD JOIN operating on a
 pre-selected IPv6 interface.
 Encapsulation on the path between the upstream router and the
 receiver may result in MTU size conflicts, since path-MTU discovery
 is often not supported for multicast and can reduce scalability in
 networks with many different MTU sizes or introduce potential denial-
 of-service vulnerabilities (since the originating addresses of ICMPv6
 messages cannot be verified for multicast).  In the absence of
 fragmentation at tunnel entry points, this may prevent the group from
 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 L2/vertical handover.
    o Ensure routing convergence, even when the MN moves rapidly and
      performs handovers at a high frequency.

Schmidt, et al. Informational [Page 10] RFC 5757 MMCASTv6-PS February 2010

    o Avoid avalanche problems and stream multiplication (n-casting),
      which potentially result from replicated tunnel initiation or
      redundant forwarding at network nodes.
 There are additional implications for the infrastructure: In changing
 its point of attachment, an exclusive mobile receiver may initiate
 forwarding of a group in the new network and termination of a group
 distribution service in the previous network.  Mobility management
 may impact multicast routing by, e.g., erroneous subscriptions
 following predictive handover operations, or slow traffic termination
 at leaf nodes resulting from MLD query timeouts, or by departure of
 the MN from a previous network without leaving the subscribed groups.
 Finally, packet duplication and reordering may follow a change of
 topology.

2.3. Multicast Source Mobility

2.3.1. Any Source Multicast Mobility

 A node submitting data to an ASM group either forms the root of a
 source-specific shortest path tree (SPT), distributing data towards a
 rendezvous point (RP) or receivers, or it forwards data directly down
 a shared tree, e.g., via encapsulated PIM Register messages, or using
 bidirectional PIM routing.  Native forwarding along source-specific
 delivery trees will be bound to the source's topological network
 address, due to reverse path forwarding (RPF) checks.  A mobile
 multicast source moving to a new subnetwork is only able to either
 inject data into a previously established delivery tree, which may be
 a rendezvous-point-based shared tree, or to (re-)initiate the
 construction of a multicast distribution tree for its new network
 location.  In the latter case, the mobile sender will have to proceed
 without knowing whether the new tree has regained ability to forward
 traffic to the group, due to the decoupling of sender and receivers.
 A mobile multicast source must therefore provide address transparency
 at two layers: To comply with RPF checks, it has to use an address
 within the source field of the IPv6 basic header, which is in
 topological agreement with the employed multicast distribution tree.
 For application transparency, the logical node identifier, commonly
 the HoA, must be presented as the packet source address to the
 transport layer at the receiver side.
 The address transparency and temporal handover constraints pose major
 problems for route-optimizing mobility solutions.  Additional issues
 arise from possible packet loss and from multicast scoping.  A mobile
 source away from home must respect scoping restrictions that arise
 from its home and its visited location [5].

Schmidt, et al. Informational [Page 11] RFC 5757 MMCASTv6-PS February 2010

 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 bidirectional shared domain-spanning trees,
 when using bidirectional PIM, eliminating the need for tunneling to
 the corresponding RP (in contrast to IPv4, IPv6 ASM multicast groups
 are associated with a specific RP/RPs).
 Issues arise in inter-domain multicast, whenever notification of
 source addresses is required between distributed instances of shared
 trees.  A new CoA acquired after a mobility handover will necessarily
 be subject to inter-domain record exchange.  In the presence of an
 embedded rendezvous point address [24], e.g., the primary rendezvous
 point for inter-domain PIM-SM will be globally appointed, and a newly
 attached mobile source can contact the RP without prior signaling
 (like a new source) and transmit data in the PIM register tunnel.
 Multicast route optimization (e.g., PIM "shortcuts") will require
 multicast routing protocol operations equivalent to serving a new
 source.

2.3.2. Source-Specific Multicast Mobility

 Source-Specific Multicast has been designed for multicast senders
 with static source addresses.  The source addresses in a client
 subscription to an SSM group is directly used to route
 identification.  Any SSM subscriber is thus forced to know the
 topological address of the contributor to the group it wishes to
 join.  The SSM source identification becomes invalid when the
 topological source address changes under mobility.  Hence, client
 implementations of SSM source filtering must be MIPv6 aware in the
 sense that a logical source identifier (HoA) is correctly mapped to
 its current topological correspondent (CoA).
 As a consequence, source mobility for SSM requires a conceptual
 treatment beyond the problem scope of mobile ASM.  A listener
 subscribes to an (S,G) channel membership and routers establish an
 (S,G)-state shortest path tree rooted at source S; therefore, any
 change of source addresses under mobility requires state updates at
 all routers on the upstream path and at all receivers in the group.
 On source handover, a new SPT needs to be established that will share
 paths with the previous SPT, e.g., at the receiver side.  As the
 principle of multicast decoupling of a sender from its receivers
 holds for SSM, the client updates needed for switching trees become a
 severe burden.

Schmidt, et al. Informational [Page 12] RFC 5757 MMCASTv6-PS February 2010

 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 [5].
 The above methods could add significant complexity to a solution for
 robust SSM mobility, which needs to converge to optimal routes and,
 for efficiency, is desired to avoid data encapsulation.  Like ASM,
 handover management is a time-critical operation.  The routing
 distance between subsequent points of attachment, the "step size" of
 the mobile from previous to next designated router, may serve as an
 appropriate measure of complexity [25][26].
 Finally, Source-Specific Multicast has been designed as a lightweight
 approach to group communication.  In adding mobility management, it
 is desirable to preserve the leanness of SSM by minimizing additional
 signaling overhead.

2.4. Deployment Issues

 IP multicast deployment, in general, has been slow over the past 15
 years, even though all major router vendors and operating systems
 offer implementations that support multicast [27].  While many
 (walled) domains or enterprise networks operate point-to-multipoint
 services, IP multicast roll-out is currently limited in public inter-
 domain scenarios [28].  A dispute arose on the appropriate layer,
 where group communication service should reside, and the focus of the
 research community turned towards application-layer multicast.  This
 debate on "efficiency versus deployment complexity" now overlaps the
 mobile multicast domain [29].  Garyfalos and Almeroth [30] derived
 from fairly generic principles that when mobility is introduced, the
 performance gap between IP- and application-layer multicast widens in
 different metrics up to a factor of four.
 Facing deployment complexity, it is desirable that any solution for
 mobile multicast does not change the routing protocols.  Mobility
 management in such a deployment-friendly scheme should preferably be
 handled at edge nodes, preserving a mobility-agnostic routing
 infrastructure.  Future research needs to search for such simple,
 infrastructure-transparent solutions, even though there are
 reasonable doubts as to whether this can be achieved in all cases.

Schmidt, et al. Informational [Page 13] RFC 5757 MMCASTv6-PS February 2010

 Nevertheless, multicast services in mobile environments may soon
 become indispensable, when multimedia distribution services such as
 Digital Video Broadcasting for Handhelds (DVB-H) [31][32] or IPTV
 develop a strong business case for portable IP-based devices.  As IP
 mobility becomes an important service and as efficient link
 utilization is of a larger impact in costly radio environments, the
 evolution of multicast protocols will naturally follow mobility
 constraints.

3. Characteristics of Multicast Routing Trees under Mobility

 Multicast distribution trees have been studied from a focus of
 network efficiency.  Grounded on empirical observations, Chuang and
 Sirbu [33] proposed a scaling power-law for the total number of links
 in a multicast shortest path tree with m receivers (proportional to
 m^k).  The authors consistently identified the scale factor to attain
 the independent constant k = 0.8.  The validity of such universal,
 heavy-tailed distribution suggests that multicast shortest path trees
 are of self-similar nature with many nodes of small, but few of
 higher degrees.  Trees consequently would be shaped tall rather than
 wide.
 Subsequent empirical and analytical work [34][35] debated the
 applicability of the Chuang and Sirbu scaling law.  Van Mieghem et
 al. [34] proved that the proposed power law cannot hold for an
 increasing Internet or very large multicast groups, but is indeed
 applicable for moderate receiver numbers and the current Internet
 size of N = 10^5 core nodes.  Investigating self-similarity, Janic
 and Van Mieghem [36] semi-empirically substantiated that multicast
 shortest path trees in the Internet can be modeled with reasonable
 accuracy by uniform recursive trees (URTs) [37], provided m remains
 small compared to N.
 The mobility perspective on shortest path trees focuses on their
 alteration, i.e., the degree of topological changes induced by
 movement.  For receivers, and more interestingly for sources, this
 may serve as a characteristic measure of the routing complexity.
 Mobile listeners moving to neighboring networks will only alter tree
 branches extending over a few hops.  Source-specific multicast trees
 subsequently generated from source handover steps are not
 independent, but highly correlated.  They most likely branch to
 identical receivers at one or several intersection points.  By the
 self-similar nature, the persistent sub-trees (of previous and next
 distribution tree), rooted at any such intersection point, exhibit
 again the scaling law behavior, are tall-shaped with nodes of mainly
 low degree and thus likely to coincide.  Tree alterations under
 mobility have been studied in [26], both analytically and by

Schmidt, et al. Informational [Page 14] RFC 5757 MMCASTv6-PS February 2010

 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 edge
 networks, where large numbers of end systems reside.  Consequently,
 it is not surprising that most LAN network access technologies
 natively support point-to-multipoint or multicast services.  Wireless
 access technologies inherently support broadcast/multicast at L2 and
 operate on a shared medium with limited frequency and bandwidth.
 Several aspects need consideration: First, dissimilar network access
 radio technologies cause distinct group traffic transmissions.  There
 are:
    o connection-less link services of a broadcast type, which mostly
      are bound to limited reliability;
    o connection-oriented link services of a point-to-multipoint type,
      which require more complex control and frequently exhibit
      reduced efficiency;
    o connection-oriented link services of a broadcast type, which are
      restricted to unidirectional data transmission.
 In addition, multicast may be distributed via multiple point-to-point
 unicast links without the use of a dedicated multipoint radio
 channel.  A fundamental difference between unicast and group
 transmission arises from power management.  Some radio technologies
 adjust transmit power to be as small as possible based on link-layer
 feedback from the receiver, which is not done in multipoint mode.
 They consequently incur a "multicast tax", making multicast less
 efficient than unicast unless the number of receivers is larger than
 some threshold.
 Second, point-to-multipoint service activation at the network access
 layer requires a mapping mechanism from network-layer requests.  This
 function is commonly achieved by L3 awareness, i.e., IGMP/MLD
 snooping [70] or proxy [38], which occasionally is complemented by
 Multicast VLAN Registration (MVR).  MVR allows sharing of a single
 multicast IEEE 802.1Q Virtual LAN in the network, while subscribers
 remain in separate VLANs.  This L2 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, et al. Informational [Page 15] RFC 5757 MMCASTv6-PS February 2010

 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 (i.e., more than one IP multicast
 group address is sent using the same L2 address).

4.2. Multicast for Specific Technologies

4.2.1. 802.11 WLAN

 IEEE 802.11 Wireless Local Area Network (WLAN) is a broadcast network
 of Ethernet type.  This inherits multicast address mapping concepts
 from 802.3.  In infrastructure mode, an access point operates as a
 repeater, only bridging data between the Base (BSS) and the Extended
 Service Set (ESS).  A mobile node submits multicast data to an access
 point in point-to-point acknowledged unicast mode (when the ToDS bit
 is set).  An access point receiving multicast data from an 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.
      The loss of frames (and hence packets) arises 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 Delivery TIM (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 Worldwide Interoperability for Microwave Access (WIMAX)
 combines a family of connection-oriented radio transmission services
 that can operate in single-hop point-to-multipoint (PMP) or in mesh

Schmidt, et al. Informational [Page 16] RFC 5757 MMCASTv6-PS February 2010

 mode.  The latter does not support multipoint transmission and
 currently has no deployment.  PMP operates between Base and
 Subscriber Stations in distinguished, unidirectional channels.  The
 channel assignment is controlled by the Base Station, which assigns
 channel IDs (CIDs) within service flows to the Subscriber Stations.
 Service flows may provide an optional Automatic Repeat Request (ARQ)
 to improve reliability and may operate in point-to-point or point-to-
 multipoint (restricted to downlink and without ARQ) mode.
 A WIMAX Base Station operates as a full-duplex L2 switch, with
 switching based on CIDs.  Two IPv6 link models for mobile access
 scenarios exist: A shared IPv6 prefix for IP over Ethernet Circuit
 Switched (CS) [39] provides Media Access Control (MAC) separation
 within a shared prefix.  A second, point-to-point link model [40] is
 recommended in the IPv6 Convergence Sublayer [41], which treats each
 connection to a mobile node as a single link.  The point-to-point
 link model conflicts with a consistent group distribution at the IP
 layer when using a shared medium (cf. Section 4.1 for MVR as a
 workaround).
 To invoke a multipoint data channel, the base station assigns a
 common CID to all Subscriber Stations in the group.  An IPv6
 multicast address mapping to these 16-bit IDs is proposed by copying
 either the 4 lowest bits, while sustaining the scope field, or by
 utilizing the 8 lowest bits derived from Multicast on Ethernet CS
 [42].  For selecting group members, a Base Station may implement
 IGMP/MLD snooping or proxy as foreseen in 802.16e-2005 [43].
 A Subscriber Station multicasts IP packets to a Base Station as a
 point-to-point unicast stream.  When the IPv6 CS is used, these are
 forwarded to the upstream access router.  The access router (or the
 Base Station for IP over Ethernet CS) may send downstream multicast
 packets by feeding them to the multicast service channel.  On
 reception, a Subscriber Station cannot distinguish multicast from
 unicast streams at the link layer.
 Multicast services have the following characteristics:
    o Multicast CIDs are unidirectional and available only in the
      downlink direction.  Thus, a native broadcast-type forwarding
      model is not available.
    o The mapping of multicast addresses to CIDs needs
      standardization, since different entities (Access Router, Base
      Station) may have to perform the mapping.

Schmidt, et al. Informational [Page 17] RFC 5757 MMCASTv6-PS February 2010

    o CID collisions for different multicast groups may occur due to
      the short ID space.  This can result in several point-to-
      multipoint groups sharing the same CID, reducing the ability of
      a receiver to filter unwanted L2 traffic.
    o The point-to-point link model for mobile access contradicts a
      consistent mapping of IP-layer multicast onto 802.16 point-to-
      multipoint services.
    o Multipoint channels cannot operate ARQ service and thus
      experience a reduced reliability.

4.2.3. 3GPP/3GPP2

 The 3rd Generation Partnership Project (3GPP) System architecture
 spans a circuit switched (CS) and a packet-switched (PS) domain, the
 latter General Packet Radio Services (GPRS) incorporates the IP
 Multimedia Subsystem (IMS) [44].  The 3GPP PS is connection-oriented
 and based on the concept of Packet Data Protocol (PDP) contexts.
 PDPs define point-to-point links between the Mobile Terminal and the
 Gateway GPRS Support Node (GGSN).  Internet service types are PPP,
 IPv4, and IPv6, where the recommendation for IPv6 address assignment
 associates a prefix to each (primary) PDP context [45].
 In Universal Mobile Telecommunications System (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 Generic Tunneling Protocol (GTP) (with multipoint TID) over
 local IP multicast.
 The 3GPP MBMS has the following characteristics:
    o There is no immediate Layer 2 source-to-destination transition,
      resulting in transit of all multicast traffic at the GGSN.
    o As GGSNs commonly are regional, distant entities, triangular
      routing and encapsulation may cause a significant degradation of
      efficiency.
 In 3GPP2, the MBMS has been extended to the Broadcast and Multicast
 Service (BCMCS) [46], which on the routing layer operates very
 similar to MBMS.  In both 3GPP and 3GPP2, multicast can be sent using
 either point-to-point (PTP) or point-to-multipoint (PTM) tunnels, and

Schmidt, et al. Informational [Page 18] RFC 5757 MMCASTv6-PS February 2010

 there is support for switching between PTP and PTM.  PTM uses a
 unidirectional common channel, operating in unacknowledged mode
 without adjustment of power levels and no reporting on lost packets.

4.2.4. DVB-H / DVB-IPDC

 Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional
 physical layer broadcasting specification for the efficient delivery
 of broadband and IP-encapsulated data streams, and is published as an
 ETSI standard [47] (see http://www.dvb-h.org).  This uses
 multiprotocol encapsulation (MPE) to transport IP packets over an
 MPEG-2 Transport Stream (TS) with link forward error correction
 (FEC).  Each stream is identified by a 13-bit TS ID (PID), which
 together with a multiplex service ID, is associated with IPv4 or IPv6
 addresses [48] and used for selective traffic filtering at receivers.
 Upstream channels may complement DVB-H using other transmission
 technologies.  The IP Datacast Service, DVB-IPDC [31], specifies a
 set of applications that can use the DVB-H transmission network.
 Multicast distribution services are defined by a mapping of groups
 onto appropriate PIDs, which is managed at the IP Encapsulator [49].
 To increase flexibility and avoid collisions, this address resolution
 is facilitated by dynamic tables, provided within the self-contained
 MPEG-2 TS.  Mobility is supported in the sense that changes of cell
 ID, network ID, or Transport Stream ID are foreseen [50].  A
 multicast receiver thus needs to relocate the multicast services to
 which it is subscribed during the synchronization phase, and update
 its service filters.  Its handover decision may depend on service
 availability.  An active service subscription (multicast join)
 requires initiation at the IP Encapsulator / DVB-H Gateway, which
 cannot be signaled in a pure DVB-H network.

4.2.5. TV Broadcast and Satellite Networks

 IP multicast may be enabled in TV broadcast networks, including those
 specified by DVB, the Advanced Television Systems Committee (ATSC),
 and related standards [49].  These standards are also used for one-
 and two-way satellite IP services.  Networks based on the MPEG-2
 Transport Stream may support either the multiprotocol encapsulation
 (MPE) or the unidirectional lightweight encapsulation (ULE) [51].
 The second generation DVB standards allow the Transport Stream to be
 replaced with a Generic Stream, using the Generic Stream
 Encapsulation (GSE) [52].  These encapsulation formats all support
 multicast operation.
 In MPEG-2 transmission networks, multicast distribution services are
 defined by a mapping of groups onto appropriate PIDs, which is
 managed at the IP Encapsulator [49].  The addressing issues resemble

Schmidt, et al. Informational [Page 19] RFC 5757 MMCASTv6-PS February 2010

 those for DVB-H (Section 4.2.4) [48].  The issues for using GSE
 resemble those for ULE (except the PID is not available as a
 mechanism for filtering traffic).  Networks that provide
 bidirectional connectivity may allow active service subscription
 (multicast join) to initiate forwarding from the upstream IP
 Encapsulator / gateway.  Some kind of filtering can be achieved using
 the Input Stream Identifier (ISI) field.

4.3. Vertical Multicast Handovers

 A mobile multicast node may change its point of Layer 2 attachment
 within homogeneous access technologies (horizontal handover) or
 between heterogeneous links (vertical handover).  In either case, a
 Layer 3 network change may or may not take place, but multicast-aware
 links always need information about group traffic demands.
 Consequently, a dedicated context transfer of multicast subscriptions
 is required at the network access.  Such Media Independent Handover
 (MIH) is addressed in IEEE 802.21 [53], but is relevant also beyond
 IEEE protocols.  Mobility services transport for MIH are required as
 an abstraction for Layer 2 multicast service transfer in an Internet
 context [54] and are specified in [55].
 MIH needs to assist in more than service discovery: There is a need
 for complex, media-dependent multicast adaptation, a possible absence
 of MLD signaling in L2-only transfers, and requirements originating
 from predictive handovers.  A multicast mobility services transport
 needs to be sufficiently comprehensive and abstract to initiate a
 seamless multicast handoff at network access.
 Functions required for MIH include:
    o Service discovery.
    o Service context transformation.
    o Service context transfer.
    o Service invocation.

5. Solutions

5.1. General Approaches

 Three approaches to mobile multicast are common [56]:
    o Bidirectional Tunneling, in which the mobile node tunnels all
      multicast data via its home agent.  This fundamental multicast
      solution hides all movement and results in static multicast
      trees.  It may be employed transparently by mobile multicast

Schmidt, et al. Informational [Page 20] RFC 5757 MMCASTv6-PS February 2010

      listeners and sources, at the cost of triangular routing and
      possibly significant performance degradation from widely spanned
      data tunnels.
    o Remote Subscription forces the mobile node to re-initiate
      multicast distribution following handover, e.g., by submitting
      an MLD listener report to the subnet where a receiver attaches.
      This approach of tree discontinuation relies on multicast
      dynamics to adapt to network changes.  It not only results in
      significant service disruption but leads to mobility-driven
      changes of source addresses, and thus cannot support session
      persistence under multicast source mobility.
    o Agent-based solutions attempt to balance between the previous
      two mechanisms.  Static agents typically act as local tunneling
      proxies, allowing for some inter-agent handover when the mobile
      node moves.  A decelerated inter-tree handover, i.e., "tree
      walking", will be the outcome of agent-based multicast mobility,
      where some extra effort is needed to sustain session persistence
      through address transparency of mobile sources.
 MIPv6 [5] introduces bidirectional tunneling as well as remote
 subscription as minimal standard solutions.  Various publications
 suggest utilizing remote subscription for listener mobility only,
 while advising bidirectional tunneling as the solution for source
 mobility.  Such an approach avoids the "tunnel convergence" or
 "avalanche" problem [56], which refers to the responsibility of the
 home agent to multiply and encapsulate packets for many receivers of
 the same group, even if they are located within the same subnetwork.
 However, this suffers from the drawback that multicast communication
 roles are not explicitly known at the network layer and may change
 unexpectedly.
 None of the above approaches address SSM source mobility, except the
 use of bidirectional tunneling.

5.2. Solutions for Multicast Listener Mobility

5.2.1. Agent Assistance

 There are proposals for agent-assisted handover for host-based
 mobility, which complement the unicast real-time mobility
 infrastructure of Fast MIPv6 (FMIPv6) [19], the M-FMIPv6 [57][58],
 and of Hierarchical MIPv6 (HMIPv6) [20], the M-HMIPv6 [59], and to
 context transfer [60], which have been thoroughly analyzed in
 [25][61].

Schmidt, et al. Informational [Page 21] RFC 5757 MMCASTv6-PS February 2010

 All these solutions presume the context state was stored within a
 network node that is reachable before and after a move.  But there
 could be cases were the MN is no longer in contact with the previous
 network, when at the new location.  In this case, the network itself
 cannot assist in the context transfer.  Such scenarios may occur when
 moving from one (walled) operator to another and will require a
 backwards compatible way to recover from loss of connectivity and
 context based on the node alone.
 Network-based mobility management, Proxy MIPv6 (PMIPv6) [62], is
 multicast transparent in the sense that the MN experiences a point-
 to-point home link fixed at its (static) Local Mobility Anchor (LMA).
 This virtual home link is composed of a unicast tunnel between the
 LMA and the current Mobile Access Gateway (MAG), and a point-to-point
 link connecting the current MAG to the MN.  A PMIPv6 domain thereby
 inherits MTU-size problems from spanning tunnels at the receiver
 site.  Furthermore, two avalanche problem points can be identified:
 the LMA may be required to tunnel data to a large number of MAGs,
 while an MAG may be required to forward the same multicast stream to
 many MNs via individual point-to-point links [63].  Future
 optimizations and extensions to shared links preferably adapt native
 multicast distribution towards the edge network, possibly using a
 local routing option, including context transfer between access
 gateways to assist IP-mobility-agnostic MNs.
 An approach based on dynamically negotiated inter-agent handovers is
 presented in [64].  Aside from IETF work, numerous publications
 present proposals for seamless multicast listener mobility, e.g.,
 [65] provides a comprehensive overview of the work prior to 2004.

5.2.2. Multicast Encapsulation

 Encapsulation of multicast data packets is an established method to
 shield mobility and to enable access to remotely located data
 services, e.g., streams from the home network.  Applying generic
 packet tunneling in IPv6 [66] using a unicast point-to-point method
 will also allow multicast-agnostic domains to be transited, but does
 inherit the tunnel convergence problem and may result in traffic
 multiplication.
 Multicast-enabled environments may take advantage of point-to-
 multipoint encapsulation, i.e., generic packet tunneling using an
 appropriate multicast destination address in the outer header.  Such
 multicast-in-multicast encapsulated packets similarly enable
 reception of remotely located streams, but do not suffer from the
 scaling overhead from using unicast tunnels.

Schmidt, et al. Informational [Page 22] RFC 5757 MMCASTv6-PS February 2010

 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 methods that avoid the
 complexity at the Internet core network, e.g., application-layer and
 overlay proposals for (mobile) multicast.  The possibility of
 integrating multicast distribution on the overlay into the network
 layer is also being considered by the IRTF Scalable Adaptive
 Multicast (SAM) Research Group.
 An early hybrid architecture using reactively operating proxy-
 gateways located at the Internet edges was introduced by Garyfalos
 and Almeroth [30].  The authors presented an Intelligent Gateway
 Multicast as a bridge between mobility-aware native multicast
 management in access networks and mobility group distribution
 services in the Internet core, which may be operated on the network
 or application layer.  The Hybrid Shared Tree approach [67]
 introduced a mobility-agnostic multicast backbone on the overlay.
 Current work in the SAM RG is developing general architectural
 approaches for hybrid multicast solutions [68] and a common multicast
 API for a transparent access of hybrid multicast [69] that will
 require a detailed design in future work.

5.2.4. MLD Extensions

 The default timer values and Robustness Variable specified in MLD
 [17] were not designed for the mobility context.  This results in a
 slow reaction of the multicast-routing infrastructure (including
 L3-aware access devices [70]) following a client leave.  This may be
 a disadvantage for wireless links, where performance may be improved
 by carefully tuning the Query Interval and other variables.  Some
 vendors have optimized performance by implementing a listener node
 table at the access router that can eliminate the need for query
 timeouts when receiving leave messages (explicit receiver tracking).
 An 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 the case of an erroneous prediction (i.e., an anticipated
 move to a network that has not taken place).  Backward context
 transfer may otherwise ensure a leave is signaled.  A further
 optimization was introduced by Jelger and Noel [71] for the special
 case when the HA is a multicast router.  A Done message received

Schmidt, et al. Informational [Page 23] RFC 5757 MMCASTv6-PS February 2010

 through a tunnel from the mobile end node (through a point-to-point
 link directly connecting the MN, in general), should not initiate
 standard MLD membership queries (with a subsequent timeout).  Such
 explicit treatment of point-to-point links will reduce traffic and
 accelerate the control protocol.  Explicit tracking will cause
 identical protocol behavior.
 While away from home, an MN may wish to rely on a proxy or "standby"
 multicast membership service, optionally provided by an HA or proxy
 router.  Such functions rely on the ability to restart fast packet
 forwarding; it may be desirable for the proxy router to remain part
 of the multicast delivery tree, even when transmission of group data
 is paused.  To enable such proxy control, the authors in [71] propose
 an extension to MLD, introducing a Listener Hold message that is
 exchanged between the MN and the HA.  This idea was developed in [59]
 to propose multicast router attendance control, allowing for a
 general deployment of group membership proxies.  Some currently
 deployed IPTV solutions use such a mechanism in combination with a
 recent (video) frame buffer, to enable fast channel switching between
 several IPTV multicast flows (zapping).

5.3. Solutions for Multicast Source Mobility

5.3.1. Any Source Multicast Mobility Approaches

 Solutions for multicast source mobility can be divided into three
 categories:
    o Statically Rooted Distribution Trees.  These methods follow a
      shared tree approach.  Romdhani et al. [72] proposed employing
      the Rendezvous Points of PIM-SM as mobility anchors.  Mobile
      senders tunnel their data to these "Mobility-aware Rendezvous
      Points" (MRPs).  When restricted to a single domain, this scheme
      is equivalent to bidirectional tunneling.  Focusing on inter-
      domain mobile multicast, the authors designed a tunnel- or SSM-
      based backbone distribution of packets between MRPs.
    o Reconstruction of Distribution Trees.  Several authors have
      proposed the construction of a completely new distribution tree
      after the movement of a mobile source and therefore have to
      compensate for the additional routing (tree-building) delay.  M-
      HMIPv6 [59] tunnels data into a previously established tree
      rooted at mobility anchor points to compensate for the routing
      delay until a protocol-dependent timer expires.  The Range-Based
      Mobile Multicast (RBMoM) protocol [73] introduces an additional
      Multicast Agent (MA) that advertises its service range.  A
      mobile source registers with the closest MA and tunnels data
      through it.  When moving out of the previous service range, it

Schmidt, et al. Informational [Page 24] RFC 5757 MMCASTv6-PS February 2010

      will perform MA discovery, a re-registration and continue data
      tunneling with a newly established Multicast Agent in its new
      current vicinity.
    o Tree Modification Schemes.  In the case of DVMRP routing, Chang
      and Yen [74] propose an algorithm to extend the root of a given
      delivery tree for incorporating a new source location in ASM.
      The authors rely on a complex additional signaling protocol to
      fix DVMRP forwarding states and heal failures in the reverse
      path forwarding (RPF) checks.

5.3.2. Source-Specific Multicast Mobility Approaches

 The shared tree approach of [72] has been extended to support SSM
 mobility by introducing the HoA address record to the Mobility-aware
 Rendezvous Points.  The MRPs operate using extended multicast routing
 tables that simultaneously hold the HoA and CoA and thus can
 logically identify the appropriate distribution tree.  Mobility thus
 may reintroduce the concept of rendezvous points to SSM routing.
 Approaches for reconstructing SPTs in SSM rely on a client
 notification to establish new router state.  They also need to
 preserve address transparency for the client.  Thaler [75] proposed
 introducing a binding cache and providing source address transparency
 analogous to MIPv6 unicast communication.  Initial session
 announcements and changes of source addresses are distributed
 periodically to clients via an additional multicast control tree
 rooted at the home agent.  Source tree handovers are then activated
 on listener requests.
 Jelger and Noel [76] suggest handover improvements employing anchor
 points within the source network, supporting continuous data
 reception during client-initiated handovers.  Client updates are
 triggered out of band, e.g., by Source Demand Routing (SDR) / Session
 Announcement Protocol (SAP) [77].  Receiver-oriented tree
 construction in SSM thus remains unsynchronized with source
 handovers.
 To address the synchronization problem at the routing layer, several
 proposals have focused on direct modification of the distribution
 trees.  A recursive scheme may use loose unicast source routes with
 branch points, based on a multicast Hop-by-Hop protocol.  Vida et al.
 [78] optimized SPT for a moving source on the path between the source
 and first branching point.  O'Neill [79] suggested a scheme to
 overcome RPF check failures that originate from multicast source
 address changes with a rendezvous point scenario by introducing
 extended routing information, which accompanies data in a Hop-by-Hop
 option "RPF redirect" header.  The Tree Morphing approach of Schmidt

Schmidt, et al. Informational [Page 25] RFC 5757 MMCASTv6-PS February 2010

 and Waehlisch [80] used source routing to extend the root of a
 previously established SPT, thereby injecting router state updates in
 a Hop-by-Hop option header.  Using extended RPF checks, the elongated
 tree autonomously initiates shortcuts and smoothly reduces to a new
 SPT rooted at the relocated source.  An enhanced version of this
 protocol abandoned the initial source routing and could be proved to
 comply with rapid source movement [81].  Lee et al. [82] introduced a
 state-update mechanism for reusing 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 source leaving its home network will signal a multicast
 forwarding state update on the path to its home agent and,
 subsequently, distribution states according to the mobile source's
 new CoA along the previous distribution tree.  Multicast data is then
 intended to flow natively using triangular routes via the elongation
 and an updated tree centered on the home agent.  Based on Host
 Identity Protocol identifiers, Kovacshazi and Vida [83] introduce
 multicast routing states that remain independent of IP addresses.
 Drawing upon a similar scaling law argument, parts of these states
 may then be reused after source address changes.

6. Security Considerations

 This document discusses multicast extensions to mobility.  It does
 not define new methods or procedures.  Security issues arise from
 source address binding updates, specifically in the case of source-
 specific multicast.  Threats of hijacking unicast sessions will
 result from any solution jointly operating binding updates for
 unicast and multicast sessions.
 Multicast protocols exhibit a risk of network-based traffic
 amplification.  For example, an attacker may abuse mobility signaling
 to inject unwanted traffic into a previously established multicast
 distribution infrastructure.  These threats are partially mitigated
 by reverse path forwarding checks by multicast routers.  However, a
 multicast or mobility agent that explicitly replicates multicast
 streams, e.g., Home Agent that n-casts data, may be vulnerable to
 denial-of-service attacks.  In addition to source authentication, a
 rate control of the replicator may be required to protect the agent
 and the downstream network.
 Mobility protocols need to consider the implications and requirements
 for Authentication, Authorization, and Accounting (AAA).  An MN may
 have been authorized to receive a specific multicast group when using
 one mobile network, but this may not be valid when attaching to a
 different network.  In general, the AAA association for an MN may
 change between attachments, or may be individually chosen prior to
 network (re-)association.  The most appropriate network path may be

Schmidt, et al. Informational [Page 26] RFC 5757 MMCASTv6-PS February 2010

 one that satisfies user preferences, e.g., to use/avoid a specific
 network, minimize monetary cost, etc., rather than one that only
 minimizes the routing cost.  Consequently, AAA bindings may need to
 be considered when performing context transfer.
 Admission control issues may arise when new CoA source addresses are
 introduced to SSM channels [84].  Due to lack of feedback, the
 admission [85] and binding updates [86] of mobile multicast sources
 require autonomously verifiable authentication.  This can be achieved
 by, for instance, Cryptographically Generated Addresses (CGAs).
 Modification to IETF protocols (e.g., routing, membership, session
 announcement, and control) as well as the introduction of new
 entities, e.g., multicast mobility agents, can introduce security
 vulnerabilities and require consideration of issues such as
 authentication of network entities, methods to mitigate denial of
 service (in terms of unwanted network traffic, unnecessary
 consumption of router/host resources and router/host state/buffers).
 Future solutions must therefore analyze and address the security
 implications of supporting mobile multicast.

7. Summary and Future Steps

 This document is intended to provide a basis for the future design of
 mobile IPv6 multicast methods and protocols by:
    o providing a structured overview of the problem space that
      multicast and mobility jointly generate at the IPv6 layer;
    o referencing the implications and constraints arising from lower
      and upper layers and from deployment;
    o briefly surveying conceptual ideas of currently available
      solutions;
    o including a comprehensive bibliographic reference base.
 It is recommended that future steps towards extending mobility
 services to multicast proceed to first solve the following problems:
    1. Ensure seamless multicast reception during handovers, meeting
       the requirements of mobile IPv6 nodes and networks.  Thereby
       addressing the problems of home subscription without n-tunnels,
       as well as native multicast reception in those visited
       networks, which offer a group communication service.

Schmidt, et al. Informational [Page 27] RFC 5757 MMCASTv6-PS February 2010

    2. Integrate multicast listener support into unicast mobility
       management schemes and architectural entities to define a
       consistent mobility service architecture, providing equal
       support for unicast and multicast communication.
    3. Provide basic multicast source mobility by designing address
       duality management at end nodes.

Schmidt, et al. Informational [Page 28] RFC 5757 MMCASTv6-PS February 2010

Appendix A. Implicit Source Notification Options

 An IP multicast source transmits data to a group of receivers without
 requiring any explicit feedback from the group.  Sources therefore
 are unaware at the network layer of whether any receivers have
 subscribed to the group, and unconditionally send multicast packets
 that propagate in the network to the first-hop router (often known in
 PIM as the designated router).  There have been attempts to
 implicitly obtain information about the listening group members,
 e.g., extending an IGMP/MLD querier to inform the source of the
 existence of subscribed receivers.  Multicast Source Notification of
 Interest Protocol (MSNIP) [87] was such a suggested method that
 allowed a multicast source to query the upstream designated router.
 However, this work did not progress within the IETF mboned working
 group and was terminated by the 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 Real-time Transport Protocol (RTP) [88].  The
 accompanying control protocol, RTP Control Protocol (RTCP), 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.  RFC 2326,
 the Real Time Streaming Protocol (RTSP), provides session layer
 control that may be used to control a multicast source.  However,
 RTCP and RTSP information is intended for end-to-end control and is
 not necessarily visible at the network layer.  Application designers
 may chose to implement any appropriate control plane for their
 multicast applications (e.g., reliable multicast transport
 protocols), and therefore a network-layer mobility mechanism must not
 assume the presence of a specific transport or session protocol.

Informative References

  [1]  Aguilar, L. "Datagram Routing for Internet Multicasting", In
       ACM SIGCOMM '84 Communications Architectures and Protocols, pp.
       58-63, ACM Press, June, 1984.
  [2]  Deering, S., "Host extensions for IP multicasting", STD 5, RFC
       1112, August 1989.
  [3]  G. Xylomenos and G.C. Plyzos, "IP Multicast for Mobile Hosts",
       IEEE Communications Magazine, 35(1), pp. 54-58, January 1997.

Schmidt, et al. Informational [Page 29] RFC 5757 MMCASTv6-PS February 2010

  [4]  Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
       Specification", RFC 2460, December 1998.
  [5]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
       IPv6", RFC 3775, June 2004.
  [6]  Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with
       IKEv2 and the Revised IPsec Architecture", RFC 4877, April
       2007.
  [7]  ITU-T Recommendation, "G.114 - One-way transmission time",
       Telecommunication Union Standardization Sector, 05/2003.
  [8]  Akyildiz, I and Wang, X., "A Survey on Wireless Mesh Networks",
       IEEE Communications Magazine, 43(9), pp. 23-30, September 2005.
  [9]  Bhattacharyya, S., Ed., "An Overview of Source-Specific
       Multicast (SSM)", RFC 3569, July 2003.
 [10]  Holbrook, H. and B. Cain, "Source-Specific Multicast for IP",
       RFC 4607, August 2006.
 [11]  Waitzman, D., Partridge, C., and S. Deering, "Distance Vector
       Multicast Routing Protocol", RFC 1075, November 1988.
 [12]  Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S.,
       Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei,
       "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol
       Specification", RFC 2362, June 1998.
 [13]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
       "Protocol Independent Multicast - Sparse Mode (PIM-SM):
       Protocol Specification (Revised)", RFC 4601, August 2006.
 [14]  Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
       "Bidirectional Protocol Independent Multicast (BIDIR-PIM)", RFC
       5015, October 2007.
 [15]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
       "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
 [16]  Deering, S., Fenner, W., and B. Haberman, "Multicast Listener
       Discovery (MLD) for IPv6", RFC 2710, October 1999.
 [17]  Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery
       Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.

Schmidt, et al. Informational [Page 30] RFC 5757 MMCASTv6-PS February 2010

 [18]  Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
       Optimization for Mobile IPv6", RFC 4866, May 2007.
 [19]  Koodli, R., Ed., "Mobile IPv6 Fast Handovers", RFC 5568, July
       2009.
 [20]  Soliman, H., Castelluccia, C., ElMalki, K., and L. Bellier,
       "Hierarchical Mobile IPv6 (HMIPv6) Mobility Management", RFC
       5380, October 2008.
 [21]  Loughney, J., Ed., Nakhjiri, M., Perkins, C., and R. Koodli,
       "Context Transfer Protocol (CXTP)", RFC 4067, July 2005.
 [22]  Montavont, N., Wakikawa, R., Ernst, T., Ng, C., and K.
       Kuladinithi, "Analysis of Multihoming in Mobile IPv6", Work in
       Progress, May 2008.
 [23]  Narayanan, V., Thaler, D., Bagnulo, M.,  and H. Soliman, "IP
       Mobility and Multi-homing Interactions and Architectural
       Considerations", Work in Progress, July 2007.
 [24]  Savola, P. and B. Haberman, "Embedding the Rendezvous Point
       (RP) Address in an IPv6 Multicast Address", RFC 3956, November
       2004.
 [25]  Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive -
       Analysis of Handover Performance and Its Implications on IPv6
       and Multicast Mobility", Telecommunication Systems, 30(1-3),
       pp. 123- 142, November 2005.
 [26]  Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees -
       On the Evolution of Multicast States under Mobility and an
       Adaptive Routing Scheme for Mobile SSM Sources",
       Telecommunication Systems, 33(1-3), pp. 131-154, December 2006.
 [27]  Diot, C. et al. "Deployment Issues for the IP Multicast Service
       and Architecture", IEEE Network Magazine, spec. issue on
       Multicasting, 14(1), pp. 78-88, 2000.
 [28]  Eubanks, M. http://multicasttech.com/status/, 2008.
 [29]  Garyfalos, A, Almeroth, K. and Sanzgiri, K. "Deployment
       Complexity Versus Performance Efficiency in Mobile Multicast",
       Intern.  Workshop on Broadband Wireless Multimedia: Algorithms,
       Architectures and Applications (BroadWiM), San Jose,
       California, USA, October 2004. Online:
       http://imj.ucsb.edu/papers/BROADWIM-04.pdf.

Schmidt, et al. Informational [Page 31] RFC 5757 MMCASTv6-PS February 2010

 [30]  Garyfalos, A, Almeroth, K. "A Flexible Overlay Architecture for
       Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm.,
       23(11), pp. 2194-2205, November 2005.
 [31]  "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set
       of Specifications for Phase 1", ETSI TS 102 468;
 [32]  ETSI TS 102 611, "Digital Video Broadcasting (DVB); IP Datacast
       over DVB-H: Implementation Guidelines for Mobility)", European
       Standard (Telecommunications series), November 2004.
 [33]  Chuang, J. and Sirbu, M. "Pricing Multicast Communication: A
       Cost- Based Approach", Telecommunication Systems, 17(3),
       281-297, 2001.  Presented at the INET'98, Geneva, Switzerland,
       July 1998.
 [34]  Van Mieghem, P, Hooghiemstra, G, Hofstad, R. "On the Efficiency
       of Multicast", IEEE/ACM Trans. Netw., 9(6), pp. 719-732, Dec.
       2001.
 [35]  Chalmers, R.C. and Almeroth, K.C, "On the topology of multicast
       trees", IEEE/ACM Trans. Netw., 11(1), 153-165, 2003.
 [36]  Janic, M. and Van Mieghem, P. "On properties of multicast
       routing trees", Int. J. Commun. Syst., 19(1), pp. 95-114, Feb.
       2006.
 [37]  Van Mieghem, P. "Performance Analysis of Communication Networks
       and Systems", Cambridge University Press, 2006.
 [38]  Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet
       Group Management Protocol (IGMP) / Multicast Listener Discovery
       (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC
       4605, August 2006.
 [39]  Jeon, H., Jeong, S., and M. Riegel, "Transmission of IP over
       Ethernet over IEEE 802.16 Networks", RFC 5692, October 2009.
 [40]  Shin, M-K., Ed., Han, Y-H., Kim, S-E., and D. Premec, "IPv6
       Deployment Scenarios in 802.16 Networks", RFC 5181, May 2008.
 [41]  Patil, B., Xia, F., Sarikaya, B., Choi, JH., and S.
       Madanapalli, "Transmission of IPv6 via the IPv6 Convergence
       Sublayer over IEEE 802.16 Networks", RFC 5121, February 2008.
 [42]  Kim, S., Jin, J., Lee, S., and S. Lee, "Multicast Transport on
       IEEE 802.16 Networks", Work in Progress, July 2007.

Schmidt, et al. Informational [Page 32] RFC 5757 MMCASTv6-PS February 2010

 [43]  IEEE 802.16e-2005: IEEE Standard for Local and metropolitan
       area networks Part 16: "Air Interface for Fixed and Mobile
       Broadband Wireless Access Systems Amendment for Physical and
       Medium Access Control Layers for Combined Fixed and Mobile
       Operation in Licensed Bands", New York, February 2006.
 [44]  3rd Generation Partnership Project; Technical Specification
       Group Services and System Aspects; "IP Multimedia Subsystem
       (IMS)"; Stage 2, 3GPP TS 23.228, Rel. 5 ff, 2002 - 2007.
 [45]  Wasserman, M., Ed., "Recommendations for IPv6 in Third
       Generation Partnership Project (3GPP) Standards", RFC 3314,
       September 2002.
 [46]  3GPP2, www.3gpp2.org, "X.S0022-A, Broadcast and Multicast
       Service in cdma2000 Wireless IP Network, Rev. A.",
       http://www.3gpp2.org/Public_html/specs/tsgx.cfm, February 2007.
 [47]  ETSI EN 302 304, "Digital Video Broadcasting (DVB);
       Transmission System for Handheld Terminals (DVB-H)", European
       Standard (Telecommunications series), November 2004.
 [48]  Fairhurst, G. and M. Montpetit, "Address Resolution Mechanisms
       for IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
 [49]  Montpetit, M.-J., Fairhurst, G., Clausen, H., Collini-Nocker,
       B., and H. Linder, "A Framework for Transmission of IP
       Datagrams over MPEG-2 Networks", RFC 4259, November 2005.
 [50]  Yang, X, Vare, J, Owens, T. "A Survey of Handover Algorithms in
       DVB-H", IEEE Comm. Surveys, 8(4), pp. 16-24, 2006.
 [51]  Fairhurst, G. and B. Collini-Nocker, "Unidirectional
       Lightweight Encapsulation (ULE) for Transmission of IP
       Datagrams over an MPEG-2 Transport Stream (TS)", RFC 4326,
       December 2005.
 [52]  Fairhurst, G. and B. Collini-Nocker, "Extension Formats for
       Unidirectional Lightweight Encapsulation (ULE) and the Generic
       Stream Encapsulation (GSE)", RFC 5163, April 2008.
 [53]  "Draft IEEE Standard for Local and Metropolitan Area Networks:
       Media Independent Handover Services", IEEE LAN/MAN Draft IEEE
       P802.21/D07.00, July 2007.
 [54]  Melia, T., Ed., "Mobility Services Transport: Problem
       Statement", RFC 5164, March 2008.

Schmidt, et al. Informational [Page 33] RFC 5757 MMCASTv6-PS February 2010

 [55]  Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC. Zuniga,
       "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC
       5677, December 2009.
 [56]  Janneteau, C, Tian, Y, Csaba, S. et al. "Comparison of Three
       Approaches Towards Mobile Multicast", IST Mobile Summit 2003,
       Aveiro, Portugal, 16-18 June 2003.
 [57]  Suh, K., Kwon, D.-H., Suh, Y.-J. and Y. Park, "Fast Multicast
       Protocol for Mobile IPv6 in the fast handovers environments",
       Work in Progress, January 2004.
 [58]  Xia, F. and B. Sarikaya, "FMIPv6 extensions for Multicast
       Handover", Work in Progress, March 2007.
 [59]  Schmidt, T. and M. Waehlisch, "Seamless Multicast Handover in a
       Hierarchical Mobile IPv6 Environment (M-HMIPv6)", Work in
       Progress, November 2005.
 [60]  Miloucheva, I. and K. Jonas, "Multicast Context Transfer in
       mobile IPv6", Work in Progress, June 2005.
 [61]  Leoleis, G, Prezerakos, G, Venieris, I, "Seamless multicast
       mobility support using fast MIPv6 extensions", Computer Comm.,
       29(18), pp. 3745-3765, 2006.
 [62]  Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K.,
       and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
 [63]  Deng, H., Chen, G., Schmidt, T., Seite, P., and P. Yang,
       "Multicast Support Requirements for Proxy Mobile IPv6", Work in
       Progress, July 2009.
 [64]  Zhang, H., Chen, X., Guan, J., Shen, B., Liu, E., and S.
       Dawkins, "Mobile IPv6 Multicast with Dynamic Multicast Agent",
       Work in Progress, January 2007.
 [65]  Romdhani, I, Kellil, M, Lach, H.-Y. et. al. "IP Mobile
       Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1),
       pp. 18-41, 2004.
 [66]  Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6
       Specification", RFC 2473, December 1998.
 [67]  Waehlisch, M., Schmidt, T.C. "Between Underlay and Overlay: On
       Deployable, Efficient, Mobility-agnostic Group Communication
       Services", Internet Research, 17(5), pp. 519-534, Emerald
       Insight, Bingley, UK, November 2007.

Schmidt, et al. Informational [Page 34] RFC 5757 MMCASTv6-PS February 2010

 [68]  J. Buford, "Hybrid Overlay Multicast Framework", Work in
       Progress, February 2008.
 [69]  Waehlisch, M., Schmidt, T., and S. Venaas, "A Common API for
       Transparent Hybrid Multicast", Work in Progress, October 2009.
 [70]  Christensen, M., Kimball, K., and F. Solensky, "Considerations
       for Internet Group Management Protocol (IGMP) and Multicast
       Listener Discovery (MLD) Snooping Switches", RFC 4541, May
       2006.
 [71]  Jelger, C, Noel, T. "Multicast for Mobile Hosts in IP Networks:
       Progress and Challenges", IEEE Wirel. Comm., 9(5), pp 58-64,
       Oct. 2002.
 [72]  Romdhani, I, Bettahar, H. and Bouabdallah, A. "Transparent
       handover for mobile multicast sources", in P. Lorenz and P.
       Dini, eds, Proceedings of the IEEE ICN'06, IEEE Press, 2006.
 [73]  Lin, C.R. et al. "Scalable Multicast Protocol in IP-Based
       Mobile Networks", Wireless Networks, 8 (1), pp. 27-36, January,
       2002.
 [74]  Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with
       Dynamic Tree Adjustment for Mobile IPv6", Journ. Information
       Science and Engineering, 20(6), pp. 1109-1124, 2004.
 [75]  Thaler, D. "Supporting Mobile SSM Sources for IPv6",
       Proceedings of ietf meeting, Dec. 2001.
       URL: www.ietf.org/proceedings/01dec/slides/magma-2.pdf
 [76]  Jelger, C. and T. Noel, "Supporting Mobile SSM sources for IPv6
       (MSSMSv6)",Work in Progress, January 2002.
 [77]  Handley, M., Perkins, C., and E. Whelan, "Session Announcement
       Protocol", RFC 2974, October 2000.
 [78]  Vida, R, Costa, L, Fdida, S. "M-HBH - Efficient Mobility
       Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM
       Press 2002.
 [79]  A. O'Neill "Mobility Management and IP Multicast", Work in
       Progress, July 2002.
 [80]  Schmidt, T. C. and Waehlisch, M. "Extending SSM to MIPv6 -
       Problems, Solutions and Improvements", Computational Methods in
       Science and Technology, 11(2), pp. 147-152. Selected Papers
       from TERENA Networking Conference, Poznan, May 2005.

Schmidt, et al. Informational [Page 35] RFC 5757 MMCASTv6-PS February 2010

 [81]  Schmidt, T.C., Waehlisch, M., and Wodarz, M. "Fast Adaptive
       Routing Supporting Mobile Senders in Source Specific
       Multicast", Telecommunication Systems, 43(1), pp. 95-108, 2009,
       http://dx.doi.org/10.1007/s11235-009-9200-y.
 [82]  Lee, H., Han, S. and Hong, J. "Efficient Mechanism for Source
       Mobility in Source Specific Multicast", in K. Kawahara and I.
       Chong, eds, "Proceedings of ICOIN2006", LNCS vol. 3961, pp.
       82-91, Springer-Verlag, Berlin, Heidelberg, 2006.
 [83]  Kovacshazi, Z. and Vida, R. "Host Identity Specific Multicast",
       Third International Conference on Networking and Services ICNS,
       IEEE Press, pp. 1-1, June 2007.
 [84]  Kellil, M, Romdhani, I, Lach, H.-Y, Bouabdallah, A. and
       Bettahar, H. "Multicast Receiver and Sender Access Control and
       its Applicability to Mobile IP Environments: A Survey", IEEE
       Comm. Surveys & Tutorials, 7(2), pp. 46-70, 2005.
 [85]  Castellucia, C, Montenegro, G. "Securing Group Management in
       IPv6 with Cryptographically Based Addresses", Proc. 8th IEEE
       Int'l Symp. Comp. and Commun, Turkey, July 2003, pp. 588-93.
 [86]  Schmidt, T.C, Waehlisch, M., Christ, O., and Hege, G.
       "AuthoCast - a mobility-compliant protocol framework for
       multicast sender authentication", Security and Communication
       Networks, 1(6),  pp. 495-509, 2008.
 [87]  Fenner, B., Holbrook, H., and I. Kouvelas, "Multicast Source
       Notification of Interest Protocol (MSNIP)", Work in Progress,
       November 2001.
 [88]  Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson,
       "RTP: A Transport Protocol for Real-Time Applications", STD 64,
       RFC 3550, July 2003.

Schmidt, et al. Informational [Page 36] RFC 5757 MMCASTv6-PS February 2010

Acknowledgments

 Work on exploring the problem space for mobile multicast has been
 pioneered by Greg Daley and Gopi Kurup within their early document
 "Requirements for Mobile Multicast Clients".
 Since then, many people have actively discussed the different issues
 and contributed to the enhancement of this memo. The authors would
 like to thank (in alphabetical order) Kevin C. Almeroth, Lachlan
 Andrew, Jari Arkko, Cedric Baudoin, Hans L. Cycon, Hui Deng, Marshall
 Eubanks, Zhigang Huang, Christophe Jelger, Andrei Gutov, Rajeev
 Koodli, Mark Palkow, Craig Partridge, Imed Romdhani, Hesham Soliman,
 Dave Thaler, and last, but not least, very special thanks to Stig
 Venaas for his frequent and thorough advice.

Authors' Addresses

 Thomas C. Schmidt
 Dept. Informatik
 Hamburg University of Applied Sciences,
 Berliner Tor 7
 D-20099 Hamburg, Germany
 Phone: +49-40-42875-8157
 EMail: schmidt@informatik.haw-hamburg.de
 Matthias Waehlisch
 link-lab
 Hoenower Str. 35
 D-10318 Berlin, Germany
 EMail: mw@link-lab.net
 Godred Fairhurst
 School of Engineering,
 University of Aberdeen,
 Aberdeen, AB24 3UE, UK
 EMail: gorry@erg.abdn.ac.uk

Schmidt, et al. Informational [Page 37]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5757.txt · Last modified: 2010/02/23 00:04 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki