Internet DRAFT - draft-park-nemo-dyn-multicast-tree
draft-park-nemo-dyn-multicast-tree
Network Mobility Kiyong Park
INTERNET-DRAFT Konkuk University
Expires April 18, 2006 Sunyoung Han
Konkuk University
Kicheon Kim
Konkuk University
Jinpyo Hong
Hankuk University of FS
Oct, 2005
Dynamic Multicast Tree Construction for NEMO
draft-park-nemo-dyn-multicast-tree-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.
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
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved
Abstract
Multicast Supporting is one of the most important issues in Network
Mobility Environment, because some killer applications related to
multicast service need to be provided on Next Generation Network.
However, current NEMO technique based on basic support protocol have
got many problems to support the service such as route optimization,
pinball route, mass of multicast problem, etc. the most signficant
problem of the service in NEMO environment is that Mobile Network
cannot be sure that multicasting from parent mobile networks is
possible when the network is nested, Moreover, even though the best
case that all mobile networks have its own multicast router is
supposed and multicasting is working well, the multicast route tree
can not be optimized due to different MNPs of the multicast routers
in each nested network.
This document defines additional functions of each component to
enable dynamic multicast tree construction for multicast service
in Mobile Network.
Expires: April 18, 2006 [Page 1]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
Table of Contents
1. Introduction
2. General Terms
3. Overview
3.1 Applicable Previous Techniques
3.1.1 MIP-BT
3.1.2 MIP-RS
3.2 Current Problems
3.3 Assumption
3.3.1 Multicast Router Functionalities in Mobile Router
3.3.2 Prefix Delegation Mechanism
4. Extensions
4.1 Default Multicast Router Information field
4.2 Router Advertisement Message Source option
4.3 Active Router Extension
4.4 Mobile Router Extension
4.4.1 Router Advertisement Message Propagation.
4.4.2 Multicast Tunnel Construction
5. Operation Flow
6. Conclusion
7. Acknowledgements
8. References
9. Authors
10. Full Copyright Statement
Expires: April 18, 2006 [Page 2]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
1. Introduction
Multicast support is one of the most challengeable issues in mobile
environment. Although basic architectures to support multicasting
on mobile environment based on Mobile IP technology [1] were
suggested. Unfortunately, the architectures are not standard. In
these circumstances, issuing multicast on NEMO [2][3][4] can be
ahead of the times. However, multicasting on NEMO must be
standardized for the purpose of making killer applications and
commercial benefits in Next Generation Networks.
NEMO basic architecture has been faced at fundamental problem of
route optimization called Pinball Route [10]. This problem is getting
critical more and more when the network is nested deeper. This
problem is caused by Bi-directional tunneling and must be solved to
enable multicast service on NEMO too. Fortunately, the solution
was suggested and it is based on Prefix Delegation (PD) Mechanism [5]
in IPv6. Therefore, In this time, multicasting techniques on NEMO
must be reinvestigated.
Because, in NEMO, the entire network moves away. The multicast
router realizes that the network to service multicast disappeared
or it moves away from the service network. In addition to it, when
the mobile networks are nested, multicasting from upper mobile
network may be impossible for the reason of upper network's network
management rules. To support multicast completely in NEMO, all
disturbances stated above must be solved and proper solution must
be created
This memo, to create proper solution of multicasting on
NEMO, explains interoperation among multicast router, mobile
router, active router and some flows to construct route optimized
multicasting model on NEMO
2. Terminology
The keywords "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.
Expires: April 18, 2006 [Page 3]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
3. Overview
3.1. Applicable Previous Techniques
In early Mobile-IP (MIP) technologies, basic architectures such as
MIP-BT (Bidirectional Tunneling) , MIP-RS (Remote Subscription) [7]
and Multicast Proxy Server [8], were suggested to provide
multicast service for Mobile hosts. These techniques can be basic
architectures for mobile network to support multicast service.
3.1.1. MIP-BT (Bidirectional Tunnel)
In MIP-BT, a mobile node in a foreign network receives multicast data
packets from the mobility agent in the home network by bi-directional
tunneling. This approach assumes that the home agent has multicast
router functions or there is a multicast router in the home network.
The home agent intercepts multicast packets that the mobile node used
to receiving, encapsulates and transmits them to the mobility agent
in the foreign network (called 'foreign agent'). When the foreign
agent receives these packets, it decapsulates them and sends to the
local network.
3.1.2. MIP-RS (Remote Subscription)
In MIP-RS, when a mobile node moves to a new network, it sends IGMP
messages to the local network in order to rejoin the multicast group
[6], so that it can receive multicast data packets from the local
multicast router of the foreign network.
3.2. Current Problems
Because NEMO basic support architecture has inherited Mobile IP and
related techniques, many serious problems in supporting multicast in
Mobile IP still exist in NEMO. Major problems are tunnel convergence
problem, mass of multicast problem [9], and route optimization
problem. Furthermore, because NEMO basic support is using bi-
directional tunnel, multicasting on NEMO has the serious weakness
called the pinball route problem, which can be classified into a
route optimization problem.
If MIP-BT is adopted on NEMO, the tunnel convergence problem occurs
and it gives much overhead not only on MRs but also on AR because
they must process many tunnels, while the problem gives some loads
only to AR or mobility agent on pure Mobile IP. Furthermore, the
more networks are nested, the more damages occur in the entire mobile
network.
Expires: April 18, 2006 [Page 4]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
If MIP-RS is adopted on NEMO, MNs in the mobile network can not join
a multicast group, because they don't know where multicast routers
are located. Moreover, their IGMP [6] messages cannot be routed to
a multicast router, because their IGMP messages might not be routed
by the MR's upper router for their different mobile network prefixes.
3.3. Assumption
3.3.1. Multicast Router Functionalities in Mobile Router
Firstly, we must handle the multicast support on a mobile network
itself, otherwise no MNs in mobile network are sure of the reception
of multicast data. Furthermore, lots of tunnels will generate network
congestions in the mobile network and its ascendants as explained in
3.2. these problems cannot be solved until mobile network has a
multicast router or MR has multicast router functions. For above
reasons, we assume that in our method, multicast router functions are
built in MR. if any network which do not want to support multicast
service is exits, it would not have the functions.
3.3.2. Prefix Delegation [PD] Mechanism in IPv6
In NEMO basic support architecture, bi-directional tunnel is used for
a MR to communicate with its home network. But it causes a serious
problem of route optimization, called the pinball route problem. It
happens again in the case of multicasting whenever a mobile network
is nested. To overcome this weakness, we adopt the Prefix Delegation
mechanism. It achieves route optimization of multicast tunnel between
a MR and its HA. That is, multicast tunnels in our method are made
from internet address of the multicast router directly to MR's CoA.
Expires: April 18, 2006 [Page 5]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
4. Extensions
To complete route optimized multicast on NEMO, our method extended
each part of components in mobile network to support multicast.
4.1. Router Advertisement (RA) Message Source option
A new option bit named 'S' indicates where this RA message [11] was
sent from. If this bit is checked, it means the RA message was from
MR, otherwise, AR. <Fig. 1> shows 'S' bit.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cur Hop Limit |M|O|H|S| Res. | Router Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reachable Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
<Fig. 1> Router Advertisement Message with 'S' bit
4.2. Default Multicast Router Information (DmRI) in RA Message
This Information is used for AR's and MR's RA message to carry a
Multicast Router Address Information and it is an optional
extension part of Router Advertisement message [11].
We suggest the type number of this option to 10.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Default Multicast Router Address (128 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<Fig. 2> Optional Extension in RA message
4.3. Active Router Extension
AR may have DmR information, explained above chapter 4.2 in its
configure file. When the AR starts up, it must insert the information
into its RA messages as an optional part and advertise it.
Expires: April 18, 2006 [Page 6]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
4.4. Mobile Router Extension
There are 2 extensions on Mobile Router. The first is RA message
propagation with its newly defined 'S' bit and the second is
multicast tunnel construction when it starts up in Home Network and
it handover to Foreign Network. Note that we supposed multicast
router functions on Mobile Router.
4.4.1. Router Advertisement Message Propagation
MR must keep the DmR information in its buffer, when it read the
information from RA message. And it must insert the information in
its RA messages as an optional part as same method as AR did.
Finally, it must check 'S' bit in its RA message explained in
chapter 4.1. If there is no DmR Information, the MR does not check
'S' bit on RA messages.
4.4.2. Multicast Tunnel Construction
The MR must be able to establish a multicast tunnel (multicast route
tree) with fixed multicast router and re-establish the tunnel with
new multicast router in run-time.
Expires: April 18, 2006 [Page 7]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
5. Operation Flow
When Mobile Network starts up firstly, the MR must keep the DmRI in
its cache, only if the information is retrieved from RA messages.
When the MR received IGMP Group Join messages from its on-link nodes,
it must construct multicast route tree onto its DmR as a parent. There
are two different cases on it. First, It must construct multicast
tunnel with Default Multicast Router it keeps only if the DmRI was
retrieved from 'S' bit not checked RA messages, that means AR's RA
message. Second, It must construct multicast tunnel with upper MR
only if the DmRI was retrieved from 'S' bit checked RA message, that
is upper MR's RA message. In opposite to above, the RA message has
neither 'S' bit nor DmRI, then the MR is in a network which does not
support multicasting. Note that PD mechanism was applied on the
mobile network, thus, the multicast tunnel is established between
MR's CoA and Multicast Router's Native internet address or between
MR's CoA and upper MR's CoA.
<Fig. 3> shows above operation flows.
_________________________
_______ | |
| | | |
| DmR |----| Internet |
|______| | |
* |________________________|
* __|__
* | |
* | AR | Access Router with DmRI
* |____|
* home ______|_____________ RA message with DmRI
* link |
* __|__
***************************| |
| MR | Mobile Router
*******|_____|
* ____|__________ RA message with DmRI
* | | and 'S' bit
* __|__ __|__
* | | | |
******| MR | | MN |
|_____| |_____|
****** Multicast Tree
<Fig. 3> Multicast Tree when MR starts up
Expires: April 18, 2006 [Page 8]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
When Mobile Network detects its movement, at that time, there are two
different cases on it. First case is that the mobile router already
has a multicast route tree with previous DmR or previous upper MR.
Second case is that the network moved without multicast service.
In Second case of it, it is just like the processes that the network
starts up firstly, explained above. But, First case is more complex.
In First case, if the MR detects its movement, it must re-establish
multicast tunnel with the DmR, it keeps, rapidly. Because the DmR is
unique and fixed multicast router information of the previous network
and all multicast data in the network was via the DmR, the
multicast groups the MR want to listen are, clearly, served by the
DmR. Therefore, the multicasting the MR wants is well working
without additional delay only by re-establishing multicast tunnel
with it.
<Fig. 4> shows above operation flows.
_____________________________
| |
| |
| Internet |
| |
|____________________________|
__|__ ___|____ __|__
| | | Prev. | | |
| AR | | DmR | | AR |
|____| |_______| |____|
foreign ___|___ * * ___|________ home link
link | * * |
__|__ * *
| | * *
| MR |******* *
|_____| *
__________|_____ *
| | *
__|___ __|___ *
| | | | *
| MN | | MR |******
|_____| |_____|
****** Multicast Tunnel
<Fig. 4> Multicast Tunnel when MR detects its movement
Expires: April 18, 2006 [Page 9]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
Finally, if the MR read the RA messages in new network multicasting
with previous network's DmR, there are three different cases on it.
First case is RA message does not contain DmRI. Second case is RA
message contains DmRI with 'S' bit, that is the network is nested.
Third case is RA message contains DmRI with no 'S' bit. If the case
is first one, the MR does nothing more, the multicasting is well
working with the DmR in the MR's previous network. If the case is
second one, that is the RA messages was from upper MR, then multicast
tunnel must be re-established with upper MR, the MR must send IGMP
Join messages of all groups it is listening and the MR must update
old DmRI with new one. Finally, If multicast data is detected from
newly established multicast tunnel, destroy previous multicast tunnel
with previous DmR. If the case is third one, then the MR must re-
establish multicast tunnel with new DmR, send IGMP Join messages
of all groups it is listening and update old DmRI with new one.
Finally, if multicast data is detected from newly established
multicast tunnel, destroy previous multicast tunnel with previous
DmR.
<Fig. 5> shows final multicast tunnel created.
_____________________________
_______ | |
| New | | |
| DmR |-----| Internet |
|______| | |
* |____________________________|
* __|__ ___|___ __|__
* | | | Prev.| | |
* | AR | | DmR | | AR |
* |____| |____ _| |____|
* ____|___ foreign ___|________ home link
* | link |
* __|__
* | |
********| MR |******
|_____| *
_________|_____ *
| | *
__|___ __|__*
| | | |
| MN | | MR |
|_____| |_____|
****** Multicast Tree
<Fig. 5> Multicast Tree with new DmRI in new RA message
Expires: April 18, 2006 [Page 10]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
6. Conclusion
This memo examined and analyzed problems of providing multicast
service on NEMO basic support architecture, and the purpose of this
memo is that provides optimized route path for multicasting in NEMO.
As presented in the previous sections, our mechanism eliminates the
complexities of multicast data flows on NEMO environments.
Specifically, in our method,
A. There is no Pinball Route problem of multicast data
B. There is no bi-directional tunnel for multicast data between MR
and its HA
C. Once a MR has provided multicast service in home network, it can
permanently provide multicast service till it is shut down
D. MRs in mobile networks have native route path for multicast data
E. Minimized multicast tree reconstruction delay
This study is a work in progress and need to be improved by any
other individual or commercial issues. Specially, this work can be
adopted on Next Generation Network's Killer Application such as
Mobile Video on Demand, etc. We will add security issue such as
Group Key Distribution Mechanism, etc. And also encourage people who
are interested in this work to contribute this work.
Expires: April 18, 2006 [Page 11]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
7. Acknowledgement
The authors would like to thank people who have given valuable
comments on various Mobile Multicast and Network Mobility issues.
8. References
[1] D. Johnson, C. Perkins, J. Arkko, Mobility Support in IPv6,
RFC 3775, Jun 2004.
[2] Thierry Ernst, Network Mobility Support Goals and Requirements,
Internet Draft, <draft-ietf-nemo-requirements-01.txt>, May 2003.
[3] Thierry Earnst, Hong-You Lach, Network Mobility Support
Terminology, Internet Draft, < draft-ietf-nemo-terminology-
00.txt>, May 2003.
[4] Vijay Devarapalli, Ryuji Wakikawa, NEMO Basic Support Protocol,
RFC 3963, Jan 2005.
[5] T. Kniventon, P. Thubert, Mobile Network Prefix Delegation,
Internet Draft, <draft-ietf-nemo-prefix-delegation-00>, Aug 2005.
[6] W. Fenne, Internet Group Management Protocol, version 2,
RFC2236.
[7] V. Chikarmane et al, Multicast Support for Mobile Hosts Using
Mobile IP: Design Issues and Proposed Architecture, ACM/Baltzer
Mobile Networks and Applications, vol 3, no 4, pp 365-379,
January 1999.
[8] Hee-Sook Shin, Young-Joo Suh, and Dong-Hee Kwon, Multicast
Routing Protocol by Multicast Agent in Mobile Networks,
Proceedings of the Proceedings of the 2000 International
Conference on Parallel Processing, pp 271-278.
[9] Kuang-Hwei Chi, Chien-Chao Tseng and Ting-Lu Huang, A Framework
for Mobile Multicast using Dynamic Multicast Route, The computer
journal, vol 42, no 6, 1999.
[10] Thubert, P., and Molteni, M., Taxonomy of Route Optimization
Models in the NEMO Context, Internet Draft: draft-thubert-nemo-
ro-taxonomy-00, Oct 2002
[11] T. Narten, Neighbor Discovery for IP Version 6 (IPv6), RFC 2461
Expires: April 18, 2006 [Page 12]
INTERNET-DRAFT Dynamic Multicast Tree Construction for NEMO Oct, 2005
9. Authors' Addresses
Kiyong Park
Computer Communication Laboratory,
Department of Computer Engineering, Konkuk University
Hwayang-Dong KwangJun-Gu Seoul Korea
Phone: +82-2-450-3537
Fax: +82-2-444-1548
EMail: kypark@cclab.konkuk.ac.kr
Sunyoung Han
Computer Communication Laboratory,
Department of Computer Engineering, Konkuk University
Hwayang-Dong KwangJun-Gu Seoul Korea
Phone: +82-2-450-3537
Fax: +82-2-444-1548
EMail: syhan@cclab.konkuk.ac.kr
Keechoen Kim
Next Generation Internet Communication Laboratory,
Department of Computer Engineering, Konkuk University
Hwayang-Dong KwangJun-Gu Seoul Korea
Phone: +82-2-450-3518
Fax: +82-2-453-3518
EMail: kckim@konkuk.ac.kr
Jinpyo Hong
Computer Communication Laboratory,
Information and Computer Engineering, Hankuk University of FS
Mohyun-Myun Yongin Kyunggi-Do Korea
Phone: +82-31-330-4116
Fax: +82-31-334-3087
EMail: jphong@hufs.ac.kr
10. Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
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 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.
Expires: April 18, 2006 [Page 13]
