NEMO Working Group H. Ohnishi
INTERNET DRAFT K. Sakitani
Expires: April 2003 Y. Takagi
NTT Corporation
Oct 2003
HMIP based Route optimization method in a mobile network
<draft-ohnishi-nemo-ro-hmip-00.txt>
Status of This Memo
This document is a submission by the mobile-ip Working Group of
the Internet Engineering Task Force (IETF). Comments should be
submitted to the nemo@ietf.org mailing list.
Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
Abstract
In a nested mobile network situation, the packet transfer route
between a correspondent node(CN) and a mobile node(MN) may become
much longer than in the simple Mobile IP case, because packets can
reach endpoints through all of the home agents (HAs) to which the
mobile routers (MRs) and the MN belong. The existing route
optimization function of Mobile IPv6 cannot solve this problem,
because while it can bypass an MN's HA, it cannot skip the MRs' HAs.
Furthermore, there is no route optimization method for communication
nodes without Mobile IPv6 functionality, which are the so-called
local fixed nodes (LFNs) within a mobile network. This draft provides
solutions to achieve route optimization in these situations by using
HMIP technology and proxy Mobile IP functions.
Ohnishi, et al. [Page 1]
Internet Draft HMIP based route optimization Oct 2003
1. Introduction
Combining the existing Mobile IPv6 (MIPv6) [1] and Network Mobility
(NEMO) technology [2] will facilitate mobility for various services.
In both technologies, individual MNs or mobile routers (MRs) belong
to their own home agents (HAs), which can independently provide
mobility to the MNs or MRs. The important point here is that MNs or
MRs may move into a mobile network and become connected to another MR
there, meaning that they will be hierarchically connected to each
other within one mobile network. A typical example is the case of
passengers with terminals (MNs or personal area networks (PANs))
getting on a bus or train providing NEMO service via an MR. This is
called a "nested mobile network." In this situation, the packet
transfer route between a CN and an MN may become much longer than in
the simple Mobile IP case, because the packets can reach endpoints
through all of the HAs to which the MRs and the MN belong. The
existing route optimization function of MIPv6 cannot solve this
problem, because while it can skip an MN's HA, it cannot skip the
MRs' HAs. Furthermore, there is no route optimization method for
communication nodes without MIPv6 functionality, which are the so-
called local fixed nodes (LFNs) within a mobile network. This draft
thus provides solutions to achieve route optimization in these
situations.
2. Protocol Overview
2.1. Route optimization bypassing the HAs of MRs
This draft proposes an approach similar to the mechanism specified in
HMIPv6 [3] to shortcut the HAs of MRs. In HMIPv6, by registering the
location of an MN within a local network (LCoA) once to a mobility
anchor point (MAP) and registering the location of the local network
(RCoA) to the MNs' HAs (HA_MNs), the HAs can send packets to the MAP
and it can relay the packets to the MN. The solution given here
applies this hierarchical location management method to a mobile
network in order to hierarchically manage the locations of the
network and the MNs within it. In this approach, an MN registers its
location within the nested mobile network once to a root-MR [6], and
it also registers the location of the nested mobile network (the
root-MR's subnet address) to its HA_MN. This hierarchical series of
registrations enables the HA_MN to shortcut the MRs' HAs (HA_MRs) by
sending packets to the root-MR directly, which then relays the
packets to the MN. Since the HA_MN manages only the location of the
whole nested mobile network, it does not have to manage the movement
of the MN within the network. This approach enables the HA_MN to
optimize the route to the mobile network regardless of the network's
configuration. To describe the proposed method simply, we assume a
two-layer nested mobile network like that shown in Figure 1. HMIP has
Ohnishi, et al. [Page 2]
Internet Draft HMIP based route optimization Oct 2003
two modes, basic and extended. The following explanation applies to
basic mode. The method proposed in this draft can also be used with
HMIP extended mode. The root-MR (MR1) adds an address (CoA_MR1) in
its subnet to its router advertisement (RA) as optional information
by using the MAP option field. The creation of this address is
described in section 5.1. The MN creates its care-of address
(LCoA_MN) based on the RA, which gives the location of the MN in the
mobile network. The MN creates the address, RCoA_MN, by using
CoA_MR1's prefix and its interface ID. It then registers binding
information containing LoA_MN and RCoA_MN with MR1 and binding
information containing RCoA_MN and its MN home address (HoA_MN) with
the HA_MN.
When the HA receives packets for the MN, it can send them directly to
MR1 (via RCoA_MN) by using an IPinIP tunnel. MR1 then encapsulates
the packets for the MN by using another IPinIP tunnel according to
the binding table for HoA_MN and LCoA_MN. The packet transfer route
can thus shortcut HA_MR1 in this manner. In this method, duplicate
IPinIP tunnels do not arise in the core network but only within the
mobile network. The sequence and packet formats are shown in figure
2-4.
Ohnishi, et al. [Page 3]
Internet Draft HMIP based route optimization Oct 2003
____
| |
| CN |
|____|
___|____________________
| |
| |
| Internet |
| |
|________________________|
__|_ __|_
| | access | |
| AR | router | AR |
|____| |____|
______|__ foreign __|_____________ home
link __|_ link
| |
| MR1| MR
|____|
_________|_______ internal
__|__ __|__ link
| | | |
| MN | | MN |
|_____| |_____|
Figure 1 Mobile node visiting a mobile network
Ohnishi, et al. [Page 4]
Internet Draft HMIP based route optimization Oct 2003
MN MR HA_MR HA_MN CN
| | | | |
|RA with MAPopt| | | |
|<-------------| | | |
| | | | |
| BU | | | |
|------------->| | | |
| | | | |
| BA | | | |
|<-------------| | | |
| | | | |
| | BU | | |
|--------------------------------------------->| |
| | | | |
| | BA | | |
|<-------------------------------------------- | |
| | | | |
| | | | |
| IPinIPinIP | | | |
|------------->| IP in IP| | |
| |------------------------------>| |
| | | | IP packet |
| | | |-------------->|
| | | | |
| | | | |
| | | | |
| | | | IP packet |
| | | |<--------------|
| | IP in IP| | |
| |<------------------------------| |
| IPinIPinIP | | | |
|<-------------| | | |
| | | | |
| | | | |
Figure 2 Sequence of packet transmission
Ohnishi, et al. [Page 5]
Internet Draft HMIP based route optimization Oct 2003
From MN to MR
+---------------------------+
|src=LCoA_MN | BU to HA_MN |
|dst=MR | CoA=RCoA_MN |
+---------------------------+
From MR to HA_MN
+-------------+
| BU to HA_MN |
| CoA=RCoA_MN |
+-------------+
From HA_MN to MR
+-------------+
| BA to MN |
| |
+-------------+
From MR to MN
+---------------------------+
|src=MR | BA to MN |
|dst=LCoA_MN | |
+---------------------------+
Figure 3 MIP message (BU/BA between MN and HA_MN) packet
formats
Ohnishi, et al. [Page 6]
Internet Draft HMIP based route optimization Oct 2003
From MN to MR
+-------------------------+-----------+
|src=LCoA_MN |src=RCoA_MN| IP packet |
|dst=MR |dst=HA_MN | |
+-------------------------+-----------+
From MR to HA_MN
+-------------------------+
|src=RCoA_MN | IP packet |
|dst=HA_MN | |
+-------------------------+
From HA_MN to CN
+------------+
| IP packet |
| |
+------------+
From CN to HA_MN
+------------+
| IP packet |
| |
+------------+
From HA_MN to MR
+-------------------------+
|src=HA_MN | IP packet |
|dst=RCoA_MN | |
+-------------------------+
From MR to MN
+-------------------------+-----------+
|src=MR |src=HA_MN | IP packet |
|dst=LCoA_MN |dst=RCoA_MN| |
+-------------------------+-----------+
Figure 4 Data packet formats between MN and CN
When there are more than two MRs above the MN (i.e., a hierarchy of 3
or more layers), all the sub-MRs relay the address of MR1 by using
the MAP option field included in the RA message. The MN registers
binding information containing RCoA_MN and LCoA_MN with MR1, which
can then send packets to the MN via an IPinIP tunnel. Thus, this
method can be applied to a nested multi-layer mobile network
environment containing any number of MRs and an MN. By applying
HMIPv6-based mechanisms and using the root-MR to provide a MAP
function, we have ensured that the proposed method does not require
any modification to HAs, CNs, or MNs. The sequence is shown in figure
Ohnishi, et al. [Page 7]
Internet Draft HMIP based route optimization Oct 2003
5.
MN MR2 MR1 HA_MR1 HA_MR2 HA_MN CN
| | | | | | |
| | RA | | | | |
| |<----------| | | | |
| | | | | | |
| | BU | | | | |
| |---------->| | | | |
| | BA | | | | |
| |<----------| | | | |
| | | BU | | | |
| |------------------------------------>| | |
| | | BA | | | |
| RA |<----------------------------------- | | |
|<-----------| | | | | |
| | | | | | |
| BU | | | | | |
|----------------------->| | | | |
| | | | | | |
| BA | | | | | |
|<-----------------------| | | | |
| | | BU | | | |
|------------------------------------------------------------->| |
| | | | | | |
| | | BA | | | |
|<-------------------------------------------------------------| |
| | | | | | |
| | | | | | |
| IP/IP | | | | | |
|----------->|IP/IP/IP | | | | |
| |---------->| | IP/IP | | |
| | |------------------------------------>| |
| | | | | | IP |
| | | | | |------------>|
| | | | | | IP |
| | | | IP/IP | |<------------|
| | |<------------------------------------| |
| |IP/IP/IP | | | | |
| IP/IP |<----------| | | | |
|<-----------| | | | | |
| | | | | | |
Figure 5 Sequence of packet transmission
Ohnishi, et al. [Page 8]
Internet Draft HMIP based route optimization Oct 2003
2.2. Route optimization shortcutting the HA of the MN
If the MN can execute the standard MIPv6 route optimization function
by sending a binding update message with RCoA_MN and HoA_MN to a CN
after completing the process described in Section 2.1, the CN can
send packets directly to the mobile network (via RCoA_MN) without
using an IPinIP tunnel. MR1 then relays the packets to the MN in the
same manner described previously. In this case, the CN and MN can
communicate without utilizing a route through an HA.
2.3. Combination of HMIPv6 with NEMO
In an actual public network service environment, users and vehicles
usually move around wide areas and pass through multiple local
networks. In this case, HMIPv6 is effective, since it can reduce the
handover times and location management burdens of the HAs, especially
for vehicles with mobile networks. When HMIPv6 is used with NEMO
technology, the proposed route optimization method described in
Section 2.1 becomes more effective, because the MAP can play the role
of the root-MR (MR1). Our proposed method combining HMIPv6 and NEMO
is illustrated in Figure 6.
Ohnishi, et al. [Page 9]
Internet Draft HMIP based route optimization Oct 2003
+-------+
| HA |
+-------+
|
| +----+
| | CN |
| +----+
+-----+ |
| |
| +---+
| |
+-------+
| MAP | RCoA
+-------+
_______________|_______
__|_ __|_
| | access | |
| AR | router | AR |
|____| |____|
______|__ foreign __|_____________ home
link __|_ link
| |
| MR1| MR
|____|
_________|_______ internal
__|__ __|__ link
| | | |
| MN | | MN |
|_____| |_____|
Figure 6 Combination of HMIPv6 with NEMO
The MAP (basic mode) advertises an address on its subnet in an RA,
and MR1 binds its current location (LCoA_MR1) with its RCoA_MR1 and
the list of mobile network prefixes (MNP_MR1). MR1 then sends a
binding update (BU) message containing this binding information,
called BU_MR1, to the MAP. If MR1 becomes aware of the MAP's
existence by detecting the MAP option field in the RA, it relays this
information to the MN within the mobile network. (If no MAP exists in
the local network, MR1 adds its own address in the MAP option field,
as described in Section 2.1.) ThemMobile node creates its own care-
of-address (LCoA_MN) with a mobile network prefix and its RCoA by
using the prefix of the MAP's address and its own interface ID. It
then registers binding information containing LCoA_MN and RCoA_MN
with the MAP (via MN's binding update (BU_MN).
The MAP also binds the information from BU_MN and BU_MR1 by matching
LCoA_MN to the MNP_MR1. The MN also registers binding information
Ohnishi, et al. [Page 10]
Internet Draft HMIP based route optimization Oct 2003
containing RCoA_MN and HoA_MN with the HA_MN. When the HA receives
packets for the MN, it can directly send them to the MAP (via
RCoA_MN) by using an IPinIP tunnel. The MAP then relays them to the
MN by using another IPinIP tunnel, with the routing header option
referring to the binding table for RCoA_MN -> LCoA_MN -> MNP_MR1 ->
LCoA_MR1 stored in the MAP (This mechanism is described in Section
5.4.2.). The packet transfer route can thus shortcut HA_MR1 in this
manner. This mechanism is basically the same as that in the case of a
three-layer nested mobile network, as described in Section 2.2. The
important point here is that an MN in the mobile network does not
have to send a BU to the HA_MN as long as the mobile network moves
within the MAP domain, because the HA_MN manages RCoA_MN as the MN's
location, as created from the MAP's address. This feature contributes
to reducing the location management burden of the HA_MN. The
sequence and packet formats are shown in figure 7-9.
Ohnishi, et al. [Page 11]
Internet Draft HMIP based route optimization Oct 2003
MN MR1 MAP HA_MR1 HA_MN CN
| | RA | | | |
| |<----------| | | |
| | | | | |
| | | | | |
| | BU | | | |
| |---------->| | | |
| | | | | |
| | BA | | | |
| |<----------| | | |
| | | | | |
| | BU | | | |
| |----------------------->| | |
| | | | | |
| | BA | | | |
| |<-----------------------| | |
| RA | | | | |
|<-----------| | | | |
| | | | | |
| BU | | | | |
|----------------------->| | | |
| | | | | |
| BA | | | | |
|<-----------------------| | | |
| | | | | |
| | BU | | | |
|------------------------------------------------->| |
| | | | | |
| | BA | | | |
|<-------------------------------------------------| |
| | | | | |
| | | | | |
| IP/IP/IP | | | | |
|----------->| | | | |
| |IP/IP/IP/IP| | | |
| |---------->| | | |
| | | IP in IP | | |
| | |------------------------>| |
| | | | | IP |
| | | | |---------->|
| | | | | |
| | | | | |
| | | | | |
| | | | | IP |
| | | IP in IP | |<----------|
| | |<------------------------| |
| | IP/IP/IP/IP | | |
| |<----------| | | |
| | | | | |
| IP/IP/IP | | | | |
|<-----------| | | | |
| | | | | |
| | | | | |
Figure 7 Sequence of packet transmission
Ohnishi, et al. [Page 12]
Internet Draft HMIP based route optimization Oct 2003
From MN to MR1
+---------------------------+
|src =LCoA_MN |BU to HA_MN |
|dst =MAP |CoA=RCoA_MN |
| | |
+---------------------------+
From MR1 to MAP
+----------------------------------------+
|src =LCoA_MR1 |src =LCoA_MN|BU to HA_MN |
|dst =MAP |dst =MAP |CoA=RCoA_MN |
| | | |
+----------------------------------------+
From MAP to HA_MN
+--------------+
| BU to HA_MN |
| CoA=RCoA_MN |
| |
+--------------+
From HA_MN to MAP
+--------------+
| BA to MN |
| |
| |
+--------------+
From MAP to MR1
+----------------------------------------+
|src =MAP |src =MAP |BA to MN |
|dst =LCoA_MR1 |dst =LCoA_MN| |
| | | |
+----------------------------------------+
or
+----------------------------------------+
|src =MAP |RH |BA to MN |
|dst =LCoA_MR1 |LCoA_MN | |
| | | |
+----------------------------------------+
Ohnishi, et al. [Page 13]
Internet Draft HMIP based route optimization Oct 2003
From MR1 to MN
+---------------------------+
|src =MAP |BA to MN |
|dst =LCoA_MN | |
| | |
+---------------------------+
or
+----------------------------------------+
|src =MAP |RH |BA to MN |
|dst =LCoA_MN |LCoA_MR1 | |
| | | |
+----------------------------------------+
Figure 8 MIP message (BU/BA between MN and HA_MN) packet formats
Ohnishi, et al. [Page 14]
Internet Draft HMIP based route optimization Oct 2003
From MN to MR1
+----------------------------------------+
|src =LCoA_MN |src =RCoA_MN|Data |
|dst =MAP |dst =HA | |
| | | |
+----------------------------------------+
From MR1 to MAP
+-------------------------------------------------+
|src =LCoA_MR1 |src =LCoA_MN|src =RCoA_MN| Data |
|dst =MAP |dst =MAP |dst =HA | |
| | | | |
+-------------------------------------------------+
From MAP to HA_MN
+---------------------------+
|src =RCoA_MN |Data |
|dst =HA | |
| | |
+---------------------------+
From HA_MN to CN
+------------+
|Data |
| |
| |
+------------+
From CN to HA_MN
+------------+
|Data |
| |
| |
+------------+
From HA_MN to MAP
+---------------------------+
|src =HA |Data |
|dst =RCoA_MN | |
| | |
+---------------------------+
From MAP to MR1
+-------------------------------------------------+
|src =MAP |src =MAP |src =HA | Data |
|dst =LCoA_MR1 |dst =LCoA_MN|dst =RCoA_MN| |
| | | | |
+-------------------------------------------------+
Ohnishi, et al. [Page 15]
Internet Draft HMIP based route optimization Oct 2003
or
+-------------------------------------------------+
|src =MAP |RH |src =HA | Data |
|dst =LCoA_MR1 |LCoA_MN |dst =RCoA_MN| |
| | | | |
+-------------------------------------------------+
From MR1 to MN:
+----------------------------------------+
|src =MAP |src =HA |Data |
|dst =LCoA_MN |dst =RCoA_MN| |
| | | |
+----------------------------------------+
or
+-------------------------------------------------+
|src =MAP |RH |src =HA | Data |
|dst =LCoA_MN |LCoA_MR1 |dst =RCoA_MN| |
| | | | |
+-------------------------------------------------+
Figure 9 Data packet formats
In the combination of HMIPv6 with NEMO, there is another solution in
which each MR can also use its own address as the RcoA (basic mode).
3. Route optimization for LFNs
Since LFNs do not support MIPv6 functionality, the route to an LFN
cannot be optimized. In this section, we describe a method by which
the closest MR can execute the MIPv6 route optimization function as a
proxy MN for an LFN. In the case of communication between an LFN and
an MN, the LFN should provide the functionality of a CN in route
optimization for the MN. Therefore, the MR should be able to perform
proxy functions for both the MN and the CN. Before the MR performs a
proxy function, it should recognize whether the connected device has
a mobility management function (MN/MR) or not (LFN). If the device
does have a mobility management function, then it should perform
route optimization, because it is preferable to distribute the burden
of route optimization management, as well as to conform to the end-
to-end concept, meaning that an MN should be able to determine the
execution of route optimization by itself. There may be several ways
to distinguish an LFN from an MN. One possible solution, which we
apply here, is for the connected device to send a BU request to the
MR if it is an MN. The MR can thus recognize that the device is an
LFN if it does not receive a BU message within a certain period after
connectivity is established. The proposed proxy route optimization
method is illustrated in Figures 10 and 11. When the MR detects the
initial packet transfer to the LFN, it first executes the return
Ohnishi, et al. [Page 16]
Internet Draft HMIP based route optimization Oct 2003
routability (RR) test. If the test is successful, it sends the BU to
the CN, instead of to the LFN. This BU contains binding information
with the LFN address as the HoA and CoA-MR1 as the CoA. When the MR
receives the RR test message sent from the MN to the LFN, it performs
the RR test function and executes route optimization as a proxy CN. A
similar proxy function for Mobile IPv4 was also proposed in MBG [4].
LFN MR HA_MR CN
| | | |
| | | IP packet |
| | |<--------------|
| | IP in IP | |
| |<--------------| |
| IP packet | | |
|<-------------| | |
| | | |
| | | |
| | HOTI | |
| |------------------------------>|
| | HOT | |
| |<------------------------------|
| | COTI | |
| |------------------------------>|
| | COT | |
| |<------------------------------|
| | BU | |
| |------------------------------>|
| | BA | |
| |<----------------------------->|
| | | |
| | IP with RH| |
| |<----------------------------- |
| IP with RH | | |
|<-------------| | |
| IP with HoA | | |
|------------->| IP with HAO | |
| |------------------------------>|
Figure 10 Proxy MN
Ohnishi, et al. [Page 17]
Internet Draft HMIP based route optimization Oct 2003
MN MR1 HA_MR1 HA_MN MN
| IP packet | | | |
|----------->| | | |
| | IP in IP | | |
| |---------->| | |
| | | IP packet | |
| | |----------->| |
| | | | IP in IP |
| | | |----------->|
| | | HOTI | |
| |<------------------------------------|
| | | HOT | |
| |------------------------------------>|
| | | COTI | |
| |<------------------------------------|
| | | COT | |
| |------------------------------------>|
| IP with RH | | | |
|----------->| IP in IP | | |
| |---------->| IP with RH | |
| | |------------------------>|
| | | IP with HAO| |
| | |<------------------------|
| | IP in IP | | |
| |<----------| | |
| | | | |
| IP with HAO| | | |
|<-----------| | | |
| | | | |
Figure 11 Proxy CN
4. Packet format: MAP option message format
This format is defined in the HMIP draft. The most recent version of
the HMIP draft does not include extended mode. The method in this
draft will use the same format as that defined in a future HMIP
draft.
5. Mobile router consideration
5.1. Detecting position in nested NEMO
If an MR receives an RA with a MAP option, it recognizes whether it
is attached to the NEMO or it is in the MAP domain. The MR relays the
MAP option by including it in its own RA. If the MR receives an RA
without a MAP option, it recognizes that it is the root-MR. It thus
sends an RA with a MAP option. In basic mode, the MR includes its CoA
in the MAP option. This CoA is created from the RA's prefix, which is
sent by the access router, or a prefix which has been delegated by
the access router.
5.2. Generating RCoA
Ohnishi, et al. [Page 18]
Internet Draft HMIP based route optimization Oct 2003
The MR generates RCoA when it receives an RA with a MAP option. The
method of generation depends on the status of the "M" flag, which is
described in HMIP [2]. "M" bit ON: the MAP address is used as RCoA
(extended mode) "M" bit OFF: the MAP address's network prefix is used
as RCoA's network prefix. RCoA is generated by combining the prefix
and the interface ID.
5.3. Sending BU
The MR sends a BU to the root-MR. In basic mode, it uses LCoA as the
CoA and RCoA as the HoA in the BU message. In extended mode, the MR
uses LCoA as the CoA and the HoA as the HoA in the BU message. After
registering with the root-MR, it sends the BU to its own HA. This BU
includes RCoA as the CoA and the HoA as the HoA.
5.4. Forwarding packets
5.4.1. From MR to CN
The forwarding method depends on the following rules:
-packets initiated by the MR (not the root-MR):
The packets are encapsulated twice by IP headers. The first (inner)
IP header has RCoA as the source address and the HA's address as
the destination address. The second (outer) IP header has its
own address as the source address and the root-MR's address
as the destination address.
-non IPinIP encapsulated packets:
The packets are encapsulated twice by IP headers.
The first (inner) IP header has RCoA as the source address and
the HA's address as the destination address. The second
(outer) IP header has its own address as the source address and the
root-MR's address as the destination address.
-IPinIP encapsulated packets, where the destination address is that
of the root-MR:
The packets are forwarded to the root-MR by usingIPinIP.
-IPinIP encapsulated packets, where the destination address is the
MR's own address:
The packets are decapsulated (if the packets are multiply
encapsulated packets, decapsulation also occurs multiply).
They are then forwarded according to normal IP routing. If the
packets are care-of test init (COTI), the Care-of Init Cookie and the
source address of the MR are maintained in the root-MR. The root-MR
uses this information to forward the COT when it receives the COT
from the CN.
-IPinIP encapsulated packets, where the destination address is
neither that of the root-MR nor its own address:
Ohnishi, et al. [Page 19]
Internet Draft HMIP based route optimization Oct 2003
The packets are forward to the MR's HA by using an IPinIP tunnel.
5.4.2. From CN to MR
If the number of layers in the hierarchy is less than 2, the root-MR
forwards the packets by using single binding caches, which are
registered by the lower MRs. If the number of layers is more than 3,
the root-MR forwards the packets by using combined binding caches,
which are also registered by the lower MRs. The following procedures
are simply examples; any other procedure that achieves the same
functionality could also be used.
Example of 3-layer nested nemo: MR1, MR2, and MR3 are the root-MR,
the middle MR, and the lowest MR, respectively. mode: HMIP basic
mode MR1's BU includes its RCoA and LCoA and the prefixes belonging
to itself. MR2's BU includes its RCoA and LCoA and the prefixes
belonging to itself.
The packet forwarding procedures in the root-MR are as follows:
1. Receive packets whose destination is MR1's RCoA.
2. Find MR1's LCoA from the binding caches registered by MR1
3. Recognize whether MR1's LCoA does not correspond to
a prefix directly connected to MR3
4. Find whether MR1's LCoA corresponds to a prefix owned by MR2
5. Find MR2's LCoA
6. Forward the packet through MR2's LCoA, MR1's LcoA, and
MR1's RCoA. This forwarding is achieved by using IPinIP or the
routing header.
5.5. Route optimization for LFNs
5.5.1. Identification of node types belonging to the mobile network
If a node sends a Mobile IP message, it is identified as a Mobile-IP-
enabled node. Otherwise, a node is identified as an LFN. This route
optimization function is provided only for LFNs.
5.5.2. Proxy CN function
The MR provides the following functions as a CN proxy:
-receiving COTI, sending COT
-receiving Home test init (HOTI), sending HOT
-receiving BU, sending BA These functions are defined in Mobile IPv6
[1].
5.5.3. Proxy MN function
The MR provides the following functions as an MN proxy:
-receiving COTI, sending COT
-receiving HOTI, sending HOT
-receiving BU, sending BA These functions are defined in Mobile IPv6
[1]
Ohnishi, et al. [Page 20]
Internet Draft HMIP based route optimization Oct 2003
6. HA consideration
HAs do not require any additional functions.
7. Security consideration
7.1. Binding update to HA and MAP
These messages are authenticated by the method defined in MIPv6
[1][5] and HMIP.
7.2. Binding update to root-MR
These messages have to be authenticated by IPsec. The question of how
to establish security associations between lower MRs/MNs and the
root-MR is outside the scope of this document. AAA- and PKI-based
approaches can be applied.
7.3. Proxy MN/CN functions
In these functions, the same CoA is assigned to multiple LFNs and is
not the IP address owned by the LFN. This is something like a Mobile
IPv4 FA CoA. Therefore, the LFN and the MR have to have some security
relationship. The method of setting up this relationship is outside
the scope of this document. The same mechanism implemented with an
access authentication method like an AAA-based approach and PANA can
be applied.
7.4. Extended mode in HMIP
In extended mode, multiple MRs share one CoA. The MAP and root-MR can
not identify COTI from the CoA. Therefore, these nodes have to
maintain a cookie in the COTI message and identify the COT by using
this information. This function does not lead to another security
issue.
In this mode, packets from an HA are decapusulated by the MAP.
Applying IPsec to the data packets is difficult, because the MAP does
not know the key that is shared by the HA and the MN. The HA has to
have a function by which it can use different IPsec Security
Association (SAs) to protect packets between itself and the MAP.
References [1] D. Johnson, C. Perkins and J. Arkko "Mobility Support in
Ohnishi, et al. [Page 21]
Internet Draft HMIP based route optimization Oct 2003
IPv6," Internet Draft, IETF. draft-ietf-mobileip-ipv6-24.txt (work in
progress), June 2003.
[2] V. Devarapalli, R. Wakikawa, A. Petrescu and P. Thubert "Nemo
Basic Support Protocol," Internet Draft, IETF. draft-ietf-nemo-basic-
support-01.txt (work in progress), Sep. 2003.
[3] H. Soliman, C. Castelluccia, K. El-Malki and L. Bellier
"Hierarchical Mobile IPv6 mobility management (HMIPv6)," Internet
Draft, IETF. draft-ietf-mobileip-hmipv6-08.txt, June 2003.
[4] T. Ihara, H. Ohnishi and Y. Takagi "Mobile IP route optimization
method for a carrier-scale IP network," in Proc. IEEE International
Conference on Engineering of Complex Computer Systems, Sep. 2000.
[5] J. Arkko, V. Devarapalli and F. Dupont "Using IPsec to Protect
Mobile IPv6 Signaling between MNs and Home Agents," Internet Draft,
IETF. draft-ietf-mobileip-mipv6-ha-ipsec-06.txt (work in progress),
June 2003.
[6] T. Ernst and H. Lach "Network Mobility Support Terminology,"
Internet Draft, IETF. draft-ietf-nemo-terminology-00.txt (work in
progress), May 2003.
Author's Address
Hiroyuki Ohnishi
NTT Network Systems Laboratories, NTT Corporation
9-11-3 Midori-Cho
Musashino-Shi, Tokyo 180-8585, Japan
Phone: +81 422-59-4132
EMail: ohnishi.hiroyuki@lab.ntt.co.jp
Keisuke Sakitani
NTT Network Systems Laboratories, NTT Corporation
9-11-3 Midori-Cho
Musashino-Shi, Tokyo 180-8585, Japan
Phone: +81 422-59-3874
EMail: sakitani.keisuke@lab.ntt.co.jp
Ohnishi, et al. [Page 22]
Internet Draft HMIP based route optimization Oct 2003
Yasushi Takagi
NTT Network Systems Laboratories, NTT Corporation
9-11-3 Midori-Cho
Musashino-Shi, Tokyo 180-8585, Japan
Phone: +81 422-59-6059
EMail: takagi.yasushi@lab.ntt.co.jp
Ohnishi, et al. [Page 23]