[multimob] New draft: MIPv6 Extensions for Mobile Multicast: Problem Statement
"Tony" <guanjian8632@163.com> Wed, 04 July 2007 01:27 UTC
Return-path: <multimob-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5teP-0006W4-KM; Tue, 03 Jul 2007 21:27:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I5teO-0006PG-AM for multimob@ietf.org; Tue, 03 Jul 2007 21:27:24 -0400
Received: from m5-82.163.com ([202.108.5.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1I5teD-0007XN-G1 for multimob@ietf.org; Tue, 03 Jul 2007 21:27:24 -0400
Received: from sunguan (unknown [218.249.29.40]) by smtp2 (Coremail) with SMTP id wKjRDLDr4gJt94pGX7cNAw==.18899S2; Wed, 04 Jul 2007 09:27:09 +0800 (CST)
Date: Wed, 04 Jul 2007 09:27:08 +0800
From: Tony <guanjian8632@163.com>
To: multimob <multimob@ietf.org>
Organization: Beijing JiaoTong University
X-mailer: Foxmail 5.0 [cn]
Mime-Version: 1.0
X-Coremail-Antispam: 1U3Yxn0WfASr-VFAUDIcSsGvfJTRUUUjyAFxVCF77xC6IxKo4 kEV4ylYx0Ex4A2jsIE14v26r4j6F4UMxkIecxEwVAFwVWkMcIj6xIIjxv20xvE14v26r12 6r1DMIIF0xvEx4A2jsIE14v26r1j6r4UM4xvF2IEb7IF0Fy264kE64k0F24lnxkEFVAIw2 0F6cxK64vIFxWl6VACY4xI67k04243AwC2zVAF1VAY17CE14v26r1j6r15Mx02cVAKzwCY 0x0Ix7I2Y4AK6ryj6rWUM4xvF2IEb7IF0Fy26I8I3I1lIxAIcVC0I7IYx2IY67AKxVWUJV WUCwCF72vE52k0Y41lw4CEF2IF47xS0VAv8wCI42IY6xIIjxv20xvEc7CjxVAFwI0_Jr0_ Gr1l1I0EscIYIxCEI4klw4CSwwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UM7AC8VAFwI 0_Jr0_Gr1lb4IE77IF4wAFIxvE14AKwVWUJVWUGwAqx4xG64xvF2IEw4CE5I8CrVC2j2Wl c7Ca8VAvwVCqb41lb7Iv0xC_JrUanT9S1TB71UUUUU7a7-sFnT9fnUUI43ZEXa7IU50fO7 UUUUUFnT9fnV45pFWDZrW3Kw1rCrWrZr1rGFW7AoXrprWUJFyDpay5GFy5tr4kXryUAw1v ywnYvrn5C3yktr4jkry5G34UXws8GFy0qr43tw45ZayDGr1DArWjqrnFvry5X34DZ3D==
Message-Id: <468AF76E.0826F9.12806@m5-82.163.com>
X-Spam-Score: 1.4 (+)
X-Scan-Signature: bc3b4a0e61e6c2546ab80acca7fc79df
Subject: [multimob] New draft: MIPv6 Extensions for Mobile Multicast: Problem Statement
X-BeenThere: multimob@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: guanjian8632@163.com
List-Id: Multicast Mobility <multimob.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/multimob>
List-Post: <mailto:multimob@ietf.org>
List-Help: <mailto:multimob-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/multimob>, <mailto:multimob-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1400952549=="
Errors-To: multimob-bounces@ietf.org
Hello every
Recently, I writed and submitted a new draft of MIPv6 extensions for mobile multicast.
Welcom everyone to comment.
Details:
Title : MIPv6 Extensions for Mobile Multicast: Problem Statement
Author(s) : Hongke Zhang, et al.
Filename : draft-zhang-multimob-memcast-ps-00.txt
Pages : 17
Date : 2007-07-01
Abstract
Mobile multicast is a research hotspot and gets more and more study
recently. But the current mobility management specifications can not
provide effective multicast packets transmission, and existing mobile
multicast schemes are not generally accepted. In this memo, we
discuss the problems arising from mobile multicast and address the
solutions of MIPv6 extensions to support mobile multicast services.
===============================================================================
Multimob Hong-ke Zhang
Internet Draft Jian-feng Guan
Expires: January 2008 De-yun Gao
Hua-chun Zhou
Ya-juan Qin
Beijing JiaoTong University
July 2, 2007
MIPv6 Extensions for Mobile Multicast: Problem Statement
draft-zhang-multimob-memcast-ps-00.txt
Status of this Memo
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.
This document may only be posted in an Internet-Draft.
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 Internet-Draft will expire on January 2, .
Abstract
Mobile multicast is a research hotspot and gets more and more study
recently. But the current mobility management specifications can not
provide effective multicast packets transmission, and existing mobile
multicast schemes are not generally accepted. In this memo, we
discuss the problems arising from mobile multicast and address the
solutions of MIPv6 extensions to support mobile multicast services.
Zhang et al Expires January 2, 2008 [Page 1]
Internet-Draft MEMCAST-PS July 2007
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 [1].
Table of Contents
1. Introduction.................................................2
2. Terminology..................................................3
3. Problem Description..........................................3
3.1. General issues..........................................4
3.1.1. Reconstruction of multicast delivery tree..........5
3.1.2. Mobile source issues...............................5
3.1.3. Mobile receiver issues.............................5
3.1.4. Mobile forwarder issues............................5
3.2. Mobility support specification issues...................5
3.3. Multicast control protocol issues.......................7
3.4. Multi-hop mobile multicast issues.......................7
3.5. Multihoming mobile multicast issues.....................8
4. Solutions....................................................8
4.1. MIPv6 extensions........................................9
4.1.1. MIPv6 signaling extensions.........................9
4.1.2. Multicast route optimization.......................9
4.2. MLD extensions..........................................9
4.3. Multi-hop mobile multicast.............................10
4.4. Multihoming mobile multicast...........................11
5. Security Considerations.....................................11
6. IANA Considerations.........................................11
7. Conclusions.................................................11
8. Acknowledgments.............................................12
9. References..................................................13
9.1. Normative References...................................13
9.2. Informative References.................................13
Author's Addresses.............................................16
Intellectual Property Statement................................16
Disclaimer of Validity.........................................16
Copyright Statement............................................17
Acknowledgment.................................................17
1. Introduction
With the development of various mobile technologies, mobile multicast
becomes more important because it can provide many applications such
as mobile conference, on-line game. Mobile multicast has to solve
mobility problem of multicast subscriber (multicast source and
Zhang, Guan et al. Expires January 2, 2008 [Page 2]
Internet-Draft MEMCAST-PS July 2007
multicast receiver) and it includes link layer handover such as WLAN,
WiMAX, UMTS and network layer handover such as MIPv6 [2] and its
variants such as FMIPv6 [9], HMIPv6 [10]and NEMO [3] which can
provide the mobility support for mobile node or mobile network.
However, these specifications do not provide an effective method to
support mobile multicast services.
MIPv6 is designed to support unicast communication by caching the
binding between HoA and CoA of MN, and route the packets addressed to
HoA to CoA transparently. As for the multicast data, two basic
methods, Bi-directional Tunnel (BT) and Remote Subscribe (RS) methods
were proposed. BT is transparent and has lower join latency, but
introduces triangular routing and additional transmission overheads.
While RS has effective routing, but increases long join delay
especially when foreign networks do not have the multicast states of
MN interested, and even result in multicast service disruption if
foreign networks do not support multicast. Based on BT and RS,
several improved schemes were proposed in past few years [11], and
try to make the tradeoff between BT and RS, using different multicast
agent selection algorithms or modifying the mobility support
specifications [12].
The prime problem of mobile multicast is that the current mobility
support specifications such as MIPv6 can not provide effective
multicast transmission mechanism. The binding cache in MIPv6 only
records the mapping between HoA and CoA which can be used to reroute
the unicast packets directly. However, for multicast data, no such
mechanism is defined. So, in this memo, we specify the problems scope
for MIPv6 extensions of mobile multicast and describe the potential
solutions.
2. Terminology
The terminology used in this memo is already defined in MIPv6, FMIPv6,
HMIPv6 and NEMOv6.
3. Problem Description
Mobile multicast derives from the development of Mobile IP and
multicast and the current mobile multicast schemes are mainly based
on the combination of multicast and Mobile IP. So, the mobile
multicast problem comes from two parts, first part is multicast and
the second part is mobility support specifications.
Multicast provides an effective group communication mechanism in IP
layer to reduce the redundant packets, and it is based on host group
model [6] which consists of multicast route protocol such as PIM-SM
Zhang, Guan et al. Expires January 2, 2008 [Page 3]
Internet-Draft MEMCAST-PS July 2007
[7] and multicast group control protocol such as MLDv1 [4] and MLDv2
[5]. Multicast routing protocol constructs the multicast delivery
tree and maintains the multicast group states in multicast router,
while multicast control protocol is used by multicast router and host
to exchange the multicast services information. Multicast supports
dynamic membership but does not support mobile group members. As a
result, to provide multicast services for mobile host, both multicast
route protocol and multicast control protocol face new challenges.
+---+ --+
Mobile source | S |--->move |
+---+ +-> MLD protocol
| |
+-------+--------+ |
| | --+
Mobile +---+ +---+ |
Forwarder | R |--->move | R | |
+---+ +---+ |
| | +-> Multicast
+-----+-----+ | | Route protocol
| | | |
+---+ +---+ +---+ |
| R | | R | | R | |
+---+ +---+ +---+ --+
| |
+-------+-------+ |
| | | +-> MLD protocol
+---+ +---+ +---+ Mobile |
| H | | H | | H |---> Receiver |
+---+ +---+ +---+ --+
Figure 1 Mobile multicast classification
3.1. General issues
Traditional multicast routing protocols have been designed
considering static network topology, and the multicast delivery tree
is stable and little changed. Figure 1 shows the classification of
mobile multicast, including mobile source, mobile receiver or mobile
forwarder. Directly applying traditional multicast route protocols to
mobile scenario may result in multicast session disruption. To
improve the performance of multicast services, it has to solve the
following problems.
Zhang, Guan et al. Expires January 2, 2008 [Page 4]
Internet-Draft MEMCAST-PS July 2007
3.1.1. Reconstruction of multicast delivery tree
The foundational problem in mobile multicast is the reconstruction of
multicast delivery tree. There are two kinds of multicast delivery
trees, source-based tree such as DVMRP, MOSPF, PIM-DM and PIM-SSM,
and shared tree such as PIM-SM and CBT. Source-based protocols
construct multicast delivery trees for every source in a group, while
shared tree protocols construct a RP or Core based multicast delivery
tree for a group. When we implement mobile multicast, the same mobile
types in different multicast delivery tree may have different results.
3.1.2. Mobile source issues
Once source changes its attachment, it will affect all receivers in
the group. Firstly, transparency is the major issue for mobile source.
Mobile source should hide the mobility and use the HoA as the source
address of multicast data. Otherwise, the foreign network will not
forward these packets. However, using the HoA will result in the
ingress filtering problem and RPF check failure. Secondly, packet
loss has an important impact on the performance of mobile multicast
services. Thirdly, when mobile source is out of the range of group,
the AR to which mobile source is attached will discard the multicast
packets from the mobile source which will be considered as a foreign
source.
3.1.3. Mobile receiver issues
Once receiver changes its attachment, it only affects itself, and
causes join delay and packet loss.
3.1.4. Mobile forwarder issues
Mobile forwarder is the node in the multicast delivery tree. Once
forwarder changes its attachment, it will affect the receivers in the
multicast route path. Although mostly mobile multicast schemes only
focus on the mobility in the access networks, the mobility in the
core networks should also be considered forward mobility.
3.2. Mobility support specification issues
Mobile IP provides handover management and location management for
mobile entity, and it sets up the binding cache between HoA and CoA
to support the transparent unicast route. But, it does not provide
mechanisms to enable multicast session to survive handover and to
seamlessly continue from the new location.
Zhang, Guan et al. Expires January 2, 2008 [Page 5]
Internet-Draft MEMCAST-PS July 2007
Firstly, MIPv6 should not only record the unicast binding cache, but
also record the multicast binding cache to assist the mobile
multicast. Multicast binding cache may include the group address,
source lists, filter mode and interface identifier. It gets the
membership information through the tunneled MLD messages or extended
signaling and gets the MN information from unicast binding cache. The
Multicast binding cache can be located in the HA or the other entity
such as Rendezvous Point in PIM-SM.
Secondly, Multicast session consists of multicast data transmission
and multicast group control messages transmission. HA should
distinguish the owner of MLD messages from the MN and intercepts and
tunnels the global scoped multicast packets on home network based on
the multicast group control protocol. MN should send the MLD messages
to HA through tunnel or AR through physical interface to receive the
multicast data from HA or AR respectively. As described in MIPv6, to
support mobile multicast, HA should be a full IPv6 multicast router
or have the proxy MLD function coupled with kernel multicast
forwarding. However, MIPv6 does not define the detailed mechanisms
and the functional requirements for HA and MN. To support the
seamless multicast handover, HA should cooperate the MIPv6 with
multicast routing protocol or proxy MLD, and sets up the multicast
information for MN and transmits the native multicast packets between
HA and MN.
Thirdly, Mobile IP based mobile multicast schemes have to solve the
route optimization problem. BT and RS are two basic mobile multicast
methods, but both of them have the disadvantages. Thomas C. Schmidt
and Matthias Waehlisch [12] classify mobile multicast methods into
three kinds, BT based, RS based and Agent based. BT based methods use
the bi-directional tunnel to transmit the multicast data between old
location and new location of mobile entity, but result in tunnel
convergence problem and additional overheads. Using IP tunnels
involves multiple encapsulation and de-capsulation operations which
require an extra cost of CPU time and memory, and increase the
multicast packet size which causes fragmentation and large bandwidth
consumption. [11] RS based methods rejoin the multicast delivery tree
in new location, but introduce additional join delay, which includes
L2 and L3 handover delay, multicast membership protocol delay,
multicast delivery tree computation delay, and the increased
propagation delay. It makes the multicast session instantaneous and
degrades the performance of multicast services. Agent based methods
try to balance between BT and RS, but increase the complexity. It
needs more signaling to select the multicast agent and reconstruct
the multicast tree for mobile entity.
Zhang, Guan et al. Expires January 2, 2008 [Page 6]
Internet-Draft MEMCAST-PS July 2007
3.3. Multicast control protocol issues
IPv6 multicast router uses the MLD as the multicast group control
protocol to discovery the multicast listeners, while the host uses
the MLD to join and leave the group. MLD protocol is designed for
fixed nodes, and only focuses on the dynamic group membership, but
not considers the mobility of node. To support the mobile multicast,
MLD protocol has to solve the following problems.
Firstly, mobile entity has to send unsolicited MLD report message
immediately after detecting the movement to shorten the rejoin delay.
However, the rejoin delay results in many packets lost unfortunately
even without including the link layer and IP layer handover delay.
MLD can not maintain multicast group membership continually. As a
result, we should increase new MLD message types to support mobile
entity.
Secondly, MLD messages are link-local, destined to a link-scope
multicast address and have a hop limit of 1 and can not forward to
the other subnets. When mobile multicast subscriber moves into
another subnet, it has to reconstruct MLD states in the new location.
However, the MLD protocol does not provide this mechanism. How to
transfer the MLD state between old location and new location affects
the performance of multicast services.
Thirdly, MLD protocol only records the multicast membership
information for every link not the node, which can reduce the number
of multicast states in shared link such 802.11. But for some point-
to-point links such as UMTS, HA assigns a home link prefix that is
unique for each MN and HoA is assigned from this unique prefix. As a
result, it makes a link for each MN. So the multicast behavior could
be simplified. Extend the MLD to record MLD state for MN in point-to-
point link is preferable.
3.4. Multi-hop mobile multicast issues
The current mobile multicast schemes mainly are single-hop based, and
the distance between mobile multicast subscribers and the AR is one
hop. However, mobile network multicast especially MANET multicast
interworking with the fixed networks is multi-hop. As for the NEMO
multicast, the node in the mobile network such as LFN, VMN joins the
multicast group through MR which may be multiple hops to the access
networks. MLD messages and multicast packets can not be forwarded if
the router in the path to AR does not support the multicast function.
Especially when nesting happens, the multicast packets transmission
will suffers from large overheads and extra propagation delay, which
result in degrade of multicast services performance significantly. As
Zhang, Guan et al. Expires January 2, 2008 [Page 7]
Internet-Draft MEMCAST-PS July 2007
for the MANET multicast interworking with the fixed networks, every
node in the MANET may be dynamic and get the connection through
multiple nodes as relay points. Because the mobile devices have
limited bandwidth, power, and coverage, the multi-hop mobile
multicast scheme should be light-weight. How to provide multicast
service for these nodes in the mobile network should be considered in
the further study.
3.5. Multihoming mobile multicast issues
Most mobile multicast methods including mobile network multicast are
based on single interface and connect to one AR at a time, which
results in the mobile entity having to break the connection to the
current network before reattaching itself to the new network (Break-
Before-Mobile) [13]. The reason is that the current wireless
interface of mobile devices is incapable of listening to multiple
base stations. As a result, the multicast session will be disrupted
because of the serious packet loss.
Recently, more and more mobile devices have multiple interfaces and
can support more than one Internet connections at a time
(multihoming). Using multiple interfaces will provide Make-Before-
Break handoffs [14], ubiquitous access, redundancy, load balancing.
However, realizing the multihoming mobile multicast has to consider
the problems inheriting from the MIPv6 multihoming [32]. Firstly, to
use the multiple interfaces simultaneously, MN should bind multiple
CoAs to a given HoA, but the current MIPv6 specification is lacking
such ability. Secondly, when multiple paths from and to MN, MN should
choose a suitable one to transmit the multicast packets, which
includes the interface selection, HoA and CoA selection. Thirdly,
when current path fails, MN should redirect the flow to the new path.
Final, to balance the multicast traffic among multiple interfaces, MN
should set up a load balance mechanism.
4. Solutions
Mobile IP based mobile multicast solutions include MIPv6 variants
extensions, MLD extensions, aiming to support multicast mobility.
These extensions usually put the multicast information in signaling
or transfer MLD state among ARs to reduce the re-join delay and
realize optimal multicast packets transmission.
Zhang, Guan et al. Expires January 2, 2008 [Page 8]
Internet-Draft MEMCAST-PS July 2007
4.1. MIPv6 extensions
4.1.1. MIPv6 signaling extensions
Most mobile multicast schemes extend the MIPv6 to carry the multicast
information in signaling. In basic MIPv6, BT method transmits the MLD
messages and multicast packets through the unicast tunnel. Based on
RS, F. Xia and B. Sarikaya [15] propose FMIPv6 extension for
multicast handover, which introduces a new Multicast Group
Information Option (MGIO) in Fast Binding Update (FBU) and Handover
Initiate (HI). To reduce the join delay, PAR transmits multicast
group information to NAR through FBU and HI with the MGIO to join the
multicast group in advance. Then Georigios A. Leoleis et al. [16]
propose Fast MIPv6 extensions for Multicast handover support with
Flow Tunneling and Buffering (M-FMIPv6/FTB), which uses the
conditional tunneling of multicast traffic per flow to solve the
tunnel convergence. Besides, it proposes a simple buffering technique
to eliminate multicast data loss. More recently, Dong-Hee Kwon et al.
[17] proposed an efficient multicast support scheme for FMIPv6. It
introduces new multicast options in mobility header and ICMP header,
which contain the multicast group information MN subscribed. To
reduce the join delay, NAR setups the multicast states MN interested
in advance by the FMIPv6 operation. Beside, it establishes a
multicast specific tunnel between PAR and NAR instead of the unicast
tunnel between PAR and NCoA to solve the tunnel coverage problem.
Based on BT, Thomas Schmidt et al. [18] proposed seamless multicast
handover in a HMIPv6 environment (M-HMIPv6), which uses the MAP as
anchor point for mobile multicast and transmits all multicast data
through this MAP using Regional CoA (RCoA) for multicast receiver or
source.
4.1.2. Multicast route optimization
Multicast route optimization aims to solve the tunnel convergence
problem and realize the native multicast transmission. Agent based
schemes described in [12] mainly focus on these problems. The
multicast agent takes over the multicast packets transmission
function, and sets up the optimal routing to mobile multicast
subscriber. For example, M-FMIPv6 [19] chooses every AR as the agent
while M-HMIPv6 chooses the MAP as the agent. DMA [20] chooses the
dynamic multicast agent based and distance and movement.
4.2. MLD extensions
Christophe Jelger and Thomas Noel [23] introduces a new type of MLD
message called MLD hold message, which is used to notify an HA to
Zhang, Guan et al. Expires January 2, 2008 [Page 9]
Internet-Draft MEMCAST-PS July 2007
stop forwarding multicast data for specified group, but keep the
group membership.
To transfer the multicast state in advance, MN should have the
ability to identify whether the AR has the multicast function or not
at first. B. Haberman and J. Martin [8] propose Multicast Router
Discovery (MRD), a general mechanism to discovery the multicast
routers. MRD introduces Multicast Router Advertisement (MRA) and
Multicast Router Solicitation (MRS) to detect the IP multicast
forwarding ability of a router. MRD protocol can be used in mobile
multicast to help the mobile entity to realize the native multicast
data transmission. After detecting the multicast ability, the mobile
entity should transfer the MLD states to the candidate AR. Based on
context transfer [21], I. Miloucheva and K. Jonas [22] propose fast
mobile multicast in IPv6 based on multicast listening context
transfer method to transmit the MLD states among ARs.
4.3. Multi-hop mobile multicast
Mobile entity may have multiple Internet connections at the same time
and attaches to multiple networks, which have different coverage,
bite rate, bandwidth. How to implement mobile multicast in
multihoming scenarios may be the key to provide the seamless mobile
multicast handover.
As for NEMO multicast, C. Janneteau et al. [24] propose MLD-proxy
based IPv6 multicast for mobile network, which deploys MLD-based
multicast forwarding (MLD-proxying) between MR and visited networks
to support the multicast service in mobile network. Kiyong Park et al.
[25] propose a dynamic multicast tree construction mechanism for
mobile network. It sets up the multicast tunnel between MR and
multicast router to support the multicast services.
As for the MANET multicast interworking with fixed networks, Wei Ding
[26] introduces a Multicast GateWay (MGW) entity to realize multicast
routing in the mixed network. MGW has both wire-line multicast
interface and wireless communication interface and supports both
multicast route protocols. At the beginning it joins the multicast
groups on both sides explicitly transmit data packets. However, it
has been less focused on the multiple MGWs scenario. Then P. Ruiz and
A. Skarmeta propose the Multicast MAnet Routing Protocol (MMARP) [27].
It introduces Multicast Internet Gateway (MIG) and uses the on-demand
multicast protocol to construct the multicast structure in the MANET,
maintains the route to the MIG. Besides, MMARP supports a standard
mobile node accessing the Internet through the MANET. MIG keep the
connectivity with the AR through the IGMP inquire message. However,
the existed schemes still need further study to solve problems such
Zhang, Guan et al. Expires January 2, 2008 [Page 10]
Internet-Draft MEMCAST-PS July 2007
as multicast security, management etc. Afterwards Wang et al. propose
a Modified MLD (M.MLD) scheme [28] which modifies the MLD messages
for MANET to realize the IPv6 multicast between fixed network and
MANET. In this scheme the access router in the MANTE is deployed as a
Designated Router (DR) of the fixed network, and M.MLD is used as the
multicast membership management protocol in the MANET by
encapsulating in the unicast packets. More recently, IETF MANET WG
proposes a Simplified Multicast Forwarding (SMF) for MANET [29] and
tries to support interoperability with connected wired infrastructure.
Zhang hui et al. [30] proposes a multicast interworking scheme
between MANET and fixed network which supports cross-network
multicast sessions. It uses the Certificate Authority (CA) [31] to
manage the cross-network multicast sessions and insure the multicast
security.
4.4. Multihoming mobile multicast
Current most mobile multicast schemes based on single interface to
perform multicast handover, which is less stable and reliable. Once
MN or MR lost its connection to Internet, it will have a significant
impact on performance of mobile multicast. Recently, the multihoming
issues in MIPv6 [32] [33] and NEMO [34] were discussed. MN with
multiple addresses which allocated to either a single interface or
multiple interfaces can provide ubiquitous, permanent and fault-
tolerant access to the Internet.
Zhang et al. [35] propose a multiple interfaces mobile multicast
scheme in Mobile IPv6 and NEMO. The interfaces in the MN may be
homogeneous or heterogeneous. This scheme introduces an interface
multicast state transition mechanism and multiple interfaces handover
mechanism for mobile multicast listeners and mobile multicast sources
to support seamless mobile multicast handover.
5. Security Considerations
This memo discusses the MIPv6 extensions for mobile multicast.
Security issues arise from the extensions of mobility support
specifications and MLD protocols.
6. IANA Considerations
There are no IANA considerations introduced by this memo.
7. Conclusions
This memo discusses the problems arise from the mobile multicast over
MIPv6 variants, and describes some solutions.
Zhang, Guan et al. Expires January 2, 2008 [Page 11]
Internet-Draft MEMCAST-PS July 2007
8. Acknowledgments
The authors would like to thank Behcet Sarikaya (Huawei USA), Hesham
Soliman (Elevate Technologies), Si-Dong Zhang (BJTU NGIRC) for their
valuable comments and suggestions on this memo.
Zhang, Guan et al. Expires January 2, 2008 [Page 12]
Internet-Draft MEMCAST-PS July 2007
9. References
9.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] D. Johnson, C. Perkins and J. Arkko, "Mobility Support in IPv6",
RFC 3775, June 2004.
[3] V. Devarapalli, R. Wakikawa, A. Petrescu, P. Thubert, "Network
Mobility (NEMO) Basci Support Protocol", RFC 3963, January 2005.
[4] S. Deering, W. Fenner, B. Haberman, "Multicast Listener
Discovery (MLD) for IPv6", RFC 2710, October 1999.
[5] R. Vida, L. Costa, "Multicast Listener Discovery Version 2
(MLDv2) for IPv6", RFC 3810, June 2004.
[6] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
August 1989.
[7] Bill Fenner, Mark Handley etc, "Protocol Independent Multicast-
Sparse Mode (PIM-SM): Protocol Specification (Revised) ", RFC
4601, August 2006.
[8] B. Haberman and J. Martin, "Multicast Router Discovery", RFC
4286, December 2005.
9.2. Informative References
[9] R. Koodli, "Fast Handovers for Mobile IPv6", RFC 4068, July
2005.
[10] H. Soliman, C. Castelluccia, K. EI Malki, L. Bellier,
"Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC
4140, August 2005.
[11] Romdhani, I., Kellil, M., Lach, H.-Y. et al., "IP Mobile
Multicast: Challenges and Solutions", IEEE Comm. Surveys, 6(1),
2004.
[12] Thomas C. Schmidt, Matthias Waehlisch, "Multicast Mobility in
MIPv6: Problem Statement and Brief Survey", draft-irtf-mobopts-
mmcastv6-ps-00, May 2007.
Zhang, Guan et al. Expires January 2, 2008 [Page 13]
Internet-Draft MEMCAST-PS July 2007
[13] Petander H., Perera E., Seneviratne A., "Multiple Interface
Handoffs: A Practical Method for Access Technology Independent
Make-Before-Break Handoffs", NICTA Technical Report, July 2005,
http://nicta.com.au/uploads/documents/PA005092_NICTA1.pdf
[14] H. Matsuoka, T. Yoshimura, and T. Ohya, "A robust method for
soft IP handover", IEEE Internet Computing, vol 7, no.2, pp 18-
24, 2003.
[15] F. Xia, B. Sarikaya, "FMIPv6 extension for multicast Handover",
draft-xia-mipshop-fmip-multicast-00, work in progress,
September 2006.
[16] Georgios A. Leoleis et al., "Seamless multicast mobility
support using fast MIPv6 extensions", Computer Communications
(2006), doi: 10.1016/j.comcom. 2006.07.013.
[17] Dong-hee Kwon et al., "Design and Implementation of An
Efficient Multicast Support Scheme for FMIPv6", IEEE INFOCOM,
2006.
[18] Thomas C. Schmidt, Matthias Waehlisch, "Seamless Multicast
Handover in a Hierarchical Mobile IPv6 Environment (M-HMIPv6)",
draft-schmidt-waehlisch-mhmipv6-04, Expired, November 2005.
[19] K. Suh, Y.-J. Suh, "Fast Multicast Protocol for Mobile IPv6 in
the Fast Handovers Environment", IETF Internet Draft, draft-
suh-mipshop-fmcast-mip6-00, Expired January 2004.
[20] Zhang, Hongke et al., "Mobile IPv6 Multicast with Dynamic
Multicast Agent", draft-zhang-mipshop-multicast-dma-03,
work in progress, January 2007.
[21] J. Loughney et al., "Context Transfer Protocol (CXTP)", RFC
4067, July 2005.
[22] I. Miloucheva and K. Jonas, "Multicast Contexe Transfer in
mobile IPv6", draft-miloucheva-mldv2-mipv6-00, June 2005.
[23] Jelger C. and Noel T., "Multicast for Mobile Hosts in IP
Networks: Progress and Challenges", Wireless Communications,
IEEE, Volume 9, Issue 5, pp 58-64, Oct. 2002.
[24] C. Janneteau et al., "IPv6 Multicast for Mobile Networks with
MLD-Proxy", draft-janneteau-nemo-multicast-mldproxy-00, Expired,
April 2004.
Zhang, Guan et al. Expires January 2, 2008 [Page 14]
Internet-Draft MEMCAST-PS July 2007
[25] Kiyong Park et al., "Dynamic Multicast Tree Construction for
NEMO", draft-park-nemo-dyn-multicast-tree-00, Expired, Oct.
2005.
[26] Wei Ding, "Multicast Routing in Fixed infrastructure and mobile
ad hoc wireless networks with a multicast gateway" Available:
http://kunz-pc.sce.carleton.ca/Thesis/WeiThesis.pdf, 2002.
[27] P. Ruiz, A. Skarmeta, "Integrated IP multicast in mobile ad hoc
networks with multiple attachments to wired IP networks", Proc.
of IEEE International Symposium on Personal, Indoor and Mobile
Radio Communications (PIMRC), pp579-583, September 2004.
[28] WANG Liang you et al., "Realization of IPv6 Multicast
Interworking between MANET and Fixed Networks", The Journal of
China Universities of Posts and Telecommunications Vol.10, No.3,
pp30-34 Sep. 2003.
[29] J. Macker (NRL) et al., "Simplified Multicast Forwarding for
MANET", draft-perkins-manet-smurf-02, Work in Progress, IETF
MANET work group, 2006.
[30] Hui Zhang, Hongke Zhang et al., "A New Architecture of
Multicast Interworking between MANET and Fixed Network",
Journal of Internet Technology, vol. (8):1, 2007.
[31] Al-Sulaiman et al., "Cooperative caching techniques for
increasing the availability of MANET certificate authority
services", The 3rd ACS/IEEE International Conference on
Computer Systems and Applications, pp88-94, 2005.
[32] N. Montavount, R. Wakikawa, T. Ernst et al., "Analysis of
Multihoming in Mobile IPv6", draft-ietf-monami6-mipv6-analysis-
02, work in progress, February 2007.
[33] Ernst, T., "Motivations and Scenarios for Using Multiple
Interfaces and Global Addresses", draft-ietf-monami6-
multihoming-motivation-scenario-01, work in progress, Oct. 2006.
[34] C. Ng, T. Ernst, E. Paik, M. Bagnulo, "Analysis of Multihoming
in Network Mobility Support", draft-ietf-nemo-multihoming-
issues-07, work in progress, February 2007.
[35] Zhang Hongke et al., "Multiple Interface Mobile Multicast",
draft-zhang-monani6-multipleif-mcast-00, work in progress, July
2007.
Zhang, Guan et al. Expires January 2, 2008 [Page 15]
Internet-Draft MEMCAST-PS July 2007
Author's Addresses
Hong-ke Zhang, Jian-feng Guan, De-yun Gao, Hua-chun Zhou, Ya-juan Qin
Next Generation Internet Research Center (NGIRC), Beijing JiaoTong
University
Beijing, China, 100044
Phone: +86 10 51685677
Email: hkzhang@bjtu.edu.cn
guanjian863@163.com
gaody@bjtu.edu.cn
hchzhou@bjtu.edu.cn
yjqin@bjtu.edu.cn
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
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.
Zhang, Guan et al. Expires January 2, 2008 [Page 16]
Internet-Draft MEMCAST-PS July 2007
Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Zhang, Guan et al. Expires January 2, 2008 [Page 17]
Tony
guanjian8632@163.com
2007-07-04
_______________________________________________ multimob mailing list multimob@ietf.org https://www1.ietf.org/mailman/listinfo/multimob
- [multimob] New draft: MIPv6 Extensions for Mobile… Tony
- [multimob] New draft: MIPv6 Extensions for Mobile… Tony
- Re: [multimob] New draft: MIPv6 Extensions for Mo… Matthias Waehlisch
- Re: [multimob] New draft: MIPv6 Extensions for Mo… Jong-Hyouk Lee
- Re: [multimob] New draft: MIPv6 Extensions for Mo… Matthias Waehlisch
- Re: [multimob] New draft: MIPv6 Extensions for Mo… Jong-Hyouk Lee
- Re: [multimob] New draft: MIPv6 Extensions for Mo… Behcet Sarikaya