Internet DRAFT - draft-cho-nemo-ro-expected-properties
draft-cho-nemo-ro-expected-properties
NEMO Working Group H. Cho
Internet-Draft T. Kwon
Expires: January 19, 2007 Seoul National University
E. Paik
KT
July 18, 2006
Route Optimization Expected Properties and Performance Metrics for
Nested Mobile Networks
draft-cho-nemo-ro-expected-properties-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.
This Internet-Draft will expire on January 19, 2007.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This memo categorizes the route optimization problem of NEMO and
clarifies the expected properties of the route optimization
protocols. The route optimization can be classified into NEMO
optimization and nested NEMO optimization. Since NEMO basic support
protocol is based on bi-directional tunneling, the packets from the
Cho, et al. Expires January 19, 2007 [Page 1]
Internet-Draft RO expected properties July 2006
CN to the MNN are suffer from inefficient routing all the cases.
This routing inefficiency is getting worse when a number of MRs are
nested. This memo is especially interested in nested NEMO
optimization. To solve the routing inefficiency problem, there were
several proposals. However, those proposals could not be compared or
evaluated properly since there was no consensus on the expected
properties of nested mobile networks. This memo is willing to
suggest the expected properties of nested mobile networks, so as to
help coming route optimization proposals find their strength and
weakness according to the commonly accepted desirable properties.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. NEMO optimization and nested NEMO optimization . . . . . . . . 4
2.1. NEMO optimization . . . . . . . . . . . . . . . . . . . . 4
2.2. Nested NEMO optimization . . . . . . . . . . . . . . . . . 5
3. Mobility awareness to mobile nodes in NEMO . . . . . . . . . . 5
3.1. When we hold the mobility transparency . . . . . . . . . . 5
3.1.1. Reduced signaling . . . . . . . . . . . . . . . . . . 5
3.1.2. Long handoff disruption time . . . . . . . . . . . . . 5
3.1.3. Loose location privacy . . . . . . . . . . . . . . . . 6
3.2. When we discard the mobility transparency . . . . . . . . 6
3.2.1. Flexible route optimization . . . . . . . . . . . . . 6
3.2.2. Reduced handoff disruption time . . . . . . . . . . . 6
3.2.3. Strong location privacy . . . . . . . . . . . . . . . 6
4. Expected properties and Performance metrics . . . . . . . . . 6
4.1. Efficient routing . . . . . . . . . . . . . . . . . . . . 6
4.2. Location privacy . . . . . . . . . . . . . . . . . . . . . 7
4.3. Mobility transparency . . . . . . . . . . . . . . . . . . 7
4.4. Handoff disruption time . . . . . . . . . . . . . . . . . 7
4.5. Inter-NEMO routing . . . . . . . . . . . . . . . . . . . . 7
4.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Relationship among expected properties . . . . . . . . . . . . 8
6. Security consideration . . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Appendix A. Case studies of existing proposals . . . . . . . . . 9
A.1. Access Router Option (ARO) . . . . . . . . . . . . . . . . 10
A.2. Recursive Binding Update (RBU+) . . . . . . . . . . . . . 10
A.3. Reverse Routing Header (RRH) . . . . . . . . . . . . . . . 10
Cho, et al. Expires January 19, 2007 [Page 2]
Internet-Draft RO expected properties July 2006
A.4. Nested Path Info (NPI) . . . . . . . . . . . . . . . . . . 10
A.5. HMIP based route optimization (HMIP-RO) . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . . . 13
Cho, et al. Expires January 19, 2007 [Page 3]
Internet-Draft RO expected properties July 2006
1. Introduction
Mobile IP [1] is the basic solution to provide host mobility whereas
network mobility [2] refers to the concept of collective mobility of
a set of nodes. In the simplest scenario, a mobile network moves as
a single unit with one mobile router (MR) that connects it to the
global Internet.
A mobile network can have a hierarchical structure, e.g. a mobile
network within another mobile network. This situation is referred to
as a nested mobile network. For example, a personal digital
assistant and a mobile phone might be organized together to form a
user's personal area network (PAN). A PAN may travel a vehicle,
which also contains a mobile network of larger scale.
In a nested mobile network, multiple MRs form a tree hierarchy in
which the root MR is called the top-level mobile router (TLMR).
Nested mobile networks exhibit the inefficient routing problem, which
becomes worse in proportion to the number of nested levels in the
hierarchy. This is the so-called pinball routing problem.
To solve the pinball problem, there were several proposals. However,
those proposals could not be compared or evaluated properly since
there was no consensus on the expected properties of nested mobile
networks. This memo is willing to suggest the expected properties of
nested mobile networks, so as to help coming route optimization
proposals find their strength and weakness according to the commonly
accepted desirable properties. All terminologies used in this memo
follow [3].
2. NEMO optimization and nested NEMO optimization
The routing optimization in NEMO context can be divided into NEMO
optimization and nested NEMO optimization.
2.1. NEMO optimization
As the NEMO basic support protocol adopts the tunneling based
mechanism, there exists a routing inefficiency naturally. NEMO
optimization is focused on how the routing path in the NEMO protocol
can be optimized. One possible solution is to adopt mobile IPv6
style route optimization by sending BU to CN. However, this approach
can result in the massively occurred binding update messages at the
same time, so called binding update storm (BU storm) since there will
be many MNNs inside the NEMO. As preventing the BU storm while a
group of nodes are moving was the basic concept of NEMO, mobile IPv6
style route optimization is not desirable. Furthermore, since some
Cho, et al. Expires January 19, 2007 [Page 4]
Internet-Draft RO expected properties July 2006
NEMO optimization schemes might be opposed to the already
standardized NEMO basic support protocol, this memo will not deal
with NEMO optimization.
2.2. Nested NEMO optimization
The nested NEMO optimization does not seek to solve the inefficiency
of the NEMO basic support protocol. In the nested NEMO, the
inefficiency is proportional to the nested level of the NEMO without
any measure. The nested NEMO can have arbitrary levels of nesting.
It is thought that there are two types of nesting: physical nesting
and logical nesting. physical nesting means a NEMO getting into
another NEMO (e.g. a PAN inside a vehicle). On the other hand, the
logical nesting is not assuming the physical containing relation
between the NEMOs. For example, in an area where a NEMO cannot
access to the Internet like a tunnel, the NEMO may be attached to its
neighbor NEMO to access to the Internet. This situation will cause
logical nesting of NEMOs. Therefore, the degree of nesting can be
increased to more than two levels, and nested NEMO optimization
should be achieved for commercial deployment of NEMO. This memo is
especially interested in nested NEMO optimization.
3. Mobility awareness to mobile nodes in NEMO
One of the basic concept of network mobility is the mobiltity
transparency. The mobility transparency means that an MR hides its
movement to the MNNs. The only entity that knows the movement of
NEMO is MR and it aggregate the location registration of underlaying
VMNs and sub-MRs. However, as we take care of the nested NEMO, the
mobility transparency makes the route optimization of nested NEMO too
difficult. Therefore, it is needed to compare the pros and cons
about holding the mobilty transparency.
3.1. When we hold the mobility transparency
3.1.1. Reduced signaling
As the top-level MR only knows the movement of the NEMO, the mobility
transparency will prevent the BU storm while a mass group of nodes
are moving.
3.1.2. Long handoff disruption time
If a route optimization scheme makes a short-cut to the nested
tunnel, the MR should register the current location of nested NEMO as
soon as possible to reduce the handoff disruption time. As the
mobility transparency hinder the fact that it move to the MR, there
Cho, et al. Expires January 19, 2007 [Page 5]
Internet-Draft RO expected properties July 2006
will exist long handoff disruption time.
3.1.3. Loose location privacy
The location privacy means that an MR hides its and thus all MNNs'
current location to the CNs. For an example, in the route
optimization scheme in mobile IPv6, an MN can send a BU to a CN to
let the CN know the current location (CoA) of the MN. As the CN
knows the CoA of the MN, packets toward the MN will be routed
directly to the MN without visiting the HA of the MN. In this case,
the location privacy is neglected for efficient routing. For the
NEMO case, the same rule could be applied.
3.2. When we discard the mobility transparency
3.2.1. Flexible route optimization
As the nested bi-directional tunnel could be skewed or omitted, the
route optimization schemes will have more flexibility.
3.2.2. Reduced handoff disruption time
All the MRs and the VMNs in the NEMO can know the movement of the
whole nested NEMO. It will help the fast location update and the
handoff disruption time will be shorten.
3.2.3. Strong location privacy
Violating both the mobility transparency and the location privacy at
the same time will cause the potential BU storm. When MRs or VMNs
let the CNs know the current point of attachment of the TLMR, if the
MRs and VNNs can know the movement of the TLMR, all MRs and VMNs are
willing to update their location simultaneously.
4. Expected properties and Performance metrics
Besides the mobility transparency and the location privacy mentioned
in the previous section, there are several expected properties and
performance metrics for route optimization schemes. Following
sections will explain about the properties and show there exist
trade-off relationships among those properties.
4.1. Efficient routing
Nested mobile networks exhibit the pinball routing problem. In the
NEMO basic support protocol, each mobile node (MR or VMN) has its own
HA. In the worst case, when a CN sends a packet to the MNN which is
Cho, et al. Expires January 19, 2007 [Page 6]
Internet-Draft RO expected properties July 2006
located at the bottom level of the nested mobile network, the packet
has to visit the HAs of all the MRs. As the pinball routing cause
long latency and packet overhead, how short the routing path is is
important. As this memo is concentrated in only nested NEMO
optimization, the minimum routing path will be triangular routing
(visiting only one HA). The routing efficiency will be measured by
the round trip time (RTT) from CN to MNN. The increasing factor of
RTT as the degree of nesting increases is matter. The constant RTT
will be desirable regardless of the depth of nesting.
4.2. Location privacy
The information about the location of a node (e.g. CoA) is a matter
of privacy, and ideally should not be exposed to a non-administrative
domain (e.g. a CN). However, the location privacy is not mandatory,
since the mobile IPv6 protocol already permits a binding update to
the CN for the route optimization. As many entities involved in the
routing know the location of a destination node, the routing path can
be shorten, however the location information might be abused by
malicious entity.
4.3. Mobility transparency
The NEMO basic support protocol uses a bi-directional tunnel between
the HA and the MR to keep MNNs from sending all their location
registrations simultaneously when the MR changes its point of
attachment. This characteristic is called mobility transparency,
which is a desirable feature for the route optimization scheme, as
preventing the BU storm while a group of nodes are moving was the
basic concept of NEMO. The mobility transparency can be measured by
the number of messages per changing its location.
4.4. Handoff disruption time
The handoff latency is composed with the sum of a movement detection
time and a location registration time. The movement detection is
achieved by very fast router advertisement. To shorten the
registration time, each MRs should update their location as soon as
possible. However, reducing the registration time might potentially
cause the BU storm and violate the mobility transparency. Coming
route optimization scheme should take care of both mobility
transparency and seamless handoff.
4.5. Inter-NEMO routing
A inter-NEMO routing and a intra-NEMO routing designate the same
situation ironically in the nested NEMO context since a NEMO can have
another NEMO and a communication between sub-NEMOs is intra-NEMO
Cho, et al. Expires January 19, 2007 [Page 7]
Internet-Draft RO expected properties July 2006
communication as well as inter-NEMO communication. Usually, the
route to be optimized is taken to be the path between the MNN and the
CN, which is outside the nested mobile network. As peer-to-peer
applications proliferate, communication inside a mobile network must
also be considered.
4.6. Security
As the NEMO basic support protocol is based on bi-directional
tunneling between HA and MR, many security concerns are shifted to
the IPsec or secured tunnel mechanism. Once the tunnel established,
all signaling messages and data traffics was safe from malicious
entity. However, in the case of route optimization, most approaches
skew the nested tunneling to shorten the routing path. In this
situation, the security considerations are mostly responsible to
protocol designers. Especially, for the intra-NEMO routing,
intermediate MR laying in the routing path may look into the packets
pass through to redirect their forwarding. The security associations
among entities are necessary.
5. Relationship among expected properties
Mobility | / Location
transparency | / privacy
| /
| /
| /
| /
|/
--------------+----------------
Inter-NEMO /| Security
routing / |
/ |
/ |
/ |
Optimal / | Seamless
routing / | handoff
Figure 1. Relationship among expected properties
As shown in Figure 1, mobility transparency and handoff disruption
time are in relation of tradeoff. "Location privacy and routing
efficiency" and "inter-NEMO routing and security" properties show
contrary characteristics to each other. When designing a new route
optimization scheme, each expected properties should be considered.
A route optimization schemes inclined to one property will lose
Cho, et al. Expires January 19, 2007 [Page 8]
Internet-Draft RO expected properties July 2006
another property. Finding balanced point is essential.
6. Security consideration
We do not consider any security issues in this draft.
7. References
[1] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[2] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert,
"Network Mobility (NEMO) Basic Support Protocol", RFC 3963,
January 2005.
[3] Ernst, T. and H. Lach, "Network Mobility Support Terminology",
draft-ietf-nemo-terminology-05 (work in progress), March 2006.
[4] Ng, C. and J. Hirano, "Securing Nested Tunnels Optimization with
Access Router Option", draft-ng-nemo-access-router-option-01
(work in progress), July 2004.
[5] Cho, H., Paik, E., and Y. Choi, "RBU+: Recursive Binding Update
for End-to-End Route Optimization in Nested Mobile Networks",
LNCS Vol. 3079, pp.468-478, June 2004.
[6] Thubert, P. and M. Molteni, "IPv6 Reverse Routing Header and its
application to Mobile Networks",
draft-thubert-nemo-reverse-routing-header-05 (work in progress),
June 2004.
[7] Na, J., Cho, S., Kim, C., Lee, S., Kang, H., and C. Koo, "Secure
Nested Tunnels Optimization using Nested Path Information",
draft-na-nemo-nested-path-info-00 (work in progress),
September 2003.
[8] Ohnishi, H., Sakitani, K., and Y. Takagi, "HMIP based Route
optimization method in a mobile network",
draft-ohnishi-nemo-ro-hmip-00 (work in progress), October 2003.
[9] Soliman, H., Castelluccia, C., El-Malki, K., and L. Bellier,
"Hierarchical Mobile IPv6 mobility management (HMIPv6)",
draft-ietf-mobileip-hmipv6-08 (work in progress), June 2003.
Appendix A. Case studies of existing proposals
Cho, et al. Expires January 19, 2007 [Page 9]
Internet-Draft RO expected properties July 2006
A.1. Access Router Option (ARO)
ARO [4] is based on the route optimization mechanism of Mobile IPv6,
which is then extended with an access router option. In this
approach, the home agents of the MRs collect binding information from
upper-level mobile routers one by one and deduce the optimal route
recursively. This approach is simple and needs minimum changes in
the existing NEMO basic support protocol. However, since the route
is optimized step by step, the process needs a long convergence time,
which is proportional to the degree of nesting. In ARO, the whole
binding cache in the HA has to be searched recursively to find the
optimal path to the MNN and the number of recursive steps for each
packet is proportional to its degree of nesting. Furthermore, since
the correspondent node also participates in the route optimization
mechanism, location privacy is not guaranteed.
A.2. Recursive Binding Update (RBU+)
RBU+ [5] is a modification of ARO, in which the optimal route is
found when the binding update messages are received by the HAs. This
recursive binding update allows the HAs to maintain the binding
information for the CoA of the TLMR. To handle a packet that arrives
at the TLMR, RBU+ adopts ad hoc network routing inside the mobile
network. MRs can maintain a routing table (proactive) or construct a
routing path on demand (reactive). However, the extensive handoff
disruption caused by a long convergence time, and weak location
privacy, are still problems in RBU+.
A.3. Reverse Routing Header (RRH)
RRH [6] uses new extension headers to inform an MR's home agents of
the nested structure of a mobile network and route the packets
optimally. In RRH, when a packet is sent from an MNN, each
intermediate MR inserts its HoA into the reverse routing header of
the packet. This means that, when a packet arrives at its
destination, that node can determine the optimal route back to the
MNN. RRH has the problem that this header modification needs to be
performed for every outgoing packet.
A.4. Nested Path Info (NPI)
In NPI [7], the binding update message is updated so that it informs
the HAs (of the MRs) of the nested path information. However, when
the TLMR moves to another site, the new nested path information will
be propagated to the whole nested mobile network. After receiving
this new information, every MR and VMN in the nested mobile network
will send BUs at the same time; this may cause binding update storm.
Cho, et al. Expires January 19, 2007 [Page 10]
Internet-Draft RO expected properties July 2006
A.5. HMIP based route optimization (HMIP-RO)
HMIP-RO [8] borrows the concept of a mobility anchor point (MAP) from
Hierarchical MIPv6 [9], and uses it to separate routing between the
CN and the MAP (outside the NEMO) and routing inside the NEMO.
HMIP-RO uses a modified version of HMIPv6 to propagate MAP
advertisement messages. So an MR has two care-of addresses, as it
would in HMIPv6 by listening to the MAP advertisement and router
advertisement messages; one is the regional CoA from the MAP and
another is the on-link CoA from its closest MR. By informing the HA
of the MR of the regional CoA and the MAP of the on-link CoA,
respectively, packets for the MR can be routed via the MAP. However,
when the MR moves to the domain of another MAP, a similar problem may
occur with NPI
Cho, et al. Expires January 19, 2007 [Page 11]
Internet-Draft RO expected properties July 2006
Authors' Addresses
Hosik Cho
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9147
Fax: +82-2-876-7170
Email: hscho@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~hscho/
Taekyoung Kwon
Seoul National University
Multimedia Communications Lab., Seoul National Univ.
Shillim-dong, Kwanak-gu
Seoul 151-744
Korea
Phone: +82-2-880-9105
Fax: +82-2-872-2045
Email: tk@mmlab.snu.ac.kr
URI: http://mmlab.snu.ac.kr/~tk/
Eunkyoung Paik
KT
Advanced Technology Lab. KT
17 Woomyeon-dong, Seocho-gu
Seoul 137-792
Korea
Phone: +82-2-526-5233
Fax: +82-2-526-5759
Email: euna@kt.co.kr
URI: http://mmlab.snu.ac.kr/~eun/
Cho, et al. Expires January 19, 2007 [Page 12]
Internet-Draft RO expected properties July 2006
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Cho, et al. Expires January 19, 2007 [Page 13]