Internet DRAFT - draft-pskim-fho16e-arid
draft-pskim-fho16e-arid
Network Working Group P. Kim
Internet-Draft Korea Polytechnic University
Expires: December 14, 2006 June 15, 2006
Fast Handover for Mobile IPv6 Based IEEE802.16e Wireless Networks
draft-pskim-fho16e-arid-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 December 14, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This draft proposes a new fast handover mechanism for Mobile IPv6
based IEEE 802.16e wireless networks. To implement the proposed
mechanism, the IEEE 802.16e neighbor advertisement message, named
MOB_NBR-ADV, sent periodically by a serving base station (BS) is
assumed to be defined newly by adding a specific subfield to the
available reserved field. In addition, Router Information
Request/Reply messages used in the network layer are defined newly.
The proposed mechanism 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 mechanism 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 current access router
(AR). Moreover, in the proposed mechanism, a mobile node can know
whether it changes AR or BS, which can remove redundant traffic
of the existing one.
Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 1]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Network Configuration and Router . . . . . . . . . . . . . . . 4
4. New Fast handover mechanism . . . . . . . . . . . . . . . . . 4
4.1 New IEEE 802.16e Neighbor Advertisement Message . . . . . . 5
4.2 Router Information Request/Reply Message Formats . . . . . . 5
5. Operation Procedure of Proposed mechanism . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . 9
Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 2]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
1. Introduction
In future Mobile IPv6 based IEEE 802.16e 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 mechanism [1]-[3] has been
proposed for Mobile IPv6 as a way to reduce a L3 handover latency.
In the curren draft, a new fast handover mechanism is proposed to
reduce the L3 handover latency for Mobile IPv6 based IEEE 802.16e
wireless networks where there are several access routers (ARs)
connected by base stations (BSs). To implement the proposed
mechanism, the IEEE 802.16e neighbor advertisement message, named
MOB_NBR-ADV, sent periodically by a serving BS is assumed to be
defined newly by adding a specific subfield to the available reserved
field. Using this message, a mobile node (MN) can know whether it
changes AR or BS. 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, such as ARs' IP
addresses, prefix lengths, and identifiers, 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
mechanism can omit a Router Solicitation for a Proxy (RtSolPr) message
and a Proxy Router Advertisement (PrRtAdv) message used in the
existing one [1]-[3], in real-time communication. This means that the
proposed mechanism 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 mechanism, the MN
can know whether it changes AR or BS while the existing one cannot.
Thus, when the MN changes BS, the proposed mechanism 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 Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 3]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
3. Network Configuration
This draft considers an IEEE 802.16e wireless network where there are
serveral ARs connected by several BSs as shown in Figure 1.
This network configuration is feasible because several access routers
in the IEEE 802.16e wireless network can cover quite wide area where
the MN can moves. These ARs can share each other's network
information, such as ARs' IP addresses, prefix lengths, and
identifiers, and thus may have information table that will be called
the Router Information Table (RIT). Note that the BS can know its AR
identifier (ARID) by a system administrator's presetting.
Note that a change of BS on same subnet does not require a change of
AR because the handover between two BSs (i.e., between BS5 and BS7)
within same subnet can be carried out using link layer mobility
without IP mobility. The handover between two BSs is outside the
scope of L3 handover mechanisms. However, a change of BS between
different subnets (i.e., between BS7 and BS8) require a change of AR
using IP mobility, because the MN would be attaching to a different
subnet. In this case, a L3 handover mechanism 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 BS
or AR. Note that this draft borrows all of the terminology from the
existing mechanism [1]-[3] and the IEEE 802.16e specification [4].
BS1 BS2 BS3 BS4
\ | | /
\ \ / /
\ \ / /
/-----------\
| AR1 |
\-----------/
|
/-------------------------------------\
| IP Backbone |
\-------------------------------------/
| |
/-----------\ /-----------\
| AR2 | | AR3 |
\-----------/ \-----------/
/ | \ / / | \ \
/ | \ / / | \ \
/ | \ / | | | \
BS5 BS6 BS7 BS8 BS9 BS10 BS11 BS12
Figure 1. The 802.16e Wireless Network
4. New Fast Handover Mechanism
In this section, a new fast handover mechanism is proposed for the
Mobile IPv6 based IEEE 802.16e wireless network with serveral access
routers.
Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 4]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
4.1 New IEEE 802.16e Neighbor Advertisement Message (MOB_NBR-ADV)
In order to implement the proposed mechanism, the IEEE 802.16e
neighbor advertisement message[4], named MOB_NBR-ADV, sent
periodically by a serving BS is assumed to be defined newly by
adding a specific subfield "ARID" to the available reserved field.
Since this field uses the available reserved field, other fields
are not affected. Using this new message, the MN can know whether
it changes AR or BS, which will be explained later.
4.2 Router Information Request/Reply Message Formats
In order to implement the proposed mechanism, 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 [5]. 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 Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 5]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
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 Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 6]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
5. Operation Procedure of Proposed Mechanism
The operation procedure of the proposed mechanism is described and
the comparison with the existing one [1]-[3] is shown.
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, ARs' IP
addresses, prefix lengths, and identifiers. 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 MOB_NBR-ADV given by BS, the
MN can know the ARID of its BS from the trigger. Then, the MN checks
this ARID using the RIT cached previously, in order to determine
whether the MN changes BS or AR. If the MN changes BS, 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 mechanism [1]-[3], once a new BS
is detected through the reception of MOB_NBR-ADV containing
the BS identifier (BSID), the MN tries to learn the associated AR
information. Thus, 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. To response to RtSolPr
message, the CAR finds the network information about the NAR
corresponding to BSID 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 BS without change of AR. Then, the MN receives
this reply message and determines whether the MN changes BS or AR.
If the MN changes BS, it continues real-time communication via the
CAR. Otherwise, the MN formulates a NCoA using the prefix of the
NAR's address.
After then, in both the proposed mechanism 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
Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 7]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
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 Mechanism
The proposed mechanism provides several advantages over the existing
one in [1]-[3]. As mentioned in Section 5, the proposed mechanism can
omit RtSolPr/PrRtAdv messages used in the existing one, in real-time
communication. The proposed mechanism 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 mechanism, the MN can know whether it
changes AR or BS, while the existing one cannot. Thus, when the MN
changes BS, the proposed mechanism can remove redundant traffic of
the existing one. However, when there are many ARs on the
IEEE 802.16e 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 mechanism.
7. References
[1] Shim, M., Wood, J., Fu, G. "A Fast Handover Mechanism
For IPv6 Based WiBro System" In: ICA0T2006, 2003.
[2] Jang, H. "Mobile IPv6 Fast Handovers over IEEE 802.16e Networks",
IETF Draft:draft-jang-mipshop-fh80216e-02.txt, Feb 2006.
[3] Koodli, R. "Fast Handovers for Mobile IPv6", IETF RFC 4068, Jul
2005.
[4] IEEE 802.16 TGe Working Document (Draft Standard), "Amendment
for Physical and Medium Access Control Layers for Combined Fixed
and Mobile Operation in Licensed Bands", 802.16e/D12, October 2005.
[5] 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 Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 8]
Internet-Draft Fast Handover for Mobile IPv6 Based IEEE802.16e June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Kim Fast Handover for Mobile IPv6 Based IEEE802.16e [Page 9]
