Internet DRAFT - draft-gwon-mipshop-efwd-fmipv6
draft-gwon-mipshop-efwd-fmipv6
Network Working Group Youngjune Gwon
draft-gwon-mipshop-efwd-fmipv6-00.txt Alper E. Yegin
Expires: May 23, 2004 DoCoMo USA Labs
Enhanced Forwarding from the Previous Care-of Address
for Fast Mobile IPv6 Handovers (eFWD)
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026. This is an individual
draft for consideration by the Mobileip Working Group.
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
We introduce Enhanced Forwarding from the Previous Care-of Address
(eFWD) for fast handovers in Mobile IPv6. eFWD enables a mobile node
to create and directly control a bi-directional tunnel between the
mobile nodeÆs previous and new subnetÆs access routers subsequent to
a link layer handover. eFWD reduces handover latency by expediting
the mobile nodeÆs movement detection and new subnetÆs access router
discovery via proposed Candidate Access Router Information Discovery
(CARID) method and by eliminating time to acquire a new care-of
address. Main advantage of eFWD is complete removal of link layer
pre-triggers that are extremely complex mechanisms to implement in
wireless technologies other than cellular systems.
Gwon and Yegin Expires May 23, 2004
[Page 2] eFWD November 2003
Table of Contents
1. Introduction....................................................2
2. Terminology.....................................................3
3. Problem Statement and Solution..................................4
4. The Protocol....................................................6
4.1 Overview.....................................................6
4.2 Requirements.................................................8
4.2.1 Control Messages.........................................8
4.2.2 Candidate Access Router Information Discovery (CARID)...13
5. Security Considerations........................................13
6. References.....................................................13
7. Addresses of Authors...........................................14
8. Acknowledgment.................................................14
9. IPR Statement..................................................14
10. Full Copyright Statement......................................15
11. Appendix A û eFWD Performance Evaluation in HoE Testbed.......15
11. Appendix A û eFWD Performance Evaluation in WLAN Testbed......17
1. Introduction
The Mobile IP Working Group has considered low latency and low loss
handover protocols for Mobile IPv6 that can seamlessly support real-
time applications. The standard Mobile IPv6 [1] handover process
reveals numerous problems manifested by time-consuming network
layer-based movement detection, non-optimized time sequencing of
handover procedures, and latency of configuring a new care-of
address. The Fast Mobile IPv6 Handover Protocol is designed to solve
these problems. The current proposal of the fast handover protocol
[2] is based on having link layer information available prior to the
actual handover so that the mobile node and the access routers
should prepare/anticipate for IP handover. In general, the fast
handover protocol tends to impose extra set of functions and
requirements over the link layer known as link layer triggers (L2
triggers) [3].
In this memo, an extension of the fast Mobile IPv6 protocol is
proposed that allows a mobile node to control and initiate the
creation of a bi-directional tunnel between the old and new access
routers immediately after link layer handover has been completed,
namely Enhanced Forwarding from Previous Care-of Address (eFWD). The
eFWD optimizes IP handover latency by eliminating new care-of
address acquisition and by identifying new access router information
in advance. It should be noted that eFWD is free from link layer
pre-triggers.
2. Terminology
Mobile Node (MN)
A Mobile Node is a Mobile IPv6 host capable of moving its point
of attachment to the Internet.
Gwon and Yegin Expires May 23, 2004
[Page 3] eFWD November 2003
Access Router (AR)
An Access Router is the last router between the network and the
mobile node, i.e., the MN has link Layer connectivity to the
Access Router.
Access Point (AP)
A first-hop link layer device between the access router and the
mobile node.
Old Access Router (oAR)
The access router involved in handling a MN's traffic prior to
an L2 Handover.
New Access Router (nAR)
The access router anticipated to be handling a MN's traffic
after completion of an L2 handover.
Old Care-of Address (oCoA)
The care-of address prior to the MN's first movement. In this
memo, it may be reused until the MN determines an appropriate
time to change it, even if the MN changes subnet.
New Care-of Address (nCoA)
The care-of address in the new subnet. In this memo,
configuration with a nCoA does not have to take place
immediately after L2 handover.
Bi-directional tunnel (BT)
A bi-directional tunnel placed between the ARs where the MN
first established its current CoA and a new AR to which the MN
is attached where the CoA would be topologically incorrect if
used. The new AR tunnels packets from the MN and having the
source address as the MN's old CoA to the old AR. The old AR
tunnels packets to the MN and having the destination address as
the MN's old CoA to new AR. The new AR detunnels the MN-
directed packets and sends them over the radio link to the MN
(and hence there is no tunnel overhead on the air link). The
old AR detunnels correspondent node-directed packets and sends
them into the subnet where the old CoA is topologically
correct. BTs allow use of the old CoA without running the risk
of ingress or egress filtering.
Link-layer Handover (L2 Handover)
Movement of a MN's point of layer 2 (L2) connection from one
wireless access point to another. Depending on the L2, an L2
handover may traverse both a wireless and a wired link, or just
a wired link.
Gwon and Yegin Expires May 23, 2004
[Page 4] eFWD November 2003
IP Handover (L3 handover)
The process by which a MN obtains a new CoA from the AR, thus
updating its routing reachability. L3 handover may occur
partially before and partially after L2 handover, or it may
occur entirely after L2 handover.
Link-layer Trigger (L2 Trigger)
Information from L2 that informs L3 of the detailed events
involved in handover sequencing at L2. L2 triggers are not
specific to any particular L2, but rather represent
generalizations of L2 information available from a wide variety
of L2 protocols.
3. Problem Statement and Solution
The process of Mobile IP network layer handover incurs certain
protocol exchanges. These protocol actions are needed to establish
on-link connectivity at the new network where a mobile node has
moved to, and also to update the remote home agent(s) and end-points
for end-to-end connectivity.
When the standard Mobile IPv6 is used for network layer handovers,
the mobile node first needs to detect the network layer movement.
This can be accomplished via observing network prefixes, or relying
on L2 triggers. The latter provides much quicker detection wherever
such link layer support is available. Secondly, the mobile node
needs to discover the IPv6 subnet prefix, if it is going to use
stateless address auto-configuration. If movement detection were
based on listening to router advertisements, this step is already
covered. Otherwise, the mobile node needs to send a router
solicitation and receive router advertisements from access routers
to learn the IPv6 prefixes available on the link. Third step is
configuring a new care-of address. Mobile node can auto-configure a
new care-of address based on one of the prefixes and has to go
through a duplicate address detection [4] to make sure this address
is unique. Finally, the mobile node has to send binding updates to
its home agent and correspondent nodes to inform them about its new
location.
Mobile node is unreachable from the Internet until its new binding
Update is received by the home agent and the correspondent nodes.
Each of these steps takes time. Therefore, we are motivated to
optimize or eliminate some of these steps to minimize the length of
service disruption.
The L2 triggers are utilized to optimize movement detection process.
This saves waiting time to receive few subsequent router
advertisements. Binding update process is already optimized by the
standard Mobile IPv6 protocol. Binding updates are sent to the old
access router instead of home agent when forwarding from the
previous care-of address is applied. This optimization saves a round
trip time across the Internet. What is left can be summarized as
Gwon and Yegin Expires May 23, 2004
[Page 5] eFWD November 2003
configuring a new care-of address, which relies on prefix discovery
and duplicate address detection. Depending on the implementation and
configuration, this can be the costliest step among others.
Latency of configuring a new care-of address can be eliminated if IP
address of the new access router (where mobile node has just moved
to) is used as the new care-of address momentarily. If the mobile
node can send a binding update to the old access router, informing
the old care-of address as the home address and IP address of the
new access router as the care-of address, forwarding from the
previous care-of address is established through a tunnel between the
old access router and the new access router. Since the new access
router is the tunnel end-point for forwarded packets, it will have
to play a role to decapsulate the packets for this method. In
standard Mobile IPv6, the new access router does not have this
special role and it simply forwards packets for on-link IP addresses
without being aware of mobile node's mobility. Once forwarding from
the previous care-of address is established, the old access router
intercepts packets sent to the old care-of address and tunnels them
to the new access router. The new access router decapsulates
tunneled packets and forwards them to the mobile node via one of its
interfaces. Similarly, packets sent by the mobile node must be
intercepted by the new router and tunneled back to the old access
router. By doing so, the packets can be forwarded to the mobile node
even before the mobile node has to configure a new care-of address
using the new prefix. This approach provides an optimized solution
for Mobile IPv6 fast handover when accompanied with link-up trigger
[3] for movement detection.
This is a mobile-controlled protocol in which mobile node is in
charge of IP handovers. It only relies on the link-up trigger and
requires no pre-triggers that are based on movement anticipation. In
other words, benefits of this approach are reliability that only a
successful link layer handover triggers subsequent IP handovers and
independence of complexity in pre-signaling before the actual
handover.
4. The Protocol
4.1 Overview
Figure 1 illustrates Enhanced Forwarding from Previous Care-of
Address (eFWD) handover. eFWD is initiated by mobile node when it
receives a link-up trigger immediately after arriving at the new
access point (nAP). The mobile node must send eFWD BU informing the
old access router (oAR) about the new care-of address, therefore new
access router (nAR) information, so that the oAR can send HI message
to the nAR. We describe a method of doing so via Candidate Access
Router Information Discovery (CARID) procedure in detail in 4.2.2 of
this memo. The CARID allows the mobile node to learn handover
candidate access router information at some sufficient time prior to
the actual handover. The list of access routers obtained via CARID
Gwon and Yegin Expires May 23, 2004
[Page 6] eFWD November 2003
includes all possible next routers a host might handover to. After a
successful link layer handover, mobile node learns the L2 ID of the
new access point (nAP) and maps it to the link layer and network
layer IDs of the corresponding nAR.
+-------+ 3. HI +-------+
| |----------------->| |
| |<-----------------| |
| | 4. HAck | |
| oAR | | nAR |
| | 5. BAck | |
| |----------------->| |-+
| |<-----------------| | |
+-------+ 2. BU +-------+
@ @ ^ |
@ @ | |
@ @ | |
@ @ | |
/ \ / \ | |
/oAP\ /nAP\ | |
/ \ / \ | |
------- ------- | |
| | | 5. BAck
| 2. | |
1. Link Up | BU | |
| | |
V | |
+------+ | |
0. MN has performed CARID and moved | |-+ |
==============>| MN |<---+
| |
+------+
Figure 1: eFWD Handover
Once MN identifies the information about the nAR, it constructs a BU
and sends it to the oAR via nAR. In this BU, home address field is
set to the old care-of address, and the care-of address field is set
to the IP address of nAR. When this BU reaches at the oAR, HI and
HACK messages are exchanged between the oAR and nAR to set up a bi-
directional tunnel. With BU being acknowledged (i.e. BAck tunneled
to the nAR and forwarded to the MN), incoming packets destined to
the mobile node's old care-of address are tunneled by the oAR and
the nAR decapsulates and forwards them to the mobile node. Finally,
the mobile node may decide to acquire a new care-of address at
sometime later and update this information with its home agent and
all nodes of interest such as correspondent nodes. It can also
choose to terminate the forwarding from previous care-of address by
sending a de-registration BU to the oAR.
Gwon and Yegin Expires May 23, 2004
[Page 7] eFWD November 2003
4.2 Requirements
4.2.1 Control Messages
eFWD creates no new control messages. It inherits four control
messages are already defined by the standard and the fast Mobile
IPv6 protocols: Binding Update (BU), Binding Acknowledgment (BAck),
Handover Initiation (HI), and Handover Acknowledgment (HAck)
messages. eFWD requires a slight modification onto the existent
Binding Update (BU) message defined in [1]. P bit is added to
distinguish eFWD handover from other usages. The Binding Update
message used by eFWD is described as follows:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|H|S|D|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Address +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link Layer Fields:
L2 Source
L2 ID of MN
L2 Destination
L2 ID of nAR
IP Fields:
Source IP Address
Old care-of address of MN
Destination IP Address
IP address of oAR
Gwon and Yegin Expires May 23, 2004
[Page 8] eFWD November 2003
Acknowledge (A)
As specified in [1]
Home Registration (H)
Must be set for eFWD
Single Address Only (S)
As specified in [1]
Duplicate Address Detection (D)
As specified in [1]
Enhanced Forwarding from Preivous Care-of Address (P)
Must be set for eFWD
Reserved
As specified in [1]
Sequence #
As specified in [1]
Lifetime
As specified in [1]
Home Address
Old care-of address of mobile node
Mobility options
This BU must include two options, i.e. alternate care-
of address and link-layer address of MN options
Alternate care-of address
The alternate care-of address field of this option must
set to IP address of the nAR. The oAR sends HI message
to this address.
Link-layer address (LLA) of MN
This is a new mobility option that must be supported
for eFWD. The value of this option must be set to link-
layer address of MN so that nAR knows how to forward
packets to the MN when packets destined to the MN
arrives from oAR. This option format is defined as
follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Option Data
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Gwon and Yegin Expires May 23, 2004
[Page 9] eFWD November 2003
Option Type
TBD
Length
The length of this option, in bytes.
Option Data
Variable length link-layer address of MN. The content and
format of this field (including byte and bit ordering) is
expected to be specified in specific documents that
describe how IPv6 operates over different link layers.
Handover Initiation Message used in eFWD is as follows:
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 |S|U|H|T|R|P| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
IP address of oAR
Destination Address
IP address of nAR
ICMP Fields:
Type
TBD
Code
0
Checksum
As specified in [2]
Identifier
As specified in [2]
S
This bit must be unset
U
As specified in [2]
Gwon and Yegin Expires May 23, 2004
[Page 10] eFWD November 2003
H
This bit must be unset
T
This bit must be unset
R
This bit must be unset
Reserved
Must set to zero and ignored by receiver
Options
Must include both link layer-address of MN option and
old care-of address option as specified by [2]. Link-
layer address of MN is copied from the incoming eFWD BU
(inserted as the new Link Layer Address Option defined
above). Old care-of address option is copied from the
home address field of incoming BU.
Accordingly, Handover Acknowledgment Message for eFWD is as follows:
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 |H|T|R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
IP Fields:
Source Address
IP address of nAR
Destination Address
IP address of oAR
ICMP Fields:
Type
TBD
Code
As specified in [2]
Checksum
As specified in [2]
Identifier
As specified in [2]
Gwon and Yegin Expires May 23, 2004
[Page 11] eFWD November 2003
H
This bit must be unset
T
This bit must be unset
R
This bit must be unset
Reserved
Must set to zero and ignored by receiver
Options
Must contain lifetime option. This indicates the
maximum lifetime that the oAR can put in the lifetime
field of the BAck message.
4.2.2 Candidate Access Router Information Discovery (CARID)
Fast handover domain is defined by a set of access routers and their
associated access points. An access router must maintain either a
complete list of all access routers in the domain, or a partial list
of access routers that are in the same geographic neighborhood,
known as geographically adjacent access routers (GAAR). Subset of
the GAARs becomes potential handover candidate access routers for
visiting mobile nodes. Each entry in the table must contain IP
address of the access router, along with link layer address of the
access router and link layer address of the associated access
points. When a mobile node associates with an access point, all it
can figure out is the link-layer address of the access point. Mobile
node can identify the associated access router by doing a look up on
this table. If such a look up fails, that means fast handover to
this network is not supported and the mobile node has to resort to
regular Mobile IPv6 handover.
Creation and maintenance of this table on the access routers is
outside the scope of this memo. It can be done manually or by some
dynamic means.
Mobile node should be able to request this table from its current
access router anytime, not necessarily right before a handover.
UDP fields:
Source Port
Variable
Destination Port
TBD
Gwon and Yegin Expires May 23, 2004
[Page 12] eFWD November 2003
The UDP header is followed by the CARID fields shown 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 | Length | Data... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-
Type
1 - Request
2 - Response
Length
Length of data in bytes. 0 if this is a Request type.
Data field is used only with Response. This field contains a
sequence of options in the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Length | Data... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ...
+-+-+-+-+-+-
Sub-Type
1 - IP address of the access router
2 - Link layer address of the access router
3 - Link layer address of the access point
Length
Length of data in bytes
Sub-type 1 contains IPv6 address of the access router (16 bytes).
Sub-types 2 and 3 are to contain link layer addresses of access
router and access points. The content and format of this field
(including byte and bit ordering) are described in specific
documents that explain how IPv6 operates over different link layers,
such as IPv6 over Ethernet (RFC 2464).
A CARID response carries a list of access routers in its payload.
Information related to each access router must begin with Sub-type 1
field (i.e. access router's IPv6 address). This data must be
followed by the link-layer address(es) of this access router. And
each link-layer address of the access router must be followed by
link-layer address(es) of the associated access points. All Sub-type
2 and Sub-type 3 data before the next sub-type 1 data are associated
with the access router identified by the leading sub-type 1 data
Gwon and Yegin Expires May 23, 2004
[Page 13] eFWD November 2003
(IPv6 address). All sub-type 3 data before the next sub-type 1 or
sub-type 2 data is associated with the access point identified by
the leading sub-type 2 data.
Data field of a CARID Response must follow an order, such that sub-
type 1 is always followed by sub-type 2, and sub-type 2 is always
followed by sub-type 3.
5. Security Considerations
The protocol exchanges defined in this memo cause routing changes.
After a successful protocol signaling, access routers create bi-
directional tunnels and install host-based routes to direct a given
mobile node's traffic differently than what they would normally do
based on the prefix information. Any protocol signaling that can
cause such changes in routing needs to be secured in order to
prevent malicious nodes taking advantage of them.
It is assumed that access routers in a fast handover domain have
pre-established security associations among themselves. Therefore,
they can use IPSec [5] [6] to secure HI/HAck messages.
We cannot assume that a similar pre-established security association
will be available between the mobile node and every possible access
router. Therefore, this security association needs to be created
dynamically. Since mobile node has been receiving IP service from
the access router even before the signaling of this protocol, it is
assumed that they can establish such a security association based on
link layer or network layer methods [3] [7]. Specifics of these
methods are outside the scope of this work. Once such an association
is established, the mobile node and the access routers can use IPSec
to secure BU/BAck and the CARID Request/Response messaging.
6. References
[1] Johnson, D., B., et al., "Mobility Support in IPv6," draft-ietf-
mobileip-ipv6-24.txt, a work in progress, July 2003
[2] Koodli, R., et al., "Fast Handovers for Mobile IPv6," draft-
ietf-mobileip-fast-mipv6-08.txt, a work in progress, October 2003
[3] Kempf, J., et al., "Supporting Optimized Handover for IP
Mobility - Requirements for Underlying Systems," draft-manyfolks-l2-
mobilereq-02.txt, a work in progress, June 2002
[4] Narten, T., et al., "Neighbor Discovery for IP Version 6
(IPv6)," RFC 2461, December 1998
[5] Kent, S., "IP Authentication Header," draft-ietf-ipsec-
rfc2402bis-05.txt, a work in progress, September 2003
Gwon and Yegin Expires May 23, 2004
[Page 14] eFWD November 2003
[6] Kent, S., "IP Encapsulating Security Payload (ESP)," draft-ietf-
ipsec-esp-v3-06.txt, a work in progress, July 2003
[7] Yegin, A., et al., ôProtocol for Carrying Authentication for
Network Access (PANA) Requirements,ö draft-ietf-pana-requirements-
07.txt, a work in progress, June 2003
7. Addresses of Authors
Youngjune Gwon, Editor
DoCoMo Communications Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4734
San Jose, CA 95110 Fax: +1 408 451 1090
USA email: gyj@docomolabs-usa.com
Alper E. Yegin
DoCoMo Communications Laboratories USA, Inc.
181 Metro Drive, Suite 300 Phone: +1 408 451 4743
San Jose, CA 95110 Fax: +1 408 451 1090
USA email: alper@docomolabs-usa.com
8. Acknowledgment
Authors of this memo thank James Kempf, Atsushi Takeshita, Carl
Williams, Ravi Jain, Daichi Funato, Guangrui Fu, and Jonathan Wood
for their valuable discussion, comments, and support.
9. IPR Statement
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
10. Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Gwon and Yegin Expires May 23, 2004
[Page 15] eFWD November 2003
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
Appendix A. Performance Evaluation of eFWD in Handover Emulator
(HoE) Testbed
Figure A.1 depicts Handover Emulator (HoE) testbed for evaluating
handover performance of eFWD. The HoE testbed consists of two access
routers (AR1 and AR2), Mobile IPv6 home agent (HA), correspondent
node (CN), and mobile node (MN). HoE provides generic link layer
(L2) handover emulation for the MN switching its point of attachment
between the two ARs. HoE has a list of configurable parameters that
include L2 handover latency, downlink/uplink bit rates, and L2 pre-
trigger timing parameters. The pre-trigger timing parameters were
never set since eFWD is completely free from the L2 pre-triggers and
requires link-up trigger only at nAR.
100BaseT Shared Ethernet
-------+--------------------------+----------+
@ @ |
@ @ |
| +-----+ +-----+ | +-----+
L| | | | | | | |
2|@@@@@@@@| AR1 | | AR2 |@@@@ | | CN |
| | | | | @ | | |
T| +-----+ +-----+ @ | +-----+
r| @ @ @ | @
i| @ @ @ | @
g| +--------------------------------+ @ | +-----+
g| | | @ | | |
e| | Handover Emulator (HoE) | @ |@@@@| HA |
r| | | @ | | |
| +--------------------------------+ @ | +-----+
I| @ @ |
n| @ @
t| +-----+ @
e| | | @
r|@@@@@@@@@@@@@@@@@@@@@| MN | @
f| | | @
a| +-----+ @
c| @
e|@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
|
Figure A.1: Handover Emulator (HoE) Testbed
Gwon and Yegin Expires May 23, 2004
[Page 16] eFWD November 2003
We have adopted two metrics for eFWD handover performance
evaluation: IP layer blackout duration and UDP packet loss. IP layer
blackout duration is time gap during an IP handover that the MN is
not reachable by ICMP request. IP layer blackout duration was
measured by generating 300 consecutive ICMP requests to the MN at
rate of one request per 10 msec. This was done by issuing æping6Æ
commands from the CN to the MN. Later, we have counted the number of
ædestination unreachableÆ messages and multiplied it by 10 msec.
For UDP packet loss, we installed a traffic generator at the CN and
the constant UDP stream (one per 10 msec) was sent to the MN during
the eFWD handovers. The UDP payload size was 40 bytes emulating VoIP
application. Total number of lost UDP packets during the handovers
was recorded.
We have configured three different bit rates for MNÆs downlink, 144
kbps, 384 kbps, and 1 Mbps, designating typical values for the 3G
and wireless LAN bandwidths. We also have configured L2 handover
latencies at 0, 50, 100, and 200 msec. We have carried out 5 trials
for each configuration.
Mean IP layer blackout duration and UDP packet loss for each
configuration are presented in Tables A.1 and A.2, respectively.
Table A.1: Mean IP Layer Blackout Duration (msec)
+------------------------------------------------------------------+
|Downlink || L2 Handover latency (msec) |
|Bit rates |+------------------------------------------------------+
|(kbps) || 0 | 50 | 100 | 150 | 200 |
+------------------------------------------------------------------+
| 144 || 39.5 | 63.5 | 108.5 | 127.5 | 161.5 |
+------------------------------------------------------------------+
| 384 || 30.5 | 63.0 | 93.0 | 104.0 | 143.0 |
+------------------------------------------------------------------+
| 1000 || 30.0 | 60.0 | 91.0 | 90.0 | 123.5 |
+------------------------------------------------------------------+
Table A.2: Mean UDP Packet Loss (packets)
+------------------------------------------------------------------+
|Downlink || L2 handover latency (msec) |
|bit rates |+------------------------------------------------------+
|(kbps) || 0 | 50 | 100 | 150 | 200 |
+------------------------------------------------------------------+
| 144 || 4.0 | 7.0 | 10.0 | 13.5 | 14.5 |
+------------------------------------------------------------------+
| 384 || 3.0 | 6.0 | 10.0 | 12.5 | 13.5 |
+------------------------------------------------------------------+
| 1000 || 3.5 | 6.0 | 8.5 | 11.0 | 13.0 |
+------------------------------------------------------------------+
Gwon and Yegin Expires May 23, 2004
[Page 17] eFWD November 2003
Appendix B. Performance Evaluation of eFWD in IEEE 802.11b Wireless
LAN Testbed
We have obtained IP layer blackout duration and UDP packet loss
during eFWD handovers in IEEE 802.11b wireless LAN testbed. The
testbed was constructed with LinkSys IEEE 802.11b products. Total of
5 eFWD handovers were triggered in the testbed. Mean IP layer
blackout duration and UDP packet loss are presented in Tables B.1.
Table B.1: Mean IP Layer Blackout Duration and UDP Packet Loss
for eFWD Handover in Wireless LAN Testbed
+---------------------+--------------------+
| Mean IP layer | Mean UDP |
| blackout duration | packet loss |
| (msec) | (packets) |
+---------------------+--------------------+
| 174 | 22.4 |
+---------------------+--------------------+
Gwon and Yegin Expires May 23, 2004
