Internet DRAFT - draft-pskim-mipv6-fasthandover
draft-pskim-mipv6-fasthandover
Network Working Group P. Kim
Internet-Draft Korea Polytechnic University
Expires: April 12, 2006 Oct 13, 2005
A Fast Handover Scheme for Mobile IPv6 Based Wireless Networks
draft-pskim-mipv6-fasthandover-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 April 12, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This draft proposes a new fast handover scheme for Mobile IPv6 based
wireless networks. To implement the proposed scheme, the beacon
message used in L2 is defined newly by adding a specific subfield to
the capability information field. In addition, Router Information
Request/Reply messages used in L3 are defined newly. The proposed
scheme provides the faster acquisition of new access router's network
information than the existing one, which might be advantageous for
the low handover latency. In addition, the proposed scheme might
reduce amount of traffic in comparison with the existing one, which
might be remarkable when there are many mobile nodes that are now
connecting to current access router. Moreover, in the proposed
scheme, a mobile node can know whether it changes access router or
access point, which can remove redundant traffic of the existing one.
Kim A Fast Handover Scheme for Mobile IPv6 [Page 1]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Network Configuration and Router Information Table . . . . . . 4
4. New Fast handover Scheme . . . . . . . . . . . . . . . . . . . 4
4.1 Beacon Message Format . . . . . . . . . . . . . . . . . . . 4
4.2 Router Information Request/Reply Message Formats . . . . . . 5
5. Basic Operation Procedure of Proposed Scheme . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10
Kim A Fast Handover Scheme for Mobile IPv6 [Page 2]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
1. Introduction
In future Mobile IPv6 based wireless networks, the need to
communicate efficiently on the move and to minimize to packet loss
caused by a handover is becoming increasingly important because a
handover latency would be unacceptable for real-time Internet
services. Thus, in recent, a fast handover scheme [1]-[3] has been
proposed for Mobile IPv6 as a way to reduce a L3 handover latency.
In this draft, a new fast handover scheme is proposed to reduce the
L3 handover latency for Mobile IPv6 based wireless networks where
there are several access routers (ARs) connected by access points
(APs). To implement the proposed scheme, the beacon message used in
L2 is defined newly by adding a specific subfield to the existing
reserved field. Using this message, a MN can know whether it changes
AR or AP. In addition, Router Information Request/Reply messages
used in L3 are defined newly. Using these messages, the MN can
acquire network information about all ARs in ESS, such as ARs' IP
addresses, prefix lengths, and identities, which is performed once
only at the booting time and isn't performed in real-time
communication. In real-time communication, this network information
allows the MN to formulate a new care-of address and to be able to
communicate immediately when the MN changes its point of attachment
from the current AR (CAR) to the new AR (NAR). That is, the proposed
scheme can omit a Router Solicitation for a Proxy message and a Proxy
Router Advertisement message used in the existing one [1]-[3], in
real-time communication. This means that the proposed scheme provides
the faster acquisition of NAR's network information than the existing
one, which might be remarkable for low L3 handover latency. In
addition, the omission of above two messages might reduce amount of
traffic when there are many MNs that are now connecting to the CAR.
Moreover, in the proposed scheme, the MN can know whether it changes
AR or AP while the existing one cannot. Thus, when the MN changes AP,
the proposed scheme can remove redundant traffic of the existing one.
2. Requirements
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 [RFC2119].
Kim A Fast Handover Scheme for Mobile IPv6 [Page 3]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
3. Network Configuration and Router Information Table
This draft considers an IEEE 802.11 wireless network where there are
serveral access routers (ARs). All access points (APs) connected to
ARs and mobile nodes (MNs) are considered to belong to the same
Extended Service Set (ESS), and thus have same ESS identity (ESSID).
For example, buildings such as offices, banks and hospitals can be
considered. These buildings have several floors where there is one AR
for each floors. Mobile hosts such as laptop computers and handheld
PCs used by resident people within the building are considered as
MNs. Usually, these MNs would not go out the building, but would move
within the building. As shown in [1]-[3], all ARs in this wireless
network share each other's network information, such as ARs' IP
addresses, prefix lengths, and identities, and thus may have
information table that will be called the Router Information Table
(RIT). Note that the AP can know its AR's identity (ARID) by a system
administrator's presetting.
Note that a change of AP on same subnet does not require a change of
AR because AR is link-layer reachable from the MN connected to any
APs. This case is outside the scope of L3 handover schemes. However,
a change of AP between different subnets require a change of AR,
because the MN would be attaching to a different subnet. In this
case, a L3 handover scheme would need to be invoked in order to
provide low handover latency between the two ARs. Therefore, it
should be required to know whether the MN changes AP or AR. Note that
this draft borrows all of the terminology from the existing scheme
[1]-[3] and the IEEE 802.11 specification [4].
4. New Fast handover Scheme
In this section, a new fast handover scheme is proposed for the
Mobile IPv6 based IEEE 802.11 wireless network with serveral access
routers. Firstly, Router Information Request/Reply messages are
defined newly to implement the proposed scheme. Secondly, the
operation procedure of the proposed scheme is described and the
comparison with the existing one [1]-[3] is shown. Lastly, several
advantages of the proposed scheme over the existing one is described.
4.1 Beacon Message Format
In order to implement the proposed scheme, the beacon message defined
recently in [5] is used. The beacon message contains information
such as timestamp, beacon interval, capability information, SSID, etc
[4]. In [5], the capability information field is modified by adding
the specific subfield "ARID". Since this field uses the existing
Kim A Fast Handover Scheme for Mobile IPv6 [Page 4]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
reserved field, other fields are not affected. Using this beacon
message, the MN can know whether it changes AR or AP, which will be
explained later.
4.2 Router Information Request/Reply Message Formats
In order to implement the proposed scheme, Router Information
Request/Reply messages used in L3 are defined newly. These messages
are made from the Internet Control Message Protocol for IPv6
(ICMPv6) in [6]. Then, using these messages, the MN performs the
Router Information Request/Reply at its booting time.
Fig. 1 shows the Router Information Request message. This message
is used by the MN to request network information about all ARs from
one of them. The description of each fields are as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.1 Router Information Request Message Formats
o Type : 160 (or any available value)
o Code : 0
o Identifier : MUST be set by the sender so that replies can be
matched to this request.
o Reserved : MUST be set to zero by the sender and ignored by
the receiver.
In the IP header of this message, the source address is an IP address
assigned to the sending interface and the destination address is the
address of the all routers multicast address.
Fig. 2 shows the Router Information Reply message that is used to
acknowledge receipt of a Router Information Request.
Kim A Fast Handover Scheme for Mobile IPv6 [Page 5]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Number of ARs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ARID | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AR's IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . .
. . .
. . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ARID | Prefix Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ AR's IPv6 Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig.2 Router Information Reply Message Formats
o Type : 161 (or any available value)
o Code : 0
o Checksum : The ICMP checksum.
o Identifier : Copied from Router Information Request.
o Number of ARs : The number of ARs' addresses.
o ARID : ARs' identity.
o Prefix Length : The prefix length of AR's address.
o AR's IP Address : IPv6 Address of AR
In the IP header of this message, the source address is an IP address
assigned to the sending interface and the destination address is the
Source Address of an invoking Router Information Request.
Kim A Fast Handover Scheme for Mobile IPv6 [Page 6]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
5. Basic Operation Procedure of Proposed Scheme
The operation procedure of the proposed scheme is described and the
comparison with the existing one [1]-[3] is shown. According to the
specification of IEEE 802.11 wireless network [4], it is required
that the MN sets the ESSID before operation. At the same time, in
this draft, it is required that the MN sets a flag additionally to
determine whether it conforms to the proposed scheme. That is, if
its ESS supports the proposed scheme, the MN sets the flag and
conforms the proposed scheme. Otherwise, the MN will not set the
flag and can conform the existing one in [1]-[3].
When the MN is booting, it sends a Router Information Request
message using all routers multicast address to current subnet in
order to acquire network information about all ARs in ESS, ARs' IP
addresses, prefix lengths, and identities. In response to Router
Information Request message, the current AR (CAR) on the current
subnet sends a Router Information Reply message using the RIT.
Then, the MN receives this reply message and caches the RIT in this
reply message. Note that this Router Information Reqeust/Reply is
performed once only at the booting time and thus isn't performed in
real-time communication.
Assume that the MN communicates with the corresponding node (CN).
In real-time communication, when the MN moves, the "trigger" may
arrive from specific L2 events that might determine the need for
handover. In this draft, this trigger itself is not specified in
detail. Since this trigger is based on the beacon message given by
AP, the MN can know the ARID of its AP from the trigger. Then, the
MN checks this ARID using the RIT cached previously, in order to
determine whether the MN changes AP or AR. If the MN changes AP, it
continues real-time communication via the CAR. Otherwise, the MN
finds the new AR (NAR) corresponding to ARID from the RIT, and
formulates a new care-of address (NCoA) using the prefix of the
NAR's address.
On the other hand, in the existing scheme [1]-[3], when the trigger
containing the AP's identity arrives from specific L2 events, the MN
sends a Router Solicitation for a Proxy (RtSolPr) message to the CAR
in order to acquire network information of the NAR in real-time
communication. This message contains the identity of its prospective
AP. To response to RtSolPr message, the CAR finds the network
information about the NAR corresponding to AP's identity from the
RIT, and sends a Proxy Router Advertisement (PrRtAdv) message with
the network information about the NAR to the MN. Note that these
RtSolPr and PrRtAdv are performed even if the MN changes AP without
change of AR. Then, the MN receives this reply message and
determines whether the MN changes AP or AR. If the MN changes AP, it
continues real-time communication via the CAR. Otherwise, the MN
formulates a NCoA using the prefix of the NAR's address.
Kim A Fast Handover Scheme for Mobile IPv6 [Page 7]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
After then, in both the proposed scheme and the existing one, the MN
associates its current CoA (CCoA) with NAR's IP address for
forwarding purposes using a Fast Binding Update (FBU). Then, the CAR
sends a Fast Binding Acknowledgment (FBACK) message to the MN and
the NAR. The FBACK message confirms whether NCoA could be used, only
after which the MN must use NCoA on the new subnet. At this time,
the CAR sends a Handover Initiate (HI) message to NAR, after looking
up the IP address corresponding to ARID supplied by the MN using its
RIT. This FBU/FBACK and HI/HACK allows that packets arriving at the
CAR can be tunneled to the NAR. When the MN has confirmed its NCoA
and then completes the Binding Update procedure with its CN, the MN
continues real-time communication with the CN using NCoA as its
source IP address via the NAR.
6. Advantages over Existing Scheme
The proposed scheme provides several advantages over the existing one
in [1]-[3].
As mentioned in Section 5, the proposed scheme can omit
RtSolPr/PrRtAdv messages used in the existing one, in real-time
communication. The proposed scheme provides the faster acquisition of
NAR's network information than the existing one, which might be
advantageous for the low L3 handover latency. In addition, the
omission of above two messages might reduce amount of traffic in
comparison with the existing one, which might be remarkable when
there are many mobile nodes that are now connecting to the CAR.
Moreover, in the proposed scheme, the MN can know whether it changes
AR or AP, while the existing one cannot. Thus, when the MN changes
AP, the proposed scheme can remove redundant traffic of the existing
one.
However, when there are many ARs on the IEEE 802.11 wireless network,
the size of the RIT may increase. Then, the more memory is required
for the MN to cache the RIT, which may be a weak point of the
proposed scheme.
Kim A Fast Handover Scheme for Mobile IPv6 [Page 8]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
7. References
[1] Kempf, J., Wood, J., Fu, G. "Fast mobile ipv6 handover packet
loss performance: measurement for emulated real time traffic" In:
2003 IEEE Wireless Communications and Networking, 2003.
[2] McCann, P. "Mobile IPv6 Fast Handovers for 802.11 Networks",
IETF Draft:draftietf-mipshop-80211fh-04.txt, Feb 2005.
[3] Koodli, R. "Fast Handovers for Mobile IPv6", IETF RFC 4068, Jul
2005.
[4] ISO/ICE: Wireless LAN Medium Access Control (MAC) and Physical
Layer (PHY) Specifications. ANSI/IEEE Std 802.11, 1999.
[5] IEEE 802.11 MAC and PHY to support InterWorking with External
Networks. IEEE 802.11u PAR, 2005.
[6] Conta, A., Deering, S. "Internet Control message Protocol (ICMP)
for the Internet Protocol Version 6 (IPv6) Specification", IETF
RFC 2463, December 1998
Authors' Addresses
Pyungsoo Kim
Department of Electronics Engineering,
Korea Polytechnic University,
2121 Jungwang-Dong, Shiheung City,
Gyeonggi-Do 429-793
KOREA
Phone: +82 31 496 8413
EMail: pskim@kpu.ac.kr
Kim A Fast Handover Scheme for Mobile IPv6 [Page 9]
Internet-Draft A Fast Handover Scheme for Mobile IPv6 Oct 2005
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 (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kim A Fast Handover Scheme for Mobile IPv6 [Page 10]
