One document matched: draft-zhao-nemo-limitations-ps-00.txt
NEMO WG Y. Zhao
Internet-Draft SH. Huawei Tech.
Intended status: Standards Track K. Lin
Expires: May 22, 2008 W. Zhong
SJTU.
November 12, 2007
Limitations exist in IP mobility support applications
draft-zhao-nemo-limitations-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.
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 May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Zhao, et al. Expires May 22, 2008 [Page 1]
Internet-Draft Limitations of Mobility Solution November 2007
Abstract
There already exist several mobility support solutions and each
solution uses its own method to achieve specific goals.But
different solutions may not work properly when they are combined in
an integrated application environment because network entities have
little information about each other.Specially when PMIP meet with the
Nemo network environment something need to be considered more. This
document describes several limitations on NEMO application and
provides a possible solution.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Current Mobility Support Solutions . . . . . . . . . . . . . . 4
3. Limitations Exist in Current Mobility Solutions . . . . . . . 5
3.1. Overlong Routing When MIPv6 Nodes Entered Mobile
Network . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Mobile Network May Not Operate Correctly under a
Pmipv6 Domain . . . . . . . . . . . . . . . . . . . . . . 5
4. Limitations of Nested NEMO . . . . . . . . . . . . . . . . . . 8
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 11
7. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Consideration . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Zhao, et al. Expires May 22, 2008 [Page 2]
Internet-Draft Limitations of Mobility Solution November 2007
1. Introduction
There already exist several mobility support solutions and each
solution uses its own method to achieve specific goals. IP mobility
support protocols are the basis of other network layer mobility
management solution. Based on MIP, there are other IP mobility
extensions like Proxymipv6 and NEMO which aim to provide mobility
support for mobility nodes which can not manage mobility by
themselves. As different methods were designed for different
applications, one method may not be useful in other application.The
future wireless application environment will most likely be a
combination of different methods. For example a mipv6 node may be a
node within a mobile network maintained by a MR. A MR may enter into
the Proxymipv6 domain.
If network entities have not enough information about the others,
they will treat different entities with only one way. The usage of
network resource may not be efficient, and the quality of service may
not be guaranteed.
o For example, when a MIPv6 node happens to enter a mobile network
maintained by a MR, as MR can't distinguish a MIPv6 node from
fixed nodes, the route of the datagram
o In addition, the route between the MIPv6 node and a correspondent
node is sub-optimised even they perform MIPv6 RO process.
Zhao, et al. Expires May 22, 2008 [Page 3]
Internet-Draft Limitations of Mobility Solution November 2007
2. Current Mobility Support Solutions
There exist several mobility support solutions for Internet
communication. They can be divided into two categories with network
layer solutions and application layer solutions. SIP (Session
initiation protocol) [RFC3261] belongs to application layer solution,
which tries to keep the session by noting the correspondent node the
new access address of the mobile node as quickly as possible. On the
other hand, the network layer solution like IP mobility support
protocol [RFC3344][RFC3775], introduces two types of IP addresses and
home agent to support the movement of MNs. In MIP solutions, the
datagram to a MN is targeted to a fixed address and transferred by
home agent to the current access address of the MN. And network
layer solutions are transparent to upper applications.
The network layer mobility support solutions can also be divided into
single node support solutions and subnet support solution. The
former are IP Mobility Support protocols and PMIPv6
[draft-ietf-netlmm-proxymip6-07],the latter is Network Mobility Basic
Support Protocol [RFC3963]. The network mobility solutions can also
be divided into active mode through which the MN control its own
mobility and passive mode where the MN does not manage the mobility.
The former solutions like IP Mobility Support and the other like NEMO
and Proxymipv6.
Different solutions defined different function entities to perform
specific function. For example, NEMO introduces Mobile Router to
maintain a subnet, provide Internet connections for all nodes within
that subnet. Proxymipv6 defined MAG and LMA to help normal nodes
without IP Mobility Support to have a session unbroken while moving.
Zhao, et al. Expires May 22, 2008 [Page 4]
Internet-Draft Limitations of Mobility Solution November 2007
3. Limitations Exist in Current Mobility Solutions
In the future, the application will more likely be a combined and
compromised solution. In a actual wireless environment there will
have different kinds of mobile nodes. For example, in a PMIPv6
domain, the nodes it serves may be a combination of fixed IPv6 nodes,
MIPv6 hosts and Mobile Router. MIPv6 node may also move into a
mobile network maintained by a mobile router. So some problems may
be encountered like that:
3.1. Overlong Routing When MIPv6 Nodes Entered Mobile Network
NEMO take nodes as fixed nodes which have not the capacity of IP
mobility support. MR encapsulates the datagram of the node within
its subnet, then tunnels the datagram to it's HA, HA deencapsulates
the datagram then transport it to the correspondent node. But for
MIPv6 host, as MR maintained a mobile network, it need not send
bindings to its HA as usual, it at least can reduces the binding
frequency for resource saving. As depicted in Figure 1, because MR
can not distinguish MIPv6 node from fixed nodes, the datagram of
MIPv6 host will also be encapsulated by MR and finally routed to
its HA through two tunnels which is not route efficiently. If MR
and MIPv6 host have some information about each other, route
optimization could take place without much cost.
+---+ +--+ ,,,,, +-----+ +------+ +--+
|MNN|<=====>|MR|<=====>|HA_MR|<=====>|HA_MNN|<----->|CN|
+---+ +--+ ''''' +-----+ +------+ +--+
+---+ +--+ +------+ +--+
|MNN|<----->|MR|<=====>|HA_MNN|<----->|CN|
+---+ +--+ +------+ +--+
Figure 1: Overlong Routing Exists When MIPv6 Node in NEMO
3.2. Mobile Network May Not Operate Correctly under a Pmipv6 Domain
PMIPv6 solution is initially designed to support mobility for single
node and it can support both fixed node and MIP node. Its
architecture is similar to [RFC3775] and it introduces LMA and MAG
for local mobility management, LMA works like a HA and it is
responsible for data transport of fixed nodes in PMIPv6 domain. In
PMIPv6, LMA and MAG build a virtual home network for MIPv6 node so it
will not send bindings to its HA while the network will register to
MN's HA on behalf of MN.
Zhao, et al. Expires May 22, 2008 [Page 5]
Internet-Draft Limitations of Mobility Solution November 2007
But mobile router is a special mipv6 node which has mobile network
prefix option. Without capacity negotiation, pmipv6 domain probably
could not distinguish MR from normal mipv6 hosts. And PMIPv6 domain
could not understand MNP so it will not work properly. For example,
as depicted in Figure 2, when MR1 initiates its IP connection in
PMIPv6 domain, MR1 thinks it is at home and will not register to its
HA, instead, the MAG in PMIPv6 domain will send BU to MR1's HA on
behalf of MR1, but the R bit will not exist in the BU message because
the PMIPv6 domain couldn't distinguish MR from normal MIPv6 hosts.
As a result, the HA of MR1 will not take MR1 as a Mobile Router and
the MR1 might not find out that it actually operates as a normal
MIPv6 host.
+---------------------------+ _-----_ +---------------+
|PMIPv6 | / \ | |
|Domain | | | | |
| +-----+ | Data for MR1 | +-------+ |
| +---+ | MAG |<==========================>|HA of | |
| |LMA| |(AR) |<==========X==X============>|Root MR| |
| +---+ +--A--+ | Data for MNNs | +-------+ |
| | | and MR2 | |
| +------------V------+ | | | | |
| | +---+ | | | | | |
| | NEMO |MR1| | | | | | |
| | +-+-+ | | | | | |
| | | | | | | | Home |
| | +-----+-+---+ | | |IPv4/IPv6| | Network|
| | | | | | | |network | +---------------+
| | +-+-+ +-+-+ +-+-+ | | | |
| | |MR2| |MNN| |MNN| | | | |
| | +---+ +---+ +---+ | | | |
| +-------------------+ | \ /
+---------------------------+ "-----"
Figure 2: MR Might not Work Properly in PMIPv6 Domain When It
Initiates Its Network Access
When MR1 moves into a PMIPv6 domain from foreign network, as depicted
in Figure 3, it will take PMIPv6 domain as its home link and de-
register as [RFC3963] defined. The MAG will send BU to MR1's HA to
continue its IP connection while the BU not containing R flag. Even
if HA continues to forward packets targeted to MNNs to MAG, the MAG
might not send MNN's packets correctly to MR1's HA because MAG
doesn't have information about MNP or the relation between MNP and
MR.
Zhao, et al. Expires May 22, 2008 [Page 6]
Internet-Draft Limitations of Mobility Solution November 2007
+---------------------------+ _-----_ +---------------+
|PMIPv6 | / \ | |
|Domain | | | | |
| +-----+ | | | | +-------+ |
| +---+ | MAG |<===========================|HA of | |
| |LMA| |(AR) |===========X==X============>|Root MR| |
| +---+ +--A--+ | | | | +-------+ |
| | | | | | |
| +------------V------+ | | | | |
| | +---+ | | | | | |
| | NEMO |MR1| | | | | | |
| | +-+-+ | | | | | |
| | | | | | | | Home |
| | +-----+-+---+ | | |IPv4/IPv6| | Network|
| | | | | | | |network | +---------------+
| | +-+-+ +-+-+ +-+-+ | | | |
| | |MR2| |MNN| |MNN| | | | |
| | +---+ +---+ +---+ | | | |
| +-------------------+ | \ /
+---------------------------+ "-----"
Figure 3: MR Might Not Work Properly in PMIPv6 Domain When It Moves
From a Foreign Network
Zhao, et al. Expires May 22, 2008 [Page 7]
Internet-Draft Limitations of Mobility Solution November 2007
4. Limitations of Nested NEMO
NEMO hide the MR's movement to the nodes within its mobile network.
MR looks like a normal access router to the mobile nodes it serves,
while MR looks like a node rather than a router to its access router.
MR can not distinguish MR from normal routers, so a MR may choose a
MR as its access router instead of a fixed router unwisely, as
depicted in Figure 4, which make the mobile network nested and is not
route efficient. Without capacity negotiation, MR can not
distinguish each other and nested mobile network is hard to achieve
route optimization and avoid router loop, as depicted in Figure 5.
+--------+ +-----+
| HA of |<xxxxxxxxxx>|HA of|
|Root MR | | MNN |
+---A----+ +-----+
|x|
|x|
|x|
|x|
+-----+----V--+-----------+ +------+
| |Root MR|<xxxxxx | |Fixed |
| +-------+ X | |Router|
| | +-v-+ | +---+--+
|NEMO +--RA-->|MNN|<-----RA---+
|Domain +---+ |
+-------------------------+
Figure 4: MR might choose a MR as its access router instead of a
fixed one in some application
Zhao, et al. Expires May 22, 2008 [Page 8]
Internet-Draft Limitations of Mobility Solution November 2007
---------- ---------- ---------- ----------
| | | | | | | |
| NEMO 1 |--| NEMO 2 |--| NEMO 3 |--Internet--| Host 1 |
| | | | | | | | |
---------- ---------- ---------- | ----------
| ----------
---------- | | |
| | |----| HA 2 |
| HA 1 |---------| | |
| | | ----------
---------- |
----------
| |
| HA 3 |
| |
----------
Figure 5: Overlong routing exists in nested NEMO basic support
application
Zhao, et al. Expires May 22, 2008 [Page 9]
Internet-Draft Limitations of Mobility Solution November 2007
5. Conclusion
If network entities do not know other's capacity and treat different
kind of entities as the very one, it could not maximize the network
resources and provide good service. Those limits seem to be a big
issue to NEMO application because MR is a different mobile node. On
the other hand, if we want to prompt the route efficiency of mobile
network, potential solutions most likely is based on information the
MRs got. The information for application optimization may be
received directly through AAA, or through the access network.
And in some applications, network entities can get information
required only through messages exchange, then they can perform
specific optimization process.
Zhao, et al. Expires May 22, 2008 [Page 10]
Internet-Draft Limitations of Mobility Solution November 2007
6. Proposed Solution
By inserting an indication bit in router solicitation, MR can tell
the network it's a MR not a MN. On the other hand, MR can insert a
bit in its router advertisement to indicate that it is not a normal
router. Based on this method, MRs can exchange other information to
negotiate a specific RO process for potential NEMO application.
Zhao, et al. Expires May 22, 2008 [Page 11]
Internet-Draft Limitations of Mobility Solution November 2007
7. IANA Consideration
There is no IANA consideration in this document.
Zhao, et al. Expires May 22, 2008 [Page 12]
Internet-Draft Limitations of Mobility Solution November 2007
8. Security Consideration
This document states some limitations when some mobility management
solutions cooperate. In particular, it does not introduce new
security concerns to current architecture.
Optimization for current solutions might introduce new threats, but
it is out of the scope of this document.
Zhao, et al. Expires May 22, 2008 [Page 13]
Internet-Draft Limitations of Mobility Solution November 2007
9. References
[draft-ietf-netlmm-proxymip6-07]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-07 (work in progress),
Nov 2007.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P.
Thubert, "Network Mobility (NEMO) Basic Support Protocol",
RFC 3963, January 2005.
Zhao, et al. Expires May 22, 2008 [Page 14]
Internet-Draft Limitations of Mobility Solution November 2007
Authors' Addresses
Yuankui zhao
Shanghai Huawei Technology
Email: john.zhao@huawei.com
Ke Lin
Shanghai Jiao Tong University
Wentao Zhong
Shanghai Jiao Tong University
Zhao, et al. Expires May 22, 2008 [Page 15]
Internet-Draft Limitations of Mobility Solution November 2007
Full 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.
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.
Intellectual Property
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Zhao, et al. Expires May 22, 2008 [Page 16]
| PAFTECH AB 2003-2026 | 2026-04-24 02:50:49 |