One document matched: draft-irtf-mobopts-mmcastv6-ps-03.txt
Differences from draft-irtf-mobopts-mmcastv6-ps-02.txt
MobOpts Research Group Thomas C. Schmidt
Internet Draft HAW Hamburg
Category: Informational Matthias Waehlisch
Expires: August 2008 link-lab
February 2008
Multicast Mobility in MIPv6: Problem Statement and Brief Survey
<draft-irtf-mobopts-mmcastv6-ps-03.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
This document discusses current mobility extensions to IP layer
multicast. 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 for fixed IPv6 networks are summarized. Specific
properties and interplays with the underlying network access are
surveyed w.r.t. the relevant technologies in the wireless domain. It
outlines the principal approaches to multicast mobility. In addition
to providing a comprehensive exploration of the mobile multicast
Schmidt, Waehlisch Expires - August 2008 [Page 1]
MMCASTv6-PS February 2008
problem and solution space, this document attempts to draft a
conceptual roadmap for initial steps in standardization for the use
of future mobile multicast protocol designers.
Table of Contents
1. Introduction and Motivation....................................3
1.1 Document Scope..............................................4
2. Problem Description............................................5
2.1 General Issues..............................................5
2.2 Multicast Listener Mobility.................................7
2.2.1 Node & Application Perspective........................7
2.2.2 Network Perspective...................................8
2.3 Multicast Source Mobility...................................9
2.3.1 Any Source Multicast Mobility.........................9
2.3.2 Source Specific Multicast Mobility...................10
2.4 Deployment Issues..........................................11
3. Characteristics of Multicast Routing Trees under Mobility.....11
4. Link Layer Aspects............................................12
4.1 General Background.........................................12
4.2 Multicast for Specific Technologies........................13
4.2.1 802.11 WLAN..........................................13
4.2.2 802.16 WIMAX.........................................14
4.2.3 3GPP.................................................15
4.2.4 DVB-H / DVB-IPDC.....................................15
4.3 Vertical Multicast Handovers...............................16
5. Solutions.....................................................17
5.1 General Approaches.........................................17
5.2 Solutions for Multicast Listener Mobility..................18
5.2.1 Agent Assistance.....................................18
5.2.2 Multicast Encapsulation..............................18
5.2.3 Hybrid Architectures.................................18
5.2.4 MLD Extensions.......................................19
5.3 Solutions for Multicast Source Mobility....................20
5.3.1 Any Source Multicast Mobility Approaches.............20
5.3.2 Source Specific Multicast Mobility Approaches........20
6. Security Considerations.......................................22
7. Summary and Future Steps......................................22
8. IANA Considerations...........................................23
Schmidt, Waehlisch Expires - August 2008 [Page 2]
MMCASTv6-PS February 2008
Appendix A. Implicit Source Notification Options.................23
9. References....................................................23
Acknowledgments..................................................30
Author's Addresses...............................................30
Intellectual Property Statement..................................30
Copyright Notice.................................................31
Disclaimer of Validity...........................................31
Acknowledgement..................................................31
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. As
broadband media delivery emerges as a typical mass scenario,
scalability and bandwidth efficiency of multicast routing
continuously gain importance.
The early idea of Internet multicasting [2] soon lead to a wide
adoption of Deering's host group model [3]. Multicast network support
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 [4] and
has led to numerous proposals, but no generally accepted solution.
Mobility in IPv6 [5] is standardized in the Mobile IPv6 RFCs [6,7].
MIPv6 [6] only roughly defines multicast mobility, using a remote
subscription approach or through bi-directional tunneling via the
Home Agent. 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, i.e., instead of traveling on shortest paths,
packets are routed through the Home Agent. Therefore none of the
approaches have been optimized for a large scale deployment. A mobile
Schmidt, Waehlisch Expires - August 2008 [Page 3]
MMCASTv6-PS February 2008
multicast service for a future Internet should provide '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 operating mobility handovers, requires
traffic to follow to its new location; any mobile source requests the
entire delivery tree to comply with or 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 [59].
In multimedia conference scenarios, games or collaborative
environments each member commonly operates as receiver and as sender
for multicast based group communication. In addition, real-time
communication such as conversational voice or video places severe
temporal requirement on mobility protocols: Seamless handover
scenarios are expected to limit disruptions or delay to less than 100
ms. Jitter disturbances should not exceed 50 ms. Note that 100 ms is
about the duration of a spoken syllable in real-time audio.
It is the aim of this document, to specify the problem scope for a
multicast mobility management, which may be elaborated in future
work. The document subdivides the various challenges according to
their originating aspects and presents existing proposals for
solution, as well as major bibliographic references.
1.1 Document Scope
When considering multicast node mobility, two basic scenarios are of
interest: Single-hop mobility (as shown in figure 1.a) and multi-hop
mobile routing (figure 1.b). This document adopts single-hop mobility
as the focal scenario, which coincides with the perspective of MIPv6
[6]. All key issues of mobile multicast membership control, as well
as the interplay of mobile and multicast routing will become apparent
in this simpler scenario.
Multi-hop network mobility is a subsidiary setting. 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 encapsulation or flooding (cf. [8] for a general overview).
Specific issues arising from (nested) tunneling or flooding,
especially the preservation of address transparency, require a
treatment in analogy to MIPv6.
+------+ +------+
Schmidt, Waehlisch Expires - August 2008 [Page 4]
MMCASTv6-PS February 2008
| MN | =====> | MN |
+------+ +------+
| .
| .
| .
+-------+ +-------+
| LAR 1 | | LAR 2 |
+-------+ +-------+
\ /
*** *** *** ***
* ** ** ** *
+------+ +------+ * *
| MN | =====> | MN | * Mobile Network *
+------+ +------+ * *
| . * ** ** ** *
| . *** *** *** ***
| . | .
+-------+ +-------+ +-------+ +-------+
| AR 1 | | AR 2 | | AR 1 | =====> | AR 2 |
+-------+ +-------+ +-------+ +-------+
| | | |
*** *** *** *** *** *** *** ***
* ** ** ** * * ** ** ** *
* * * *
* Fixed Internet * * Fixed Internet *
* * * *
* ** ** ** * * ** ** ** *
*** *** *** *** *** *** *** ***
a) Single-Hop Mobility b) Multi-Hop Mobility
Figure 1: Mobility Scenarios
2. Problem Description
2.1 General Issues
Multicast mobility is a generic term, which subsumes a collection of
quite distinct functions. At first, multicast communication divides
into Any Source Multicast (ASM) [3] and Source Specific Multicast
(SSM) [9,10]. At second, the roles of senders and receivers are
distinct and asymmetric. Both may individually be mobile. Their
interaction is facilitated by a multicast routing protocol such as
DVMRP [11], PIM-SM/SSM [12,13], Bi-directional PIM [14], formerly CBT
[15], BGMP [16], or inter-domain multicast prefix advertisements via
MBGP [17], and a client interaction with the multicast listener
discovery protocol (MLD and MLDv2) [18,19].
Schmidt, Waehlisch Expires - August 2008 [Page 5]
MMCASTv6-PS February 2008
Any multicast mobility solution must take all of these functional
blocks into account. It should enable seamless continuity of
multicast sessions when moving from one IPv6 subnet to another. It
should preserve the multicast nature of packet distribution and
approximate optimal routing. It should support per flow handover for
multicast traffic, as properties and designations of flows can be of
distinct nature. Such distinctions may result from differing
QoS/real-time requirements, but may also be caused by network layer
conditions, which need not be identical for all groups.
The host group model extends the capability of the network layer
unicast service. In common with the architecture of fixed networks,
multicast mobility management should transparently utilize or
smoothly extend the unicast functions of MIPv6 [6], its security
extensions [7,20], its expediting schemes FMIPv6 [21] and HMIPv6
[22], its context transfer protocols [23], its multihoming
capabilities [24,25], emerging protocols like PMIPv6 [57] 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 jointly
supporting unicast and multicast can be derived.
Multicast routing dynamically adapts to the topology of the sender(s)
and receiver(s) participating in a multicast session, which then may
change under mobility. However, depending on the topology and the
protocol in use, current multicast routing protocols may require a
time close to seconds, or even minutes to converge following a change
in receiver or sender location. This is far too slow to support
seamless handovers for interactive or real-time media sessions. The
actual temporal behavior strongly depends on the multicast routing
protocol in use and on the geometry of the current distribution tree.
A mobility scheme that re-adjusts routing, i.e., partially changes or
fully reconstructs a multicast tree, is forced to comply with the
time scale of 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.
IP layer multicast packet distribution is an unreliable service that
is bound to connectionless transport protocols. Where applications
are sensitive to packet loss, loss recovery, concealment, etc,
counter measures must be performed by the multicast transport or
application. Mobile multicast handovers though should not introduce
significant additional packet drops. Due to statelessness, the bi-
casting of multicast flows does not cause foreseeable degradations at
the transport layer.
Group addresses in general are location transparent, even though they
may be scoped and there are methods that embed unicast prefixes or
Rendezvous Point addresses [26]. Addresses of sources contributing to
Schmidt, Waehlisch Expires - August 2008 [Page 6]
MMCASTv6-PS February 2008
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) on the one hand, and a topological locator, the care-
of-address (CoA) on the other. At the network layer, the elements
that comprise the delivery tree, i.e., multicast senders, forwarders
and receivers, need to carefully account for address duality issues,
e.g., by using binding caches, extended multicast states or
signaling.
Multicast sources in general operate decoupled from their receivers
in the following sense: A multicast source sends packets to a group
of unknown receivers and thus operates without a feedback channel. It
neither has means to inquire 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. (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 of the complexity of the requirements, multicast mobility
management should seek lightweight solutions with easy deployment.
Such realistic, sample deployment scenarios and architectures should
be provided in future solution documents.
2.2 Multicast Listener Mobility
2.2.1 Node & Application Perspective
A mobile multicast listener entering a new IP subnet requires
multicast reception subsequent to handover in real-time. It faces the
problem of transferring 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 MN's moving interface(s) to the new upstream
router(s). In the latter case, it may encounter either one of the
following conditions: The new network may not be multicast-enabled or
the specific multicast service may be unavailable, e.g. unsupported
or prohibited. Alternatively, the requested multicast service may be
supported and enabled in the visited network, but the multicast
groups under subscription may not be forwarded to it. Then current
distribution trees for the desired groups may only be met at large
routing distance. The simplest scenario occurs when data of some, or
all, of the subscribed groups of the mobile node are already received
Schmidt, Waehlisch Expires - August 2008 [Page 7]
MMCASTv6-PS February 2008
by one or several group members in the destination network, and thus
multicast streams natively flow on MN’s arrival.
The problem of achieving seamless multicast listener handovers is
thus threefold:
o Ensure multicast reception even in visited networks without
appropriate multicast support.
o Minimize multicast forwarding delay to provide seamless
and fast handovers. Dependant on layer 2 and 3 handover
performance, the time available for multicast mobility operations
is typically bound to a fraction of 100 ms.
o Minimize packet loss and reordering that result from multicast
handover management.
Moreover, in many wireless regimes it is also desirable to minimize
multicast related signaling to preserve the limited resources of
battery powered mobile devices and the constrained transmission
capacities of the networks. This may lead to a need to restrict MLD
queries towards the MN. Multihomed MNs may smooth handoffs by a
.make-before-break. approach. This requires a per interface
subscription, facilitated by a selective MLD JOIN.
Encapsulation on the path between the upstream router and the
receiver may cause MTU size conflicts, as commonly path-MTU discovery
is unavailable for multicast. In the absence of fragmentation at
tunnel entry points, this may disable a group distribution service
entirely.
2.2.2 Network Perspective
Infrastructure providing corresponding multicast services is required
to keep traffic following the mobile without having network
functionality compromised. Mobility solutions thus have to face the
immediate problems:
o Realize native multicast forwarding whenever applicable to
preserve network resources, facilitate multipoint distribution
capabilities at the link layer and avoid data redundancy.
o Activate link layer multipoint services, even if the MN performs
only a layer 2 / vertical handover.
o Ensure routing convergence, even if the mobile node moves rapidly
and performs handovers at high frequency.
o Avoid avalanche problems and n-casting, which potentially result
from replicated tunnel initiation or redundant forwarding at
network nodes.
Additional implications for the infrastructure remain. In changing
its point of attachment, an exclusive mobile receiver may cause
initiation and termination of a group distribution service in the new
Schmidt, Waehlisch Expires - August 2008 [Page 8]
MMCASTv6-PS February 2008
respectively previous network. Mobility management may issue traffic
directives that lead to suboptimal routing, i.e., by erroneous
subscriptions following predictive handover operations, or by slow
effective leaves caused by MLD querying, or by a rapid departure of
the mobile without leaving groups in the previous network at all.
Finally, packet duplication and re-ordering may follow a change of
topology.
2.3 Multicast Source Mobility
2.3.1 Any Source Multicast Mobility
A node submitting data to an ASM group either 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, or using
bi-directional PIM routing. Native forwarding along source specific
delivery trees will be bound to the source’s topological network
address due to reverse path forwarding (RPF) checks. A mobile
multicast source moving to a new subnetwork is only able to either
inject data into a previously established delivery tree, which may be
a rendezvous point based shared tree, or to (re-)initiate the
construction of a multicast distribution tree compliant to its new
location. In the latter case, the mobile sender will have to precede
without controlling the new tree development due to decoupling of
sender and receivers.
A mobile multicast source consequently must meet address transparency
at two layers: 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 the packet source address to the transport
layer at the receiver side.
Conforming to address transparency and temporal handover constraints
pose major problems for any route optimizing mobility solution.
Additional issues arise from possible packet loss and from multicast
scoping. A mobile source away from home must respect scoping
restrictions that arise from its home and its visited location [6].
Within intra-domain multicast routing the use of shared trees may
reduce 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. Intra-domain mobility is transparently provided by bi-
directional shared domain-spanning trees, when using bi-directional
PIM, eliminating the need for tunneling to a rendezvous point.
Schmidt, Waehlisch Expires - August 2008 [Page 9]
MMCASTv6-PS February 2008
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 presence of embedded
rendezvous point addresses [26], 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
Source Specific Multicast has been designed for static addresses of
multicast senders. The source addresses in a client subscription to
an SSM group is directly used for 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 invalidates, when topological 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).
As a direct consequence, source mobility for SSM packet distribution
requires a dedicated conceptual treatment beyond the problem scope 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 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, 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 may subscribe to or exclude any specific multicast
source, and thereby wants to rely on the topological correctness of
network operations. The SSM design permits trust in equivalence to
the correctness of unicast routing tables. Any SSM mobility solution
should preserve this degree of confidence. Binding updates for SSM
sources thus should have to prove address correctness in the unicast
routing sense, which is equivalent to binding update security with a
correspondent node in MIPv6 [6].
All of the above severely add complexity to a robust SSM mobility
solution, which should converge to optimal routes and, for
efficiency, should avoid data encapsulation. Like ASM, handover
management is a time-critical operation. The routing distance between
subsequent points of attachment, the 'step size' of the mobile from
Schmidt, Waehlisch Expires - August 2008 [Page 10]
MMCASTv6-PS February 2008
previous to next designated router, may serve as an appropriate
measure of complexity [27,28].
Finally, Source Specific Multicast has been designed as a light-
weight approach to group communication. In adding mobility
management, it is desirable to preserve the 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 implementations that support multicast [29]. While many
(walled) domains or enterprise networks operate point-to-multipoint
services, IP multicast rollout is currently limited in public inter-
domain scenarios [30]. A dispute arose on the appropriate layer,
where group communication service should reside, and the focus of the
research community turned towards application layer multicast. This
debate on "efficiency versus deployment complexity" now overlaps the
mobile multicast domain [31]. Garyfalos and Almeroth [32] derived
from fairly generic principles that when mobility is introduced the
performance gap between IP and application layer multicast widens in
different metrics up to a factor of four.
Facing deployment complexity, it is desirable that any solution for
mobile multicast should leave routing protocols unchanged. Mobility
management in such deployment-friendly scheme should preferably be
handled at edge nodes, preserving a mobility agnostic routing
infrastructure. Future research needs to search for such simple,
infrastructure transparent solutions, even though there are
reasonable doubts, whether 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-H [33] or IPTV will develop as a strong business cases 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 from a focus of
network efficiency. Grounded on empirical observations Chuang and
Sirbu [34] 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-
Schmidt, Waehlisch Expires - August 2008 [Page 11]
MMCASTv6-PS February 2008
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 [35,36] debated the
applicability of the Chuang and Sirbu scaling law. Van Mieghem et al.
[35] proved that the proposed power law cannot hold for an increasing
Internet or very large multicast groups, but is indeed applicable for
moderate receiver numbers and the current Internet size N = 10^5 core
nodes. Investigating self-similarity Janic and Van Mieghem [37] semi-
empirically substantiated that multicast shortest path trees in the
Internet can be modeled with reasonable accuracy by uniform recursive
trees (URT) [38], provided m remains small compared to N.
The mobility perspective on shortest path trees focus on their
alteration, i.e., the degree of topological changes induced by
movement. For receivers, and more interestingly for sources this may
serve as an outer measure for routing complexity. Mobile listeners
moving to neighboring networks will only alter tree branches
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 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 [28], both analytically and by
simulations. It was found that even in large networks and for
moderate receiver numbers more than 80 % of the multicast router
states remain invariant under a source handover.
4. Link Layer Aspects
4.1 General Background
Scalable group data distribution has the highest potential in leaf
networks, where large numbers of end systems reside. Consequently, it
is not surprising that most LAN network access technologies natively
support point-to-multipoint or multicast services. Of focal interest
to the mobility domain are wireless access technologies, which always
operate on a shared medium of limited frequencies and bandwidth.
Several aspects need consideration: First, dissimilar network access
radio technologies cause distinct group traffic transmissions. There
are:
Schmidt, Waehlisch Expires - August 2008 [Page 12]
MMCASTv6-PS February 2008
o connection-less link services of broadcast type, which mostly are
bound to limited reliability;
o connection-oriented link services of point-to-multipoint type,
which require more complex control and frequently exhibit reduced
efficiency;
o connection oriented link services of broadcast type, which are
restricted to unidirectional data transmission.
Second, point-to-multipoint service activation at the network access
layer requires a mapping mechanism from network layer requests. This
function is commonly achieved by L3 awareness, i.e., IGMP/MLD
snooping [63], which occasionally is complemented by Multicast VLAN
Registration (MVR). MVR allows sharing of a single multicast IEEE
802.1Q Virtual LAN in the network, while subscribers remain in
separate VLANs. This layer 2 separation of multicast and unicast
traffic can be employed as a workaround for point-to-point link
models to establish a common multicast link.
Thirdly, an address mapping between the layers is needed for common
group identification. Address resolution schemes depend on framing
details for the technologies in use, but commonly cause a significant
address overlap at the lower layer.
4.2 Multicast for Specific Technologies
4.2.1 802.11 WLAN
IEEE 802.11 WLAN is a broadcast network of Ethernet type, which
inherits multicast address mapping concepts from 802.3. In
infrastructure mode an access point operates as repeater, only
bridging data between the Base (BSS) and the Extended Service Set
(ESS). A mobile node submits multicast data to an access point in
point-to-point acknowledged unicast mode (when the ToDS bit is set).
An access point receiving multicast data from a MN simply repeats
multicast frames to the BSS and propagates them to the ESS as
unacknowledged broadcast. Multicast frames received from the ESS are
analogously treated.
Multicast frame delivery has the following characteristics:
o As an unacknowledged service it attains limited reliability.
Frames (and hence packet) loss arises from interference, collision,
or time-varying channel properties.
o Data distribution may be delayed, as unicast power save
synchronization via Traffic Indication Messages (TIM) does not apply.
Schmidt, Waehlisch Expires - August 2008 [Page 13]
MMCASTv6-PS February 2008
Access points buffer multicast packets while waiting for a larger
DTIM interval, whenever stations use the power saving mode.
o Multipoint data may cause congestion, as 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
configurable rate limiting for multicast packets. Additionally,
IGMP/MLD snooping may be active at the bridging layer between the BSS
and the ESS or at switches interconnecting access points.
4.2.2 802.16 WIMAX
IEEE 802.16 WIMAX combines a family of connection-oriented radio
transmission services, operating in distinguished, unidirectional
channels. The channel assignment is controlled by Base Stations,
which assign channel IDs (CIDs) within service flows to the
subscriber stations. Service flows may provide an optional Automatic
Repeat Request (ARQ) to improve reliability and may operate in point-
to-point or point-to-multipoint (without ARQ) mode.
A WIMAX Base Station operates as L2 switch in full duplex mode, where
switching is based on CIDs. Two possible IPv6 link models for mobile
access deployment scenarios exist: Shared IPv6 prefix and point-to-
point link model [39]. The latter treats each connection to a mobile
node as a single link, which on the IP layer conflicts with a
consistent group distribution via a shared medium (cf. section 4.1
for 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 [40]. For
selecting group members, a Base Station may implement IGMP/MLD
snooping or IGMP/MLD proxying as foreseen in 802.16e-2005 [41].
A Subscriber Station will send multicast data to a Base Station as a
point-to-point unicast stream, which is forwarded to the upstream
access router. The access router may return multicast data to the
downstream Base Station by feeding into a multicast service channel.
On reception a Subscriber Station cannot distinguish multicast from
unicast streams.
Multicast services have the following characteristics:
Schmidt, Waehlisch Expires - August 2008 [Page 14]
MMCASTv6-PS February 2008
o The mapping of multicast addresses to CIDs needs standardization,
since different entities (Access Router, Base Station) may have to
perform the mapping.
o CID collisions for different multicast groups are very likely due
to the short ID space. As a consequence, multicast data transmission
may occur in joint point-to-multipoint groups of reduced
selectiveness.
o The point-to-point link model for mobile access contradicts a
consistent mapping of IP layer multicast onto 802.16 point-to-
multipoint services.
o Multipoint channels cannot operate ARQ service and thus experience
a reduced reliability.
4.2.3 3GPP
The 3GPP System architecture spans a circuit switched (CS) and a
packet switched (PS) domain, the latter General Packet Radio Services
(GPRS) incorporates the IP Multimedia Subsystem (IMS) [42]. 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 [43]. Current packet filtering practice causes inter-working
problems between Mobile IPv6 nodes connected via GPRS [44].
As of UMTS Rel. 6 the IMS has been extended to include Multimedia
Broadcast and Multicast Services (MBMS). A point-to-multipoint GPRS
connection service is operated on radio links, while the gateway
service to Internet multicast is handled at the IGMP/MLD-aware GGSN.
Local multicast packet distribution is used within the GPRS IP
backbone resulting in the common double encapsulation at GGSN: global
IP multicast datagrams over GTP (with multipoint TID) over local IP
multicast.
The 3GPP MBMS has the following characteristics:
o There is no immediate layer 2 source-to-destination transition,
resulting in transition of all multicast traffic at the GGSN.
o As GGSN commonly are regional, distant entities, triangular
routing and encapsulation may cause a significant degradation of
efficiency.
4.2.4 DVB-H / DVB-IPDC
Schmidt, Waehlisch Expires - August 2008 [Page 15]
MMCASTv6-PS February 2008
Digital Video Broadcasting for Handhelds (DVB-H) is a unidirectional
physical layer broadcasting specification for the efficient delivery
of broadband, IP-encapsulated data streams. It was formally adopted
as ETSI standard [45] (see http://www.dvb-h.org). DVB uses a
mechanism called multi-protocol encapsulation (MPE), which enables a
transport of network layer protocols on top of a link layer built
from MPEG-2 transport streams and includes a forward error correction
(FEC). Thereby DVB cannot only support TV broadcasting, but offers an
IP Datacast Service. DVB-IPDC [33] consists of a number of
individual, application layer specifications, some of which are still
under development. Transport Streams (TS) form the basic logical
channels, identified by a 13 bit TS ID (PID). This together with a
multiplex service ID is associated with IPv4 or IPv6 addresses [46]
and used for selective traffic filtering at receivers. Upstream
channels may complement DVB-H by means of alternative technologies.
Multicast distribution services are defined by a mapping of groups
onto appropriate PIDs, which is managed at the IP Encapsulator [47].
To increase flexibility and avoid collisions, this address resolution
is facilitated by dynamic tables, provided within the self-consistent
MPEG-2 TS. Mobility is supported in the sense that changes of cell
ID, network ID or Transport Stream ID are foreseen [48]. A multicast
receiver thus needs to re-locate multicast services it is subscribed
to, which is to be done in the synchronization phase, and update its
service filters. Its handover decision may depend on service
availability. An active service subscription (multicast join) will
need initiation at the IP Encapsulator / DVB-H Gateway, which cannot
be achieved in a pure DVB-H network setup.
4.3 Vertical Multicast Handovers
A mobile multicast node may operate homogeneous (horizontal) or
heterogeneous (vertical) layer 2 handovers with or without layer 3
network changes. Consequently, multicast configuration context
transfer at network access' needs dedicated treatment. Media
Independent Handover (MIH) is addressed in IEEE 802.21 [49], but is
relevant also beyond IEEE protocols. Mobility services transport for
MIH naturally reside on the network layer and are currently in the
process of specification [50].
MIH needs to assist in more than service discovery. Keeping in mind
complex, media dependent multicast adaptations, 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:
Schmidt, Waehlisch Expires - August 2008 [Page 16]
MMCASTv6-PS February 2008
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 [51]:
o Bi-directional Tunnelling, in which the mobile node tunnels all
multicast data via its home agent. This fundamental multicast
solution hides all movement and results in static multicast trees. It
may be employed transparently by mobile multicast listeners and
sources, at the cost of triangular routing and possibly significant
performance degradations due to widely spanned data tunnels.
o Remote Subscription forces the mobile node to re-initiate
multicast distribution subsequent to handover, e.g., by submitting an
MLD listener report within the subnet a receiver newly attaches 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 cannot support session persistence under multicast source
mobility.
o Agent-based solutions attempt to balance between the previous two
mechanisms. Static agents typically act as local tunnelling proxies,
allowing for some inter-agent handover when the mobile node moves. A
decelerated inter-tree handover, i.e. 'tree walking', will be the
outcome of agent-based multicast mobility, where some extra effort is
needed to sustain session persistence through address transparency of
mobile sources.
MIPv6 [6] introduces bi-directional tunnelling as well as remote
subscription as minimal standard solutions. Various publications
suggest utilizing remote subscription for listener mobility only,
while advising bi-directional tunnelling as the solution for source
mobility. Such an approach avoids the 'tunnel convergence' or
'avalanche' problem [51], 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, it suffers from the drawback that multicast communication
roles are not explicitly known at the network layer and may change or
mix unexpectedly.
Schmidt, Waehlisch Expires - August 2008 [Page 17]
MMCASTv6-PS February 2008
None of the above approaches address SSM source mobility, except the
bi-directional tunnelling.
5.2 Solutions for Multicast Listener Mobility
5.2.1 Agent Assistance
There are proposals for agent assisted handovers for host based
mobility, which complement the unicast real-time mobility
infrastructure of Fast MIPv6 [21], the M-FMIPv6 [52,53], and of
Hierarchical MIPv6 [22], the M-HMIPv6 [54], and to context transfer
[55], which have been thoroughly analyzed in [27,56].
Network based mobility management, PMIPv6 [57], at its current stage
remains multicast transparent, as the MN experiences a point-to-point
home link fixed at its local mobility anchor (LMA). A PMIPv6 domain
thereby inherits the tunnel convergence problem; future optimizations
and extensions to shared links should foresee native multicast
distribution towards the edge network, including context transfer
between access gateways to aid the IP-mobility-agnostic MNs.
An approach based on dynamically negotiated inter-agent handovers is
presented in [58]. Aside from IETF work, countless publications
present proposals for seamless multicast listener mobility, e.g. [59]
provides a comprehensive overview.
5.2.2 Multicast Encapsulation
Encapsulation of multicast data packets is an established method to
shield mobility and to enable access to remotely located data
services, e.g., streams from the home network. Applying generic
packet tunnelling in IPv6 [60] in a unicast point-to-point way will
in addition bridge multicast-agnostic domains, but inherits the
tunnel convergence problem and may cause traffic multiplication.
Multicast enabled environments may take advantage of point-to-
multipoint encapsulation, i.e., generic packet tunnelling using an
appropriate multicast destination address in the outer header. Such
multicast-in-multicast encapsulated packets likewise enable reception
of remotely located streams, but do not suffer from the scaling
deficiencies of unicast tunnels.
For any use of encapsulation, the tunnelling entry point should
provide fragmentation to keep data packets within MTU size
constraints.
5.2.3 Hybrid Architectures
Stimulated by the desire to avoid complexity at the Internet core
network, application layer and overlay proposals for (mobile)
Schmidt, Waehlisch Expires - August 2008 [Page 18]
MMCASTv6-PS February 2008
multicast have recently raised interest. The possibility of
integrating multicast distribution on the overlay into the network
layer is being considered by the IRTF Scalable Adaptive Multicast
Research Group (SAM).
An early hybrid architecture of reactively operating proxy-gateways
located at the Internet edges was introduced by Garyfalos and
Almeroth [32]. The authors present 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. For
such hybrid architectures, a mobility-agnostic multicast backbone on
the overlay has been introduced in the Hybrid Shared Tree approach
[61].
Currently SAM is developing general architectural approaches for
hybrid multicast solutions [62], which will require detailed design
in future work.
5.2.4 MLD Extensions
MLD timer defaults [19] cause slow reaction of the multicast routing
infrastructure as well as of layer-3-aware access devices [63] on
client leaves, which may be disadvantageous for wireless links. This
tardy adaptation may be improved by carefully adjusting the Query
Interval. Alternatively, vendors have implemented listener node
tables at access routers to eliminate query timeouts on leaves
(explicit tracking).
A MN operating predictive handover, e.g., using FMIPv6, may
accelerate multicast service termination in the previous network by
submitting an early Done before handoff. MLD router Querying will
allow for a possible withdrawal in case of an erroneous prediction.
Backward context transfer may be used to ensure leave signalling,
otherwise. A further optimization is introduced by Jelger and Noel
[64] for the special case of the HA being a multicast router. A Done
message received through a tunnel from the mobile end node (through a
point-to-point link directly connecting the MN, in general), should
not initiate regular MLD membership queries with subsequent timeout.
Such explicit treatment of point-to-point links will reduce traffic
and accelerate the control protocol. Explicit tracking will cause
identical protocol behaviour.
While away from home, a MN may wish to rely on a proxy or standby
multicast membership service, optionally provided by a HA or proxy
agent. Such function relies 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 though transmission of group
data is paused. To enable such proxy control, the authors in [64]
Schmidt, Waehlisch Expires - August 2008 [Page 19]
MMCASTv6-PS February 2008
propose to extend MLD by a Listener Hold message exchanged between MN
and HA. This idea has been taken up in [54] and further developed to
a multicast router attendance control, allowing for a general
deployment of group membership proxies. Currently deployed IPTV
solutions use such mechanism in combination with a recent (video)
frame buffer, to enable fast channel switching (zapping).
5.3 Solutions for Multicast Source Mobility
5.3.1 Any Source Multicast Mobility Approaches
Solutions for the multicast source mobility problem can be devided in
three categories:
o Statically Rooted Distribution Trees:
Following a shared tree approach, Romdhani et al. [65] propose to
employ Rendezvous Points of PIM-SM as mobility anchors. Mobile
senders tunnel their data to these "Mobility-aware Rendezvous Points"
(MRPs). When restricted to a single domain this scheme is equivalent
to bi-directional tunneling. Focusing on interdomain mobile
multicast, the authors design a tunnel- or SSM-based backbone
distribution of packets between MRPs.
o Reconstruction of Distribution Trees:
Several authors propose construction of a completely new distribution
tree after the movement of a mobile source and therefore have to
compensate routing delays. M-HMIPv6 [54] 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 [66] introduces additional Multicast Agents (MA) that
advertise their service range. The mobile source registers with the
closest MA and tunnels data through it. When moving out of the
previous service range, it will perform MA discovery, a re-
registration and continue data tunneling with a newly established
Multicast Agent in its current vicinity.
o Tree Modification Schemes:
In the case of DVMRP routing, Chang and Yen [67] 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.
5.3.2 Source Specific Multicast Mobility Approaches
Schmidt, Waehlisch Expires - August 2008 [Page 20]
MMCASTv6-PS February 2008
The shared tree approach of [65] 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 [68] proposes binding caches and
obtaining 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 [69] suggest handover improvements by employing
anchor points within the source network, supporting 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 the source
handovers.
To address 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 [70] optimize
SPTs for moving sources on the path between source and first
branching point. O'Neill [71] suggests a scheme to overcome RPF check
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
[72] 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. [73] introduce a state
update mechanism for re-using major parts of established multicast
trees. The authors start from an initially established distribution
state centered at the mobile source's home agent. A mobile leaving
its home network will signal a multicast forwarding state update on
the path to its home agent and, subsequently, distribution states
according to the mobile source's new CoA 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.
Schmidt, Waehlisch Expires - August 2008 [Page 21]
MMCASTv6-PS February 2008
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. Admission control issues may arise with new CoA source
addresses being introduced to SSM channels (cf. [74] for a
comprehensive discussion). Due to lack of feedback, admissions [75]
and binding updates [76] of mobile multicast sources require self-
consistent authentication as achievable by CGAs. Future solutions
must address the security implications.
7.Summary and Future Steps
This memo is intended to support a future design of mobile 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 for currently available
solutions;
o including a comprehensive bibliographic reference base.
It is recommended that future steps towards extending mobility
services to multicast proceed to first solve the following problems:
1. Ensure seamless multicast reception during handovers,
meeting the requirements of mobile IPv6 nodes and networks.
Thereby address the problems of home subscription without
n-tunnels, as well as native multicast reception in those
visited networks, which offer a group communication service.
2. Integrate multicast listener support into unicast mobility
management schemes and architectural entities to define a
consistent mobility service architecture, providing equal
supporting for unicast and multicast communication.
3. Provide basic multicast source mobility by designing
address duality management at end nodes.
Schmidt, Waehlisch Expires - August 2008 [Page 22]
MMCASTv6-PS February 2008
8. 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
the option of an explicit feedback channel. There are attempts though
to implicitly obtain information on listening group members. One
proposed approach allowed an IGMP/MLD querier to be informed of the
pure existence of receivers. Based on an extension of IGMP, the
Multicast Source Notification of Interest Protocol (MSNIP) [77] 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 [78] as its
application layer transport protocol, which is accompanied by its
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.
9. References
Informative 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 S. Deering "Host Extensions for IP Multicasting", RFC 1112, August
1989.
4 G. Xylomenos and G.C. Plyzos "IP Multicast for Mobile Hosts", IEEE
Communications Magazine, 35(1), pp. 54-58, January 1997.
5 R. Hinden and S. Deering "Internet Protocol Version 6
Specification", RFC 2460, December 1998.
Schmidt, Waehlisch Expires - August 2008 [Page 23]
MMCASTv6-PS February 2008
6 D.B. Johnson, C. Perkins and J. Arkko "Mobility Support in IPv6",
RFC 3775, June 2004.
7 V. Devarapalli and F. Dupont "Mobile IPv6 Operation with IKEv2 and
the Revised IPsec Architecture", RFC 4877, April 2007.
8 Akyildiz, I and Wang, X. "A Survey on Wireless Mesh Networks",
IEEE Communications Magazine, 43(9), pp. 23-30, September 2005.
9 S. Bhattacharyya "An Overview of Source-Specific Multicast (SSM)",
RFC 3569, July 2003.
10 H. Holbrook, B. Cain "Source-Specific Multicast for IP", RFC 4607,
August 2006.
11 D. Waitzman, C. Partridge, S.E. Deering "Distance Vector Multicast
Routing Protocol", RFC 1075, November 1988.
12 D. Estrin, D. Farinacci, A. Helmy, D. Thaler, S. Deering, M.
Handley, V. Jacobson, C. Liu, P. Sharma, L. Wei "Protocol
Independent Multicast-Sparse Mode (PIM-SM): Protocol
Specification", RFC 2362, June 1998.
13 B. Fenner, M. Handley, H. Holbrook, I. Kouvelas: "Protocol
Independent Multicast - Sparse Mode PIM-SM): Protocol
Specification (Revised)", RFC 4601, August 2006.
14 M. Handley, I. Kouvelas, T. Speakman, L. Vicisano "Bidirectional
Protocol Independent Multicast (BIDIR-PIM)", RFC 5015, October
2007.
15 A. Ballardie "Core Based Trees (CBT version 2) Multicast Routing",
RFC 2189, September 1997.
16 D. Thaler "Border Gateway Multicast Protocol (BGMP): Protocol
Specification", RFC 3913, September 2004.
17 T. Bates et al. "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007.
18 S. Deering, W. Fenner and B. Haberman "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
19 R. Vida and L. Costa (Eds.) "Multicast Listener Discovery Version
2 (MLDv2) for IPv6", RFC 3810, June 2004.
Schmidt, Waehlisch Expires - August 2008 [Page 24]
MMCASTv6-PS February 2008
20 Arkko, J., Vogt, C., Haddad, W. "Enhanced Route Optimization for
Mobile IPv6", RFC 4866, May 2007.
21 Koodli, R. "Fast Handovers for Mobile IPv6", RFC 4068, July 2005.
22 Soliman, H., Castelluccia, C., El-Malki, K., Bellier, L.
"Hierarchical Mobile IPv6 mobility management", RFC 4140, August
2005.
23 Loughney, J., Nakhjiri, M., Perkins, C., Koodli, R. "Context
Transfer Protocol (CXTP)", RFC 4067, July 2005.
24 Montavont, N., et al. "Analysis of Multihoming in Mobile IPv6",
draft-ietf-monami6-mipv6-analysis-04, Internet Draft - (work in
progress), November 2007.
25 Narayanan, V., Thaler, D., Bagnulo, M., Soliman, H. "IP Mobility
and Multi-homing Interactions and Architectural Considerations",
draft-vidya-ip-mobility-multihoming-interactions-01.txt, Internet
Draft - (work in progress), July 2007.
26 Savola, P., Haberman, B. "Embedding the Rendezvous Point (RP)
Address in an IPv6 Multicast Address", RFC 3956, November 2004.
27 Schmidt, T.C. and Waehlisch, M. "Predictive versus Reactive -
Analysis of Handover Performance and Its Implications on IPv6 and
Multicast Mobility", Telecommunication Systems, 30(1-3), pp. 123-
142, November 2005.
28 Schmidt, T.C. and Waehlisch, M. "Morphing Distribution Trees - On
the Evolution of Multicast States under Mobility and an Adaptive
Routing Scheme for Mobile SSM Sources", Telecommunication Systems,
Vol. 33, No. 1-3, pp. 131-154, Berlin Heidelberg: Springer,
December 2006.
29 Diot, C. et al. "Deployment Issues for the IP Multicast Service
and Architecture", IEEE Network Magazine, spec. issue on
Multicasting 14(1), pp. 78-88, 2000.
30 Eubanks, M.: http://multicasttech.com/status/, 2007.
31 Garyfalos, A., Almeroth, K. and Sanzgiri, K. "Deployment
Complexity Versus Performance Efficiency in Mobile Multicast",
Intern. Workshop on Broadband Wireless Multimedia: Algorithms,
Architectures and Applications (BroadWiM), San Jose, California,
USA, October 2004. Online: http://imj.ucsb.edu/papers/BROADWIM-
04.pdf.gz
Schmidt, Waehlisch Expires - August 2008 [Page 25]
MMCASTv6-PS February 2008
32 Garyfalos, A., Almeroth, K. "A Flexible Overlay Architecture for
Mobile IPv6 Multicast", IEEE Journ. on Selected Areas in Comm., 23
(11), pp. 2194-2205, November 2005.
33 "Digital Video Broadcasting (DVB); IP Datacast over DVB-H: Set of
Specifications for Phase 1", ETSI TS 102 468;
"Digital Video Broadcasting (DVB); IP Datacast over DVB-H:
Implementation Guidelines for Mobility", ETSI TS 102 611.
34 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.
35 Van Mieghem, P., Hooghiemstra, G., Hofstad, R. "On the Efficiency
of Multicast", Transactions on Networking, 9, 6, pp. 719-732,
December 2001.
36 Chalmers, R.C. and Almeroth, K.C., "On the topology of multicast
trees", IEEE/ACM Trans. Netw. 11(1), 153-165, 2003.
37 Janic, M. and Van Mieghem, P. "On properties of multicast routing
trees", Int. J. Commun. Syst. 19(1), pp. 95-114, 2006.
38 Van Mieghem, P. "Performance Analysis of Communication Networks
and Systems", Cambridge University Press, 2006.
39 Shin, M. et al. "IPv6 Deployment Scenarios in 802.16 Networks",
draft-ietf-v6ops-802-16-deployment-scenarios-07, (work in
progress), Januar 2008.
40 Kim, S. et al. "Multicast Transport on IEEE 802.16 Networks",
draft-sekim-802-16-multicast-01, (work in progress), July 2007.
41 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.
42 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.
43 Wasserman, M. "Recommendations for IPv6 in Third Generation
Partnership Project (3GPP) Standards", RFC 3314, September 2002.
Schmidt, Waehlisch Expires - August 2008 [Page 26]
MMCASTv6-PS February 2008
44 Chen, X., Rinne, J. and Wiljakka, J. "Problem Statement for MIPv6
Interactions with GPRS/UMTS Packet Filtering", draft-chen-mip6-
gprs-07.txt, (work in progress), January 2007.
45 ETSI EN 302 304: "Digital Video Broadcasting (DVB); Transmission
System for Handheld Terminals (DVB-H)", European Standard
(Telecommunications series), November 2004.
46 Fairhurst, G. and Montpetit, M. "Address Resolution Mechanisms for
IP Datagrams over MPEG-2 Networks", RFC 4947, July 2007.
47 Montpetit, M. et al. "A Framework for Transmission of IP Datagrams
over MPEG-2 Networks", RFC 4259, November 2005.
48 Yang, X., Vare, J., Owens, T. "A Survey of Handover Algorithms in
DVB-H", IEEE Comm. Surveys, 8(4), 2006.
49 "Draft IEEE Standard for Local and Metropolitan Area Networks:
Media Independent Handover Services", IEEE LAN/MAN Draft IEEE
P802.21/D07.00, July 2007.
50 Melia, T. et al. "Mobility Services Transport: Problem Statement",
draft-ietf-mipshop-mis-ps-05, (work in progress), November 2007.
51 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.
52 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.
53 Xia, F. and Sarikaya, B. "FMIPv6 extensions for Multicast
Handover", draft-xia-mipshop-fmip-multicast-01, (work in progress,
expired), March 2007.
54 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.
55 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 - August 2008 [Page 27]
MMCASTv6-PS February 2008
56 Leoleis, G., Prezerakos, G., Venieris, I. "Seamless multicast
mobility support using fast MIPv6 extensions", Computer Comm. 29,
pp. 3745-3765, 2006.
57 Gundavelli, S., et al. "Proxy Mobile IPv6", draft-ietf-netlmm-
proxymip6, (work in progress), February 2008.
58 Zhang, H. et al "Mobile IPv6 Multicast with Dynamic Multicast
Agent", draft-zhang-mipshop-multicast-dma-03.txt, (work in
progress), January 2007.
59 Romdhani, I., Kellil, M., Lach, H.-Y. et. al. "IP Mobile
Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1),
2004.
60 Conta, A, Deering, S. "Generic Packet Tunneling in IPv6 -
Specification", RFC 2473, December 1998.
61 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.
62 Buford, J. "Hybrid Overlay Multicast Framework", draft-irtf-sam-
hybrid-overlay-framework-01.txt, Internet Draft (work in
progress), January 2007.
63 Christensen, M., Kimball, K. and Solensky, F. "Considerations for
Internet Group Management Protocol (IGMP) and Multicast Listener
Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
64 Jelger, C., Noel, T. "Multicast for Mobile Hosts in IP Networks:
Progress and Challenges", IEEE Wirel. Comm., pp 58-64, Oct. 2002.
65 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.
66 Lin, C.R. et al., "Scalable Multicast Protocol in IP-Based Mobile
Networks", Wireless Networks and Applications, 5, pp. 259-271,
2000.
67 Chang, R.-S. and Yen, Y.-S. "A Multicast Routing Protocol with
Dynamic Tree Adjustment for Mobile IPv6", Journ. Information
Science and Engineering 20, pp. 1109-1124, 2004.
Schmidt, Waehlisch Expires - August 2008 [Page 28]
MMCASTv6-PS February 2008
68 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
69 Jelger, C. and Noel, T. "Supporting Mobile SSM sources for IPv6
(MSSMSv6)", Internet Draft (work in progress, expired), January
2002.
70 Vida, R., Costa, L., Fdida, S. "M-HBH - Efficient Mobility
Management in Multicast", Proc. of NGC '02, pp. 105-112, ACM Press
2002.
71 O'Neill, A. "Mobility Management and IP Multicast", draft-oneill-
mip-multicast-00.txt, (work in progress, expired), July 2002.
72 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.
73 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.
74 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.
75 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.
76 Christ, O., Schmidt, T.C., Waehlisch, M. "A Light-Weight
Implementation Scheme of the Tree Morphing Protocol for Mobile
Multicast Sources ", Proc. of 33rd Euromicro Conf., pp. 149-156,
IEEE/CS Press, Sept. 2007.
77 Fenner, B. et al. "Multicast Source Notification of Interest
Protocol", draft-ietf-idmr-msnip-05.txt, (work in progress,
expired), March 2004.
78 Schulzrinne, H. et al. "RTP: A Transport Protocol for Real-Time
Applications", RFC 3550, July 2003.
Schmidt, Waehlisch Expires - August 2008 [Page 29]
MMCASTv6-PS February 2008
Acknowledgments
Work on exploring the problem space for mobile multicast has been
pioneered by Greg Daley and Gopi Kurup within their early draft
"Requirements for Mobile Multicast Clients" (draft-daley-magma-
mobile).
Since then, many people have actively discussed the different issues
and contributed to the enhancement of this memo. The authors would
like to thank (in alphabetical order) Kevin C. Almeroth, Hans L.
Cycon, Hui Deng, Gorry Fairhurst, Zhigang Huang, Christophe Jelger,
Rajeev Koodli, Mark Palkow, Imed Romdhani, Hesham Soliman and last
but not least very special thanks to Stig Venaas for his frequent and
thorough advice.
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
Hoenowerstr. 35
D-10318 Berlin, Germany
Email: mw@link-lab.net
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.
Schmidt, Waehlisch Expires - August 2008 [Page 30]
MMCASTv6-PS February 2008
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 (2008) This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
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.
Schmidt, Waehlisch Expires - August 2008 [Page 31]
| PAFTECH AB 2003-2026 | 2026-04-24 09:07:45 |