Internet Draft C. Janneteau
Document: draft-janneteau-nemo-multicast-mldproxy-00.txt E. Riou
Expires: October 2004 A. Petrescu
A. Olivereau
H.-Y. Lach
Motorola Labs
April 2004
IPv6 Multicast for Mobile Networks with MLD-Proxy
<draft-janneteau-nemo-multicast-mldproxy-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document addresses the problem of delivering IPv6 multicast
traffic to nodes inside a mobile network. An approach based on the
deployment of "MLD-based Multicast Forwarding (MLD-proxying)" [1]
in the mobile network, combined with the use of MLD [2][3] between
the mobile router (MR) and the visited network, is proposed. Such a
configuration allows multicast support for mobile networks, without
the need to run a multicast routing protocol. In addition of being
simple to implement and deploy, this approach provides global
mobility in the Internet, and optimal multicast routing with nested
mobile networks, while optimizing network and radio resources. This
document does not specify new protocols, nor extensions to existing
protocols.
Janneteau et al. Expires October 2004 [Page i]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
Table of Contents
Status of this Memo................................................i
Abstract...........................................................i
Conventions Used in this Document..................................1
1. Introduction....................................................1
2. Multicast Configuration in the Mobile Network...................3
3. Example.........................................................4
4. Discussion......................................................6
4.1 Simplicity.....................................................6
4.2 Global Mobility in the Internet................................6
4.3 Optimal Routing with Nested Mobile Networks....................7
4.4 Optimization of Network and Radio Resources....................7
4.5 Seamless Mobility..............................................8
4.6 Fault Tolerance................................................8
4.7 Operation in Disconnected Mode................................10
4.8 Independence from the NEMO Basic Support Protocol.............10
4.9 Support of Multicast Sources inside the Mobile Network........10
5. Security Considerations........................................11
6. Conclusion.....................................................11
Acknowledgements..................................................11
Copyright Notice..................................................13
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [4].
Some terms from the NEMO terminology [5] are used in this document;
as well as the following definitions from [1]:
Upstream Interface: A proxy device's interface in the direction of
the root of the tree. Also called the "Host
interface".
Downstream Interface: Each of a proxy device's interfaces that is
not in the direction of the root of the
tree. Also called the "Router interfaces".
1. Introduction
The NEMO Basic Support protocol [6] specifies extensions to Mobile
IPv6 [7] in order to provide reachability at a permanent address
and unicast session continuity for nodes in a mobile network, while
the mobile router (MR) moves between IPv6 subnets. The protocol
relies on the establishment of a bi-directional tunnel between the
mobile router (MR) and its home agent (HA). MR forwards outgoing
IPv6 packets through the tunnel, towards its home network.
Similarly, any packet arriving on the MR's home link are
intercepted by the HA and forwarded through the tunnel, if the
packet's destination address matches the mobile network prefix
Janneteau et al. Expires October 2004 [Page 1]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
(MNP). This is achieved by extending the MR's HA to support
redirection for the whole MNP, in addition to the MR's home
address.
While mobility support for IPv6 unicast sessions is fully addressed
by the above mentioned mechanism, [6] (up to now) does not discuss
the case of IPv6 multicast traffic. The issue here is to enable
session continuity both for multicast receivers and multicast
sources located inside a mobile network, while MR is moving.
Since multicast routing highly differs from unicast routing, the HA
forwarding mechanism defined by [6] for unicast packets does not
serve the forwarding of multicast packets. The key reason is that
multicast packets are sent to a multicast address that is unrelated
to the prefixes of the networks where potential multicast receivers
are located (e.g. the mobile network prefix).
A possible solution is the use of the MR-HA bi-directional tunnel
for the forwarding of multicast traffic too, in both directions,
between the MR and its home link. By co-locating a multicast
routing function on both the MR and its HA, multicast routing
protocol messages can be exchanged over the MR-HA tunnel. This
allows the creation of multicast branches from the Internet to
receivers in the mobile network, as well as from sources in the
mobile network to receivers in the Internet. This solution is
somehow similar to running a dynamic unicast routing protocol over
the MR-HA tunnel as described in section 8 of [6].
This document addresses the problem of delivering IPv6 multicast
traffic to nodes inside mobile networks. It proposes an attractive
alternative, in situations where the above mentioned approach is
either not possible (e.g. due to MR or HA capabilities), or the
network and radio overhead (i.e. sub-optimal routing, and
encapsulating header) introduced by the MR-HA tunnel is not
acceptable.
Up to now, two main approaches have been identified by the IETF
community enabling delivery of multicast traffic to mobile
multicast hosts [8][9]. The first one, sometimes called
Bi-directional Tunnelling (BT), relies on the Mobile IPv6 tunnel to
forward the multicast traffic to the mobile host. This is the same
principle as what has been discussed above. The second approach,
sometimes called Remote Subscription (RS), proposes that the mobile
host joins the multicast group via a local multicast router on the
visited link. For this purpose, the mobile host behaves like any
other fixed multicast receiver in the visited network, e.g. sending
MLD Report messages [2][3] to the local multicast router using an
IPv6 link-local source address.
Our approach proposes to apply the Remote Subscription principle to
the case of a mobile router, serving a mobile network. The MR uses
MLD messages to re-subscribe to the ongoing multicast sessions
through the local multicast router in the visited network. In the
case of the mobile network however, the two following requirements
have to be considered:
Janneteau et al. Expires October 2004 [Page 2]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
o First, MR must be able to discover which multicast groups nodes
in the mobile network are interested in, in order to subscribe
to them and forward the traffic to all interested receivers
inside the mobile network.
o Second, the multicast routing inside the mobile network should
be optimal. That is, routing multicast packets only in parts
of the mobile network where receivers are located; and thus
avoiding flooding.
Our approach bases on the deployment of "MLD-based Multicast
Forwarding (MLD-proxying)" [1] inside the mobile network, in order
to solve the above mentioned issues. Such a configuration,
combined with the use of Remote Subscription at MR, allows
multicast support for mobile networks, without the need to run a
multicast routing protocol.
In addition of being simple to implement and deploy, this approach
provides global mobility in the Internet and optimal multicast
routing with nested mobile networks. In addition, it optimizes the
usage of network and radio resources.
In the following sections, we will first review the details of the
multicast configuration inside the mobile network, as proposed in
our approach. Then, we will present some of the advantages
foreseen.
2. Multicast Configuration in the Mobile Network
The multicast configuration in the mobile network bases on the
deployment of the "MLD-based Multicast Forwarding" function (or
MLD-proxy) both on internal fixed routers and on the MR, in such a
way that group membership information will propagate router-by-
router (being aggregated at each router) from the routers serving
multicast receivers towards the MR.
This approach allows to route multicast traffic inside the mobile
network without the need to run a multicast routing protocol. It is
sufficient for each intermediate router to learn and proxy group
membership information and simply forward multicast traffic based
upon that information.
As opposed to multicast routing protocols, the MLD-based Multicast
Forwarding mechanism does not define a tree buidling algorithm, as
a way to avoid forwarding loops. The consequence is that the MLD-
based Multicast Forwarding approach can be used only in tree
topologies. Hence, routers inside the mobile network must be
manually configured to form a tree rooted at the MR, for the
purpose of multicast forwarding within the mobile network. This
configuration process consist in (1) selecting which routers should
run the MLD-proxy function, and (2) designating the unique upstream
interface and the downstream interface(s) on each of these proxy
devices. A proxy device performs the Host part of the MLD protocol
on the upstream interface, and the Router part of MLD on each of
Janneteau et al. Expires October 2004 [Page 3]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
its downstream interfaces. Especially, ingress interfaces of the
MR should be configured as downstream interfaces, while the egress
interface must be configured as the upstream interface.
The reader should refer to [1] for more details on the behaviors of
MLD-proxy devices.
3. Example
This section illustrates, through an example, the multicast
operations in a mobile network supporting the above mentioned
approach.
Let's assume the mobile network of Figure 1, with a quite complex
internal topology. The mobile network is made of 5 different IPv6
subnets (link1 to link5), interconnected by fixed routers FR1 to
FR4. MR is attached to Foreign Link A, served by the access router
AR1. Both AR1 and AR2 are multicast routers. No assumption is
made whether AR1 and AR2 run the same multicast routing protocol or
not. It may be the case if they are located in the same multicast
domain. If they are located in different domains, it is assumed
that an appropriate inter-domain multicast routing protocol is
deployed in the multicast inter-network.
CN
|
"===================================="
" "
" Multicast Inter-network "
" "
"===================================="
| |
AR1 AR2
Foreign | | Foreign
Link A ----------- ----------- Link B
|i1
MR ---
|i2 |
------------------------------------- link1 |
|i1 |i1 |i1 |
FR1 FR2 FR3 | Mobile
i2| |i3 |i2 |i2 | Network
link2 ----- ----- link3 -------------- link4 |
| |i1 |
`--------------- FR4 |
i2 |i3 |
------------- link5 |
| |
MNN |
---
Figure 1: Mobile Network with Complex Internal Topology
Janneteau et al. Expires October 2004 [Page 4]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
In order to support delivery of multicast traffic to MNN with the
MLD-based Multicast Forwarding scheme, the tree of MLD-proxies must
be configured in the mobile network. The configuration of Table 1
can be used.
==============================================================
| MLD-proxy? | Upstream Interface | Downstream Interface(s) |
| | (MLD Host Part) | (MLD Router Part) |
==================================================================
| MR | YES | i1 | i2 |
|FR1 | YES | i1 | i2, i3 |
|FR2 | YES | i1 | i2 |
|FR3 | NO | none | none |
|FR4 | YES | i1 | i3 |
==================================================================
Table 1: Example #1 of MLD-based
Multicast Forwarding Configuration
In this configuration, it is worth noting that FR3 is operating the
MLD protocol (either Host or Router part) on none of its
interfaces. Similarly, FR4 does not operate the MLD protocol on
its interface i2.
From the multicast routing perspective, the topology in the mobile
network is then a tree, as depicted in Figure 2. Of course, this
has no impact on the unicast routing inside the mobile network.
For instance, unicast packets may still be routed through FR3.
CN
|
"===================================="
" "
" Multicast Inter-network "
" "
"===================================="
| |
AR1 AR2
Foreign | | Foreign
Link A ----------- ----------- Link B
|i1
MR ---
|i2 |
------------------------------------- link1 |
|i1 |i1 |
FR1 FR2 | Mobile
i2| |i3 |i2 | Network
link2 ----- ----- link3 -------------- link4 |
|i1 |
FR4 |
|i3 |
------------- link5 |
| |
MNN |
---
Figure 2: Tree Multicast Routing Topology in the Mobile Network
Janneteau et al. Expires October 2004 [Page 5]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
Once the above configuration is in place, multicast traffic can be
delivered to receivers in the mobile network. Let's consider CN as
the source of a multicast group G, served by a multicast tree in
the multicast inter-network. Let's consider that none of the nodes
in the mobile network have yet subscribed to group G.
When MNN subscribes to group G, it sends an MLD Report message on
link5. FR4, which is the proxy device for this link, intercepts
this message, determines that this group is not yet received at
FR4, and thus sends its own MLD Report message for group G through
its upstream interface i1. The membership subscription for group G
propagates router-by-router (FR4 -> FR2 -> MR) within the mobile
network up to MR. Similarly, MR determines that this group is not
yet received, and thus sends its own MLD Report message for group G
through its upstream/egress interface towards its access router
(AR1) on the Foreign Link A. This will trigger establishment of a
new delivery branch for multicast group G towards AR1 along which
multicast packets will be forwarded. Upon reception of the
multicast packets, MR will look at the group membership information
associated with each of its downstream interfaces and forward the
packets through the interfaces for which the group G is mentioned.
Other routers in the mobile network will apply the same forwarding
mechanism. Finally, the packet will be received by MNN.
When MR moves to a new network, for instance to Foreign Link B, it
must re-subscribe to all multicast groups it was receiving through
its old access router (AR1). This is the Remote Subscription. For
this purpose MR sends new MLD Report messages for all the groups
(and related source lists) listed in its aggregated group list
towards the Foreign Link B. Upon reception of these messages, AR2
will trigger establishment of new multicast branches so that
multicast packets for these groups can be delivered to MR. Then MR
forwards these packets inside the mobile network as before. Note
that the mobility of the mobile network is transparent to the
multicast receivers in the mobile network since MR handles the re-
subscription on its own.
4. Discussion
4.1 Simplicity
The approach proposed is quite simple to implement on any type of
system thanks to the widespread availability of MLD.
It is quite simple to deploy and operate too, because no multicast
routing protocol is needed inside the mobile network. In addition,
the required configuration to form the tree of MLD-proxies seems
affordable in the context of mobile networks, which are typically
small-to-medium leaf networks.
4.2 Global Mobility in the Internet
The approach bases on the use of the MLD protocol between the MR
and the visited network, in order to maintain multicast session
continuity. This allows global mobility in the multicast inter-
Janneteau et al. Expires October 2004 [Page 6]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
network since MLD is expected to be supported in any IPv6 subnet.
With this approach the mobile network can roam in any visited
network, irrespective of the type of multicast routing protocol
locally deployed.
If the mobile network moves to a foreign link where multicast is
not supported, MR can still maintain ongoing multicast sessions by
performing re-subscription to the group, with MLD Report messages,
through the MR-HA bi-directional tunnel. Several approaches can be
envisaged for the multicast support on the HA. It can be
configured as a multicast router, or simply as an MLD-proxy. In
the later case, the HA would then issue its own MLD Reports towards
the multicast-enabled Border Router (BR) on the MR's home link.
4.3 Optimal Routing with Nested Mobile Networks
The approach provides optimal routing both in the infrastructure
and inside the mobile network.
Optimal routing is achieved in the infrastructure thanks to the
Remote Subscription concept, by reconstructing a new multicast
branch at the current location of MR.
Optimal routing inside the mobile network is achieved by the "MLD-
based Multicast Forwarding" mechanism which routes packets on the
shortest-possible-path (according to the tree topology configured),
and only in subnets where receivers are located.
It is worth noting that optimality of the path is preserved even in
scenarios of nested mobile networks.
It is acknowledged that under certain circumstances the remote
subscription process may involve overload in the network, for
instance when the MR moves frequently into foreign networks which
are topologically far from the existing multicast tree. In the
context of this document, however, it is considered that this
inconvenient is largely overcome by the advantages of offering
optimal routing paths outside the mobile network (no mandatory long
path to Home Agent) and inside an aggregation of mobile networks.
4.4 Optimization of Network and Radio Resources
The approach preserves native multicast routing of the traffic all
along the path from the source to the receivers, even when located
under several nested mobile routers. Flooding is avoided both in
the infrastucture thanks to the routing protocol (e.g. PIM-SM), and
inside the mobile network thanks to MLD-based Multicast Forwarding,
which optimizes network resources.
In addition, radio resources are also optimized since the sending
of native IPv6 multicast (i.e. not unicast-encapsulated) over the
air interface, between the infrastructure and MR or even within the
mobile network, avoids header overhead and allows to take full
advantage of a potential multicast support available at the link
level.
Janneteau et al. Expires October 2004 [Page 7]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
4.5 Seamless Mobility
The fact that MR aggregates group membership information (from
nodes inside the mobile network) and subscribes to those groups
using MLD, makes the MR behave like an individual mobile host with
respect to the multicast routing in the infrastructure. One
advantage is that seamless multicast handover mechanisms (such as
[10] and [11]) that have been defined for mobile hosts still work
for mobile networks that implement MLD-proxying locally.
For instance, in [10], seamless mobile multicast is achieved thanks
to the forwarding of multicast traffic through a temporary tunnel
established between the previous and the new multicast access
routers, while the multicast branch at the new access router is
under construction.
4.6 Fault Tolerance
Although the multicast delivery mechanism inside the mobile
network, based on "MLD-based Multicast Forwarding", requires an
appropriate designation of upstream and downstream interfaces on
internal routers in order to form a multicast tree, it features
some form of robustness against failure.
Indeed, this approach allows several routers on the same link to be
configured as MLD-proxy (and thus as MLD Router). In order to
avoid redundant traffic on the link, coming from those different
proxies, only one of them must be authorized to propagate the group
membership information upstream and to forward the multicast
traffic on the link. This is achieved by electing a single
forwarding MLD-proxy per link. The solution proposed in [1] is to
"piggy-back" this forwarder proxy election on the MLD Querier
election. In case of failure of the forwarder/querier router,
another one is automatically elected. This new one will then start
to propagate upstream the group membership information it had
previously collected on the link, and delivered the related
multicast traffic on this link. If later the former router
recovers, it will automatically win the Querier election (smaller
IP address), and thus take the role of forwarder on the link.
Considering the mobile network of Figure 1, another possible
multicast configuration is given in Table 2. Parentheses "()"
indicate the changes with respect to the configuration of Table 1.
==============================================================
| MLD-proxy? | Upstream Interface | Downstream Interface(s) |
| | (MLD Host Part) | (MLD Router Part) |
==================================================================
| MR | YES | i1 | i2 |
|FR1 | YES | i1 | i2, i3 |
|FR2 | YES | i1 | i2 |
|FR3 | (YES) | (i1) | (i2) |
|FR4 | YES | i1 | (i2), i3 |
==================================================================
Table 2: Example #2 of MLD-based Multicast Forwarding Configuration
Janneteau et al. Expires October 2004 [Page 8]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
According to [2] and [3], if the IPv6 adress assigned to FR1's i3
interface is smaller than the one of FR4's i2 interface, then FR1
will be the Forwarder/Querier for link3. Similarly, if the IPv6
address assigned to FR2's i2 interface is smaller than the one of
FR3's i2 interface, FR2 will be the Forwarder/Querier for link4.
The multicast tree is then equivalent to the one depicted in Figure
2. Now, if FR1 fails for any reason, FR4 will automatically becomes
the Forwarder/Querier for link3. Similarly, if FR2 fails, FR3 will
become the Forwarder/Querier for link4. This new multicast tree is
depicted in Figure 3. Ongoing multicast sessions are maintained.
CN
|
"===================================="
" "
" Multicast Inter-network "
" "
"===================================="
| |
AR1 AR2
Foreign | | Foreign
Link A ----------- ----------- Link B
|i1
MR ---
|i2 |
------------------------------------- link1 |
|i1 |i1 |
FR1 FR3 | Mobile
i2| |i2 | Network
link2 ----- ----- link3 -------------- link4 |
| |i1 |
`--------------- FR4 |
i2 |i3 |
------------- link5 |
| |
MNN |
---
Figure 3: Another Multicast Tree in the Mobile Network
When configuring several MLD-proxy devices on the same link, it
should be ensured that the overall multicast topology inside the
mobile network will always form a tree rooted at MR (i.e. no loop),
irrespective of the outcome of the forwarder election process. If
this rule is met, then an appropriate support for failure recovery
can be provided.
It is worth mentioning that, from the multicast delivery
perspective, this forwarder election mechanism also allows to
duplicate the mobile router serving the mobile network, and to
automatically switch to the backup mobile router only when the
master one fails.
Janneteau et al. Expires October 2004 [Page 9]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
4.7 Operation in Disconnected Mode
Another capability that may be expected from a mobile network, is
to allow establishment of new communications between nodes inside
the mobile network, and maintain existing ones, in situations where
MR is disconnected from the fixed infrastructure. This is referred
to as operating in disconnected (or autonomous) mode.
The MLD-proxy approach for multicast routing inside the mobile
network supports the disconnected mode, since the multicast packets
from a local source can be delivered to local receivers (fixed, and
mobile ones using remote subscription) without the need for the
packets to be routed outside of the mobile network. Indeed, [1]
recommends that each MLD-proxy device, receiving a multicast packet
on a downstream interface which is in the Forwarder/Querier mode,
forwards this packet through its upstream interface in addition to
through all its other downstream interfaces (in Forwarder/Querier
mode) which have a subscription pertaining to this packet. This
rule allows multicast packets from a local source to propagate
hop-by-hop to the MR, and be redistributed at each hop in the
downstream direction, so that all local receivers can be reached.
Again, it is worth noting that the proposed approach supports
multicast communications in disconnected mode, even in cases of
nested mobile networks. Indeed, if the top-level Mobile Router of
an aggregation of nested mobile networks is disconnected from the
infrastructure, multicast communications are still possible between
any sources and receivers inside this aggregation, irrespective of
their location. In addition, multicast routing will again be
optimal.
4.8 Independence from the NEMO Basic Support Protocol
This proposed mobile multicast scheme for mobile networks is
completely independent of the protocol used to maintain ongoing
unicast communications, be it the NEMO Basic Support [12] or
another. This independence allows flexibility.
4.9 Support of Multicast Sources inside the Mobile Network
The MLD-proxy forwarding rule discussed in section 4.7 allows
delivery of multicast traffic from a local source to all local
receivers in a mobile network.
In order to reach receivers outside of the mobile network, the MR
intercepting the multicast packet from the local source should then
forward this packet towards the multicast delivery tree in the
multicast inter-network. Because of the loop-avoidance mechanism of
multicast routing protocols (i.e. RPF check), multicast packets must
enter the multicast delivery tree through a point wherefrom the
source is considered topologically correct and subsequent RPF checks
of multicast routers in the delivery tree will complete.
Janneteau et al. Expires October 2004 [Page 10]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
A possible solution is that MR forwards outgoing multicast packets
towards its home network, for instance by taking advantage of the
MR-HA tunnel of the NEMO Basic Support protocol.
5. Security Considerations
The proposed solution for delivery of multicast to mobile networks
relies on the use of MLD-based Multicast Forwarding inside the
mobile network, combined with the use of MLD at the MR.
Security aspects of MLD and MLD-based multicast forwarding are
discussed in [2][3], and [1] respectivelly.
6. Conclusion
This document has discussed the support of IPv6 multicast for
mobile networks. The approach presented is also applicable in the
IPv4 context, where IGMP is used instead of MLD.
This approach, including MLD-based Multicast Forwarding inside the
mobile network and remote subscription at MR, has been demonstrated
during various public events including the HyWiN workshop [12], on
December 2003. The implementation was based on the LIVSIX [13]
open source IPv6 stack.
Acknowledgements
The authors would like to thank their colleagues in the OverDRiVE
project, in the framework of which this work has been partly
performed. Thanks too to Daniel Negru and Greg Daley, for the
discussion held on the NEMO mailing list that has encouraged the
publication of this document.
Janneteau et al. Expires October 2004 [Page 11]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
References
[1] Fenner, B., He, H., Haberman, B. and Sandick, H., "IGMP/MLD-
based Multicast Forwarding ("IGMP/MLD Proxying")", work in
progress, draft-ietf-magma-igmp-proxy-06.txt, April 2004.
[2] Deering, S., Fenner, W. and Haberman, B., "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[3] Vida, R. and Costa, L., "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", work in progress, draft-vida-mld-v2-08.txt,
December 2003.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Ernst, T. and Lach, H.-Y., "Network Mobility Support
Terminology", draft-ietf-nemo-terminology-01.txt, work in
progess, February 2004.
[6] Devarapalli, V., Wakikawa, R., Petrescu, A. and Thubert, P.,
"Network Mobility (NEMO) Basic Support Protocol", work in
progress, draft-ietf-nemo-basic-support-02.txt, December 2003.
[7] Johnson, D., Perkins, C. and Arkko, J, "Mobility Support in
IPv6", work in progress, draft-ietf-mobileip-ipv6-24.txt, June
2003.
[8] Daley, G., Kurup, G., "Requirements for Mobile Multicast
Clients", work in progress, draft-daley-magma-mobile-00.txt,
June 2003, (Expired).
[9] Janneteau, C., Tian, Y., Csaba, S., Lohmar, T., Lach, Y.-H.,
Tafazolli, R., "Comparison of Three Approaches Towards Mobile
Multicast", IST Mobile Summit 2003, Aveiro, Purtugal, 15-18
June 2003, http://www.mobilesummit2003.org.
[10] Simon, C., Vida, R., Kersch, P., Janneteau, C., Leijonhufvud,
G., "Seamless IP Multicast Handovers in OverDRiVE", IST Mobile
Summit 2004, Lyon, France, 27-30 June 2004, (accepted for
publication), http://www.mobilesummit2004.org.
[11] Suh, K., Kwon, D.-H., Suh, Y.-J. and Park, Y., "Fast Multicast
Protocol for Mobile IPv6 in the fast handovers environments",
work in progress, draft-suh-mipshop-fmcast-mip6-00.txt,
January 2004.
[12] Janneteau, C., Demonstration entitled "Multicast for Moving
Networks", HyWiN 2003 workshop, Turin, Italy, 2 December 2003,
http://www.ist-overdrive.org/HyWiN2003/.
[13] LIVSIX IPv6 Stack, http://www.enrl.motlabs.com/livsix
Janneteau et al. Expires October 2004 [Page 12]
INTERNET-DRAFT Multicast for Mobile Networks April 2004
Authors' Addresses
Christophe Janneteau Emmanuel Riou
Motorola Labs Motorola Labs
Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin
Gif-sur-Yvette 91193 Gif-sur-Yvette 91193
France France
Phone: +33 1 69352548 Phone: +33 1 69354829
Christophe.Janneteau@motorola.com Emmanuel.Riou@motorola.com
Alexandru Petrescu Alexis Olivereau
Motorola Labs Motorola Labs
Parc les Algorithmes St Aubin Parc les Algorithmes St Aubin
Gif-sur-Yvette 91193 Gif-sur-Yvette 91193
France France
Phone: +33 1 69354827 Phone: +33 1 69352516
Alexandru.Petrescu@motorola.com Alexis@motorola.com
Hong-Yon Lach
Motorola Labs
Parc les Algorithmes St Aubin
Gif-sur-Yvette 91193
France
Phone: +33 1 69352536
Hong-Yon.Lach@motorola.com
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Funding for the RFC editor function is currently provided by the
Internet Society.
Janneteau et al. Expires October 2004 [Page 13]