Internet Draft Seok Joo Koh, ETRI
Internet Engineering Task Force Hee Young Jung, ETRI
Expires May 2004 November 2003
Fast Handover for Regional MIPv4
<draft-sjkoh-mip4-regional-handover-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026 [1].
Internet-Drafts are 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 a "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
This document addresses how to support fast handover in regional MIPv4
networks (Regional Hanover). The proposed regional handover scheme is
designed based on the existing MIPv4 Post-Registration scheme in a
more effective way that the regional MIPv4 features are exploited. In
the proposed regional handover scheme, the GFA acts as an anchor FA
and thus the bi-directional handover tunnels are established between
GFA and nFA, not between oFA and nFA.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 1]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
Table of Contents
1. Introduction..................................................3
2. Terminology...................................................4
3. Overview of F-HMIPv4..........................................5
3.1 Reference Architecture....................................5
3.2 Motivations for F-HMIPv4..................................6
3.3 Design Principles.........................................7
4. F-HMIPv4 Operations...........................................9
4.1 Source Triggered Handover.................................9
4.2 Target Triggered Handover................................12
5. Message Format for F-HMIPv4..................................14
5.1 Handover Request (HRqst).................................14
5.2 Handover Reply (HRply)...................................15
6. Further Considerations.......................................16
6.1 Mobile Triggered Handover in F-HMIPv4....................16
6.2 When will GFA Start Data Forwarding to nFA...............16
6.3 How to Use F-HMIPv4 over HMIPv4 Networks.................16
7. Security Considerations......................................17
8. Acknowledgement..............................................17
9. References...................................................18
Author's Addresses..............................................18
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 2]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
1. Introduction
The MIPv4 [3] could be benefited from its two extensions: Regional
Registration for MIPv4 [4] and Low Latency Handover for MIPv4 [5].
Those two extensional schemes have so far been designed in their own
ways so as to enhance the MIPv4 in the signaling and handover aspects.
It is clear that a combination of those two schemes gives the
harmonized benefit in terms of signaling overhead and latency (by
Regional MIPv4) as well as fast handover (by Low Latency handover).
This document addresses how to support fast handover in regional MIPv4
networks. The existing Low Latency handover scheme [5] provides the
two approaches for fast handover: Pre-Registration and Post-
Registration.
In the regional MIPv4 networks, the Pre-Registration handover scheme
seems to be effectively performed compared to the Post-Registration
scheme. However, in certain environments, e.g., in cases that the L2
handover is completed too earlier or the MN moves too faster, the
Post-Registration scheme MAY be preferred. This document focuses on
how to use the Post-Registration handover scheme over regional MIPv4
networks.
When applying the MIPv4 Post-Registration to Regional MIPv4 networks,
a bi-directional tunnel will be established between two FAs (oFA and
nFA). This simple combination may possibly induce additional
processing overhead for re-tunneling at oAR, since in regional MIPv4
networks all the data traffic is routed via GFA between MN and HA/CN.
This also incurs inefficient usage of network bandwidth.
This document describes 'Regional Handover' (i.e., Fast Handover for
Regional MIPv4). The proposed regional handover scheme is designed
based on the existing MIPv4 Post-Registration in a more effective way
such that the HMIPv4 features could be exploited. In the regional
handover scheme, the GFA will always act as an anchor FA (aFA), in
which all the handover tunnels will be established by GFA.
In the regional handover, it is assumed that the GFA has already
information about the Link Layer Address (LLA) and IP address (CoA) of
the FAs located in its HMIPv4 domain. This document describes the
regional handover operations for the Source Triggered and Target
Triggered handover cases. The proposed regional handover scheme uses
the two types of messages, Handover Request (HRqst) and Handover Reply
(HRply) described [5], without defining any new messages.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 3]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2].
This document uses all the terminology described in the MIPv4 [3],
regional tunneling for MIPv4 [4], and low latency handover for MIPv4
[5] documents.
In addition, this document also uses the following abbreviations
alternately:
HMIPv4:
'Hierarchical Mobile IPv4', which refers to 'Regional Registration
or Tunneling for MIPv4' [4].
FMIPv4:
'Fast Handover for Mobile IPv4', which refers to 'Low Latency
Handover for MIPv4' [5].
F-HMIPv4:
'Fast Handover for Hierarchical MIPv4', which is proposed in this
document.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 4]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
3. Overview of F-HMIPv4
3.1 Reference Architecture
This document addresses how to support fast handover in hierarchical
MIPv4 networks (F-HMIPv4). For this purpose, we consider a
hierarchically configured MIPv4 network, as shown in Figure 1. In the
figure it is assumed that the MNs and FAs (including GFA) in the
network are aware of HMIPv4 functionality specified in [4].
+-------+
| HA |
+-------+
| +----+
| | CN |
| +----+
+-----+ |
| +---+
| |
+-------+
| GFA |
+-------+
| |
| +--------+
| |
+-----+ +-----+
| oFA | | nFA |
+-----+ +-----+
+----+
| MN | -------------->
+----+ movement
Figure 1: A Reference Network for F-HMIPv4
When an MN enters a new HMIPv4 domain, it will perform Home
Registration with HA via GFA by sending Registration Request message.
After that, whenever the MN moves into another FA region, it will
follow the HMIPv4 Regional Registration procedures [4].
If the MN has an active session during the move, it is required to
support fast handover for seamless mobility services, in particular
for the real-time applications, as described in FMIPv4 [5].
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 5]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
3.2 Motivations for F-HMIPv4
It is clear that a combination of FMIPv4 and HMIPv4 gives the
harmonized benefit in terms of signaling overhead and latency (by
HMIPv4) as well as fast handover (by FMIPv4).
FMIPv4 provides the two schemes for fast handover: Pre-Registration
and Post-Registration [5].
The FMIPv4 Pre-Registration seems to be effectively applied in the
HMIPv4 networks, rather than the Post-Registration scheme, since the
MN will perform Pre-Registrations with the GFA not HA in the long
distance. However, the Pre-Registration scheme may not be effective in
certain environment that the L2 handover is completed too earlier or
the MN moves too faster. This document focuses on how to apply or
enhance the Post-Registration over HMIPv4 networks.
The existing FMIPv4 Post-Registration supports the handover using a
bi-directional tunnel, without performing the HMIP regional
registration by MN, and hence no registration messages are required
for handover support. Instead, the Post-Registration utilizes the Bi-
directional Edge Tunnel (BET) between oFA and nFA for fast handover.
In case of using the FMIPv4 Post-Registration in HMIPv4 networks, a
BET will be established between two FAs (oFA and nFA) by the FMIPv4
procedures. This simple combination of FMIPv4 and HMIPv4 may possibly
induce additional processing overhead for re-tunneling at oAR, since
in HMIPv4, all the data traffic is routed via GFA between MN and HA/CN.
This also incurs inefficient usage of network bandwidth.
Figure 2 shows the data flow by the simple integration of FMIPv4 with
HMIPv4. According to the HMIPv4 operations, the data packets sent by
CN/HA will arrive at GFA and then be tunneled to MN over oFA.
CN/HA oFA GFA nFA
| | | |
| MIPv4 | |
|---------------------->| |
| | HMIPv4 | |
| |<----------| |
| | FMIPv4 |
| |---------------------->|
| | | |
Figure 2: Data flows by FMIPv6 (Post) in HMIPv6 networks
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 6]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
When the handover is initiated by an L2 trigger, a BET tunnel will be
established between oFA and nFA according to the FMIPv4 Post-
Registration procedures. To forward the data packets to the nFA by
using the tunnel, the oFA must first intercept those data packets
flowing from the GFA, and then perform the re-tunneling process. This
may be done by adding a new outer IP header of <Source = oFA,
Destination = nFA> to the data packets sent by GFA according to the
HMIPv4 operations.
In the viewpoint of the HMIPv4 operations, the above straightforward
approach has the following disadvantages:
(1) In HMIPv4, the actual data path of the BET between oFA and nFA may
come along the GFA (i.e., oFA-GFA-nFA). Accordingly, the data
packets will flow twice along the path between oFA and GFA. This
induces inefficiency of network bandwidth usage, especially when
those FAs are connected to the network through bandwidth-limited
links.
(2) In this scheme, the handover event of MN from oFA to nFA will not
be informed to GFA, despite that essentially the HMIPv4 regional
tunnel to nFA must be established by MAP. Accordingly, the
benefits of handover anticipation may be depreciated in this
scheme.
(3) From such detouring feature as described above, the overall
handover latency and tunneling overhead may increase during the
handover period. Moreover, it is likely to be difficult to exploit
the advantages of FMIPv4 and HMIPv4 as well.
3.3 Design Principles
3.3.1 Data Flow Optimization for F-HMIPv4
From the observations described above, it is clear that the fast
handover for HMIPv4 needs to be designed by considering the data
transport features of the HMIPv4 (i.e., in HMIPv4, all data packets
are intercepted by GFA and routed to MN.
This document describes Fast Handover for HMIPv4 (F-HMIPv4), in which
the GFA establishes the Bi-directional Tunnel (BT) with nFA for fast
handover instead of oFA. Note that such a tunnel is BT rather than BET,
since it is established between GFA and FA. Actually such a BT will
function as the regional tunnel described in [4].
For this purpose, the FMIPv4 Post-Registration is re-designed in this
document.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 7]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
Figure 3 illustrates the data flows by the F-HMIPv4.
CN/HA oFA GFA nFA
| | | |
| MIPv4 | |
|---------------------->| |
| | | |
| | | F-HMIPv4 |
| | |---------->|
| | | |
Figure 3: Data flows by F-HMIPv4 handover
Before handover, according to the HMIPv4 operations, the data packets
destined to MN are tunneled by GFA. When the F-HMIPv4 handover is
triggered (e.g., by L2 triggers), the GFA will establish a bi-
directional tunnel with the nFA, and then begin to forward the data
packets to the nFA over the tunnel.
When receiving the tunneled data packets from the GFA, the nFA will
de-capsulate and cache the data packets. It then will deliver the
cached data packets to the MN, as done in FMIPv4, when the MN moves
into the nFA region.
3.3.2 Assumptions
The F-HMIPv4 is newly designed based on the existing FMIPv4 Post-
Registration in a more effective manner by exploiting the HMIPv4
features. In F-HMIPv4, the GFA always acts as an anchor FA (aFA) of
FMIPv4, in which all the BET tunnels for fast handover will be
established by GFA.
In F-HMIPv4, it is assumed that the GFA has already information about
the Link Layer Address (LLA) and IP address (CoA) of the FAs located
in its HMIPv4 domain. This ensures that in response to the handover
(or BET establishment) request from an FA, the GFA could identify the
CoA of the FA concerned with the handover.
Basically the F-HMIPv4 operates over the HMIPv4 networks. Accordingly,
it is assumed that the FAs and MNs in the domain are aware of the
HMIPv4 functionality. For handover, the F-HMIPv4 procedures described
in this document apply to the concerned FAs and MN.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 8]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
3.3.3 F-HMIPv4 Messages
The F-HMIPv4 uses the two types of messages, Handover Request (HRqst)
and Handover Reply (HRply), as those defined in the FMIPv4 [5] without
defining any new messages.
The messages are used with different operation procedures for BT
establishment between GFA and nFA, which will be described in the next
section. The two messages are also used differently by the type of L2
triggers (ST or TT) and by the entity generating the message (FA or
GFA).
In this context, the following notations for two message types are
used in this document:
HRqst(s/t/r, FA/GFA) and HRply(s/t/r, FA/GFA),
where s, t, and r represent ST, TT, tunnel removal or renewal,
respectively, and also the FA or GFA means that the corresponding
message is transmitted by FA or GFA, respectively.
To indicate who generates the message, a new flag F is added to the
HRqst and HRply messages defined in FMIPv4 [5]. The detailed message
format will be discussed in Section 5.
4. F-HMIPv4 Operations
In this section, we describe the F-HMIPv4 operations for the Source
Triggered and Target Triggered handover cases. The Mobile Triggered
handover is discussed in Section 6.
It is assumed that the MNs and FAs located in the domain are aware of
the HMIPv4 and also F-HMIPv4 described in this document.
It is assumed in F-HMIPv4 that that the GFA already has the
information about the LLA and CoA (IP address) for each FA located in
the HMIPv6 domain. When an MN enters a new HMIPv4 domain and moves
around in the domain, it will activate the home and regional
registration procedures defined in HMIPv4 [4].
If the MN has an active session and moves to the other FA in the
domain, then the F-HMIPv4 applies for supporting fast handover.
4.1 Source Triggered Handover
In this section, we describe the F-HMIPv4 operations for the Source
Triggered handover. Figure 4 shows overall operations for Source
Triggered F-HMIPv4 handover.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 9]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
+------+
+--->| GFA |<---+
| +->+------+ |
2) HRqst(s,FA) | | | 3) HRqst(s,GFA)
5) HRply(s,GFA) | |6) Redirect | 4) HRply(s,FA)
| | Request |
v | v
1) L2-ST ~~~> +------+ +------+
| oFA | | nFA |
6) L2-LD ~~~> +------+ +------+ <~~~ 7) L2-LU
^ ^
old L2 | | new L2
+-----+ +-------+
| |
| |
V V
+-------+ movement
7) L2-LU ~~~> | MN | --------->
+-------+
Figure 4: Source Triggered Handoff
The general idea behind the Source Triggered handover procedure is
that the oFA provides GFA with the same information it would have
obtained via an L2-ST, and then the GFA establishes a BT with nFA in
order to move the BET to nFA. When the L2 handover is complete (by L2-
LD), oFA sends an HRqst(r,FA) to GFA so as to terminate the previous
BET.
The following describes the process of the Source Triggered F-HMIPv4
handover. The numbered items refer to steps in Figure 4.
1) The oFA receives an L2-ST that contains the MN's L2 address (LLA)
and an IP address or LLA (that can be mapped to IP address) for
nFA.
2) The oFA sends HRqst(s,FA) to GFA for handover request, which
contains the MN's home IP address (HoA), the GFA IP address, an
LLA for the nFA, and an LLA containing the MN's L2 address.
3) Upon receipt of the HRqst(s,FA), the GFA gets the IP address
(CoA) of nFA from its pre-configured mapping table (which must
always maintain the mapping between LLA and CoA for all the nFAs).
The GFA then tries to establish a BT with nFA by sending
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 10]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
HRqst(s,GFA) to nFA. The HRqst(s,GFA) contains the MN's home IP
address (HoA) and an LLA containing the MN's L2 address.
4) In response to HRqst(s,GFA), the nFA sends HRply(s,FA) to GFA for
BT establishment. The HRply(s,FA) contains a code indicating that
the tunnel is successfully established. The nFA is ready to
receive and buffer the data packet from GFA over the BT.
5) Upon receipt of HRply(s,FA), the GFA sends HRply(s,GFA) to oFA,
which contains a code indicating that a BT has been successfully
established.
6) Once the L2 handover is underway and the MN gets disconnected at
L2 (by L2-LD), the oFA will request the GFA to start the tunnel
with nFA by sending an indication message explicitly such as ICMP
Redirect Request (See 6.2 for further discussion).
7) Completion of L2 handover is signaled by an L2-LU trigger at nFA
and/or MN. Then the nFA delivers the buffered data packets to the
MN. From then the nFA provides the data delivery service to the
MN. The MN either defers or initiates HMIP registration when it
receives the L2-LU, which will be discussed in Section 6.
Based on the description above, Figures 5 shows the timing diagram for
Source Triggered (L2-ST) F-HMIPv4 handover.
MN oFA GFA nFA
| | | |
| L2-ST ~~~~~>| | |
| | HRqst(s,FA) | |
| |------------->| HRqst(s,GFA) |
| | |--------------->|
| | |<---------------|
| |<-------------| HRply(s,FA)|
| | HRply(s,GFA)| |
| | | |
| L2-LD ~~~~~>|Redirect Request |
| |------------->| |
| | | L2-LU ~~~~~>|
|<---------------------------------------------->|
| MN's traffic | | |
Figure 5: Source Triggered F-HMIPv6 Timing
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 11]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
4.2 Target Triggered Handover
This section describes the F-HMIPv4 operations for the Target
Triggered handover. Figure 6 shows overall operations for Target
Triggered F-HMIPv4 handover.
+------+
+--->| GFA |<---+
| +->+------+ |
3) HRqst(t,GFA) | | | 2) HRqst(t,FA)
4) HRply(t,FA) | | 6) Redirect | 5) HRply(t,GFA)
| | Request |
v | v
+------+ +------+ <~~~ 1) L2-TT
| oFA | | nFA |
6) L2-LD ~~~> +------+ +------+ <~~~ 7) L2-LU
^ ^
old L2 | | new L2
+-----+ +-------+
| |
| |
V V
+-------+ movement
7) L2-LU ~~~> | MN | --------->
+-------+
Figure 6: Target Triggered Handoff
In the Target Triggered handover, the nFA provides GFA with the
information that would have obtained via an L2-TT. Then the GFA gets
the information on MN (such as its HoA and LLA) for BT establishment
from the oFA, as shown as Steps 2 to 5 of Figure 6. The remaining
procedures (Steps 6 and 7) are identical to those for Source Triggered
handover.
The following describes the process of Target Triggered F-HMIPv4
handover for Steps 1 through 5.
1) The nFA receives an L2-TT that contains the MN's L2 address (LLA)
and an IP address or LLA (that can be mapped to IP address) for
oFA.
2) The nFA sends HRqst(t,FA) to GFA for handover request, which
contains the MN' home IP address (HoA), the GFA IP address, an
LLA for the oFA, and an LLA containing the MN's L2 address.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 12]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
3) Upon receipt of the HRqst(t,FA), the GFA checks the IP address
(CoA) of oFA from its pre-configured mapping table. The GFA then
send HRqst(t,GFA) to oFA so as to get the information about MN's
home IP address (HoA) and an LLA containing the MN's L2 address.
4) In response to HRqst(t,GFA), the oFA sends HRply(t,FA) to GFA,
which contains the information for BET establishment.
5) Upon receipt of HRply(t,FA), the GFA sends HRply(t,GFA) to nFA,
which contains a code indicating that the handover request has
been successfully handled. The nFA is now ready to receive and
buffer the data packet from GFA over the BT.
Based on the description above, Figures 7 shows the timing diagram for
Target Triggered (L2-TT) F-HMIPv4 handover.
MN oFA GFA nFA
| | | |
| | | L2-TT ~~~~~>|
| | HRqst(t,GFA) |<---------------|
| |<-------------| HRqst(t,FA) |
| |------------->| |
| | HRply(t,FA) |--------------->|
| | | HRply(t,GFA) |
| | | |
| | | |
| L2-LD ~~~~~>|Redirect Request |
| |------------->| |
| | | L2-LU ~~~~~>|
|<---------------------------------------------->|
| MN's traffic | | |
| | | |
Figure 7: Target Triggered F-HMIPv6 Timing
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 13]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
5. Message Format for F-HMIPv4
The F-HMIPv6 uses two types of messages: HRqst and HRply. They have
the same message format as FMIPv4 [5] without defining any new message
type. Instead, a new flag bit 'F' is added in the message so as to
indicate the entity (such as FA or GFA) generating the concerned
message. The messages will be differently handled, depending on the
flags indicating the L2 trigger type (s or t) and the entity
generating the message (FA or GFA).
5.1 Handover Request (HRqst)
Figure 8 shows the HRqst message format, in which a new flag 'F' is
added to that defined in FMIPv4 [5]. This is a Mobile IP message
carried on UDP (destination port 434) [3]. The UDP header is followed
by the fields below.
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 |H|N|R|M|G|T|B|F| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address (HoA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 8: Handover Request Message
Type TBD (Handover Request) as in [5]
H,N,R,M,G,T,B As defined in [5].
F Flag to indicate the entity generating this
message. If set to '0', it represents that this
message is sent by FA. If otherwise set to '1',
this is sent by GFA.
Lifetime As defined in [5].
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 14]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
MN Home Address As defined in [5].
GFA Address IP address of GFA
Identification As defined in [5].
Extensions The message MUST include an LLA containing the
MN's L2 address and an L2 address that can be
mapped to an IP address for the oFA or nFA,
appropriately as described in the F-HMIPv4
operations of Section 4. This message MUST also
contain the FA-FA Authentication Extension for
security purpose.
5.2 Handover Reply (HRply)
Figure 9 shows the HRply message format, in which a new flag 'F' is
added to that defined in FMIPv4 [5].
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 |H|N|R|M|G|T|B|F| Reserved | Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN Home Address (HoA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| GFA Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ Identification +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extensions ...
+-+-+-+-+-+-+-+-
Figure 9: Handover Reply Message
Type TBD (Handoff Reply), as in [5]
Code A value indicating the result of the corresponding
Handover Request (HRqst)
The remaining fields (including the flag 'F') are applied in the same
way as defined in the HRqst message.
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 15]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
6. Further Considerations
6.1 Mobile Triggered Handover in F-HMIPv4
Basically the F-HMIPv4 operates in the network-initiated fashion by
using Source or Target Trigger. If a Mobile Trigger (MT) is supported,
it may be used for MN to request the oFA that the Source Triggered
handover is initiated. Such a triggering or requesting message may be
newly defined in the L2 or L3 level, which is for further
investigation.
Alternatively, the MT may be used for triggering the FMIPv4 Pre-
Registration process as defined in [5]. In this case, the FAs and MNs
in the HMIPv4 domain are required to be aware of both FMIPv4 and F-
HMIPv4.
6.2 When will GFA Start Data Forwarding to nFA
By the F-HMIPv4 operations described in Section 4, the GFA establishes
a BT with nFA. After that, the GFA will start tunneling packets using
the BT to nFA, when receiving the ICMP Redirect Request message from
oFA indicating that the MN has disconnected. Instead of ICMP Redirect
message, the HRqst(r,FA) MAY be used for such indication, which is for
further investigation.
As another option, the GFA MAY start tunneling packets using the BT to
nFA as soon as establishing the BT with nFA, that is, after receiving
the HRply(s,FA) from the nFA in the Source Triggered handover case, or
after sending the HRply(s,GFA) to nFA for the Target Triggered
handover case.
6.3 How to Use F-HMIPv4 over HMIPv4 Networks
The F-HMIPv4 operates over HMIPv4 networks. Accordingly, the MN may
perform the HMIPv4 Regional Registration when it enters a new FA
region, independently of the F-HMIPv4 operations described in this
document.
In HMIPv4 [4], the GFA maintains the 'Visitor Entry List' that
includes the following fields for each MN:
o Current CoA of the MN
o Remaining Lifetime of the Regional Registration
On the other hand, by F-HMIPv4, GFA will keep the following fields:
o nFA CoA of the MN
o Remaining Lifetime of the Lifetime of the BT
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 16]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
Depending on the design of F-HMIPv4 with HMIPv4, when the GFA obtains
a new CoA (nFA CoA) of MN, and starts the data forwarding to the BT,
we have the following two choices for maintenance of the 'Visitor
Entry List':
(1) GFA updates the corresponding fields of 'Visitor Entry List'.
That is, the information by Regional Registration is handled in
the same as that by the F-HMIPv4 handover.
(2) GFA adds the information on BT for handover and maintains it
additionally. That is, the information by Regional Registration
is handled differently from that by the F-HMIPv4 handover.
It is for further study which one is a better choice.
7. Security Considerations
The security issues of F-HMIPv6 are basically in line with those of
HMIPv6 [4] and FMIPv4 [5].
8. Acknowledgement
The Authors would like to give special thanks to the following people
for their valuable comments and discussion for enhancing the F-HMIPv4.
Sung Han Kim (ETRI)
Jun Seob Lee (ETRI)
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 17]
INTERNET DRAFT Fast Handover for Regional MIPv4 November 2003
9. References
[1] S. Bradner, "The Internet Standards Process -- Revision 3", BCP,
RFC 2026, October 1996.
[2] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP, RFC 2119, March 1997.
[3] C. Perkins, et al., "Mobility Support in IPv4", RFC 3344, August
2002.
[4] E. Gustafsson, et al., "Mobile IPv4 Regional Registration", draft-
ietf-mobileip-reg-tunnel-07, October 2002.
[5] K. Malki, et al., "Low Latency Handoffs in Mobile IPv4", draft-
ietf-mobileip-lowlatency-handoffs-v4-05, June 2003.
Author's Addresses
Seok Joo Koh
sjkoh@etri.re.kr
Protocol Engineering Center, ETRI
Hee Young Jung
hyjung@etri.re.kr
Protocol Engineering Center, ETRI
Koh and Jung <draft-sjkoh-mip4-regional-handover-00.txt> [Page 18]