| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi all, I have earlier (dated 06 Mar 2003) written an Internet draft on identical approach to detect L2/L3 movement. Please refer to the following (attached the ID) for detail. http://www.ietf.org/mail-archive/working-groups/seamoby/current/msg01629.html. Hope to hear some comments. Sungjin Lee wrote: Hi Daniel, Stephen and all HO guys In my understanding, that kind of issue (e.g. ARID into beacon) is fit to be discussed within 802.21. The ARID formant, recommended usage examples and scenarios also could be discussed and then put into the documentation released as 802.21 spec. based on agreement between 802.21 attendees. However, the specific way to provide that ARID information over the air interface should be discussed within each WG. In fact, It sould be discussed within 802.11 WG to propose the changed Beacon frame structure including ARID and within 802.16 to propose the changed DL-MAP or NBR-ADV message including ARID. Let me know if I misunderstanding something from the Stephen's comments Regards, Sungjin Lee ===================================== Global Standards & Research Team Telecommunication R&D Center SAMSUNG Electronics TEL : +82 31 279 5248 MOBILE : +82 16 301 6603 E-mail : steve.lee@samsung.com ====================================== -----Original Message----- From: owner-stds-802-21@listserv.ieee.org [mailto:owner-stds-802-21@listserv.ieee.org] On Behalf Of S. Daniel Park Sent: Wednesday, April 28, 2004 8:38 AM To: 'McCann, Stephen'; 'stds-802-21' Cc: ajayrajkumar@LUCENT.COM; 'S. Daniel Park'; 'Pyungsoo Kim' Subject: RE: contributions for upcoming May 2004 meeting - ARID Stephen, thanks your kindly comments on this work. I agree what you said, this solution can be applied for several wireless environments and I really hope it will be expanded to related WG as you stated 802.11 WIEN SG. I am deeply considering what approach is more general as 802.21 guys indicated and also waiting for various comments/feedbacks on this work. -- Cheers, Paul Tan |
Internet Draft Paul Tan
draft-paultan-seamless-ipv6-handoff-802-00.txt ICR
Expires: Aug 2003 Feb 2003
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
To achieve seamless layer 3 handover, mobile nodes must be able to
perform movement detection and neighborhood candidate access routers
discovery quickly and efficiently.
In this document, we present a conceptual overview on how to extend
the IEEE 802.11 Management frames to carry extensible application-
specific Information Element, which allow access points to advertise
the capabilities information of its associated network/provider and
to improve movement detection. We believe that mobile nodes can thus
dynamically discover neighboring candidate access routers or
networks more quickly and efficiently, and also to obtain valuable
capabilities information so as to select the 'best' target access
router to initiate seamless handover.
Paul Tan Expires - August 2003 [Page 1]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as
described in RFC 2119. This document uses the terminology defined in
[2] and [3]. The following terminology and abbreviations are used in
this document.
Mobile Node (MN)
A Mobile IPv6 host
Access Router (AR)
An Access Network Router residing on the edge of an Access Network
and offers IP connectivity to mobile nodes
New Access Router (NAR)
The MN's anticipated default router subsequent to its handover
Candidate AR (CAR)
An AR to which a MN has a choice of performing IP-level handover.
This implies that the MN has the right radio interface to connect to
an AP that is served by this AR, as well as the coverage of this AR
overlaps with that of the AR to which the MN is currently attached
to.
Target AR (TAR)
An AR with which the procedures for the MN's IP-level handover are
initiated. The TAR is selected after running a TAR Selection
algorithm that takes into account the capabilities of CARs,
preferences of the MN and any other local policies.
New CoA (NCoA)
The MN's Care of Address valid on NAR
Handover
A process of terminating existing connectivity and obtaining new IP
connectivity.
Router Solicitation for Proxy (RtSolPr)
A message from the MN to the PAR requesting information for a
potential handover
Proxy Router Advertisement (PrRtAdv)
A message from the PAR indicating a MN to undergo handover
Paul Tan Expires - August 2003 [Page 2]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
Access Point (AP)
An L2 entity that has station functionality and provides access to
the distribution services, via the wireless medium for associated
stations.
Association
The service used to establish access point/station (AP/STA) mapping
and enable STA access to the Distribution System.
Basic Service Set (BSS)
A set of stations controlled by a single coordination function,
where the coordination function may be centralized (e.g., in a
single AP) or distributed (e.g., for an ad-hoc network). The BSS
can be thought of as the coverage area of a single AP.
Distribution System (DS)
A system used to interconnect a set of basic service sets (BSSs) and
integrated local area networks (LANs) to create an extended service
set(ESS).
Extended Service Set (ESS)
A set of one or more interconnected basic service sets (BSSs) and
integrated local area networks (LANs) that appears as a single BSS
to the logical link control layer at any station associated with one
of those BSSs. The ESS can be thought of as the coverage area
provided by a collection of APs all interconnected by the
Distribution System. It may consist of one or more IP subnets.
Paul Tan Expires - August 2003 [Page 3]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
2. Introduction
In Mobile IPv6 [1], a mobile node can effectively maintain its
connectivity to the Internet when it changes its point-of-attachment
to the Internet. During the handover, the mobile node is unable to
send/receive IPv6 packets both due to its L2/L3 handover operations.
This handover latency is unacceptable to real-time or delay
sensitive traffic/applications.
2.1 Movement Detection based on Router Advertisements
Whenever a mobile node moves, it is required to perform movement
detection by discovering (sending Router Solicitation) its current
environment.
In Mobile IPv6 [1], the movement detection algorithm relies on the
periodic Router Advertisements to enable the mobile node to
determine their current location. To achieve optimum detection
performance, Router Advertisements can be broadcast at a faster
rate, which eventually results in poor link utilization. The
algorithm can be triggered through the indication from the
underlying L2 driver. However, we noted that not all L2 mobility
indication from the L2 driver indicates movement of the mobile node
to a new subnet (i.e. L3 movement).
Movement detection, which is achieved through the use of Neighbour
Discovery [4] requires routers to send unsolicited Router
Advertisement at a minimum interval of 3 seconds [section 6.2.4 of
[4]]. Upon receipt of a Router Solicitation message, the router MUST
delay its response (i.e. Router Advertisement) by a random time.
Lastly, the protocol also requires the mobile node to delay its
transmission of the initial solicitation for a random amount of
time. Such delay is simply not desirable in achieving seamless
handover. However, mobile IPv6 [1] relaxes such limit to allow
mobile nodes to quickly detect their movement by listening to Router
Advertisements, which are sent at a much faster rate.
2.2 Fast-Handoff Protocol
The fast handover protocol [2] is designed to achieve seamless
handoff of mobile nodes between the access routers.
In a mobile-initiated anticipated fast-handover described in [2],
the mobile node first sends a Router Solicitation for Proxy(RtSolPr)
to the current access router containing the link-layer address of
the new access point. The current access router replies with
RtrAdvPr, which contains the [AP-ID, AR-MAC, AR-IP] tuple. These
message exchanges allows a mobile node to obtain the new access
Paul Tan Expires - August 2003 [Page 4]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
router's MAC address, which is needed to send packets once the
mobile node attaches to the new access router, and also to perform
'anticipative' configuration of the new IP address on the new subnet
using the New Router Prefix Information option carried in the
RtrAdvPr message.
However, the above protocol assumes that the L2 protocol is capable
of delivering the L2 identifier of the new access point to the
mobile node. More important, to initiate seamless handover, the
current AR must be capable of mapping this new L2 identifier into
the IP address of the new AR [6]. Lastly, it assumes that the mobile
node or the current access router have a priori knowledge (e.g.
capabilities) of the target of the handover (i.e. target access
router).
3. Proposal Overview
One of the challenges in achieving seamless L3 handover is the
ability of MN to perform movement detection and to discover and
select its new neighboring candidate access router quickly and
efficiently that matches closely to the mobile node preferences or
requirements.
In this document, we present an overview on how to extend the IEEE
802.11 Management frames to carry extensible application-specific
Information Element, which allow access points to advertise the
capabilities information of its associated network/provider. The
recommendation also improves in the movement detection mechanism by
avoiding unnecessary L3 messaging over the wireless link. More
importantly, we believe that mobile nodes can dynamically discover
neighboring candidate access routers or networks more quickly and
efficiently, and also to obtain valuable capabilities information so
as to select the 'best' target access router to initiate seamless
handover. The recommendation also allows new/removed access routers
and access points to be discovered without much human interventions.
3.1 Instantaneous/Faster Movement Detection
In this section, we describe how to configure the Extended Service
Set Identifier (ESSID) of an infrastructure 802.11 network such that
it includes the L3 identifier/Information of its associated AR or
network.
With this embedded identifier (e.g. IP address or prefix
information), MN can quickly detect movement to a new L3 subnet,
thus avoiding transmitting unnecessary L3 messages (i.e. Router
Solicitation/Advertisement) and delays.
Paul Tan Expires - August 2003 [Page 5]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
To perform instantaneous movement detection, we recommend that APs
to include the subnet prefix information for their associated AR
(Subnet-Router-Anycast-Address) into the ESSID. This recommendation
allows MN to discover new network when it established a L2
connection with the new AP in an instantaneous manner.
+---...--+
| |
+-----+ +-----+ +-----+
| AR1 | | AR1 | | AR2 |
+-----+ +-----+ +-----+
| | |
+---+---+ | |
| | | |
+-----+ +-----+ +-----+ +-----+
| AP1 | | AP2 | | AP1 | | AP2 |
+-----+ +-----+ +-----+ +-----+
/\ /\ /\ /\
/ \ / \ / \ / \
/ \ / \ / \ / \
/ \/ \ / \/ \
/ /\ \ / /\ \
/ / \ \ / / \ \
re-assoc
(mn) ----->
|----- essid_1 -----| |---- essid_1 ----|
Figure 1: Typical/Possible 802.11 Network Deployment
However, to improve the inter-cell (802.11) handoff performance,
several APs belonging to different administrative domains (different
subnets) may choose to share similar ESSID. Therefore, as MN moves
across these cells, it only needs to initiate re-association instead
of the plain association process, which can take significantly
longer. In this case, instead of embedding network prefix
information into the ESSID, which is specific to each subnet, AP can
include Network-Prefix-Information (section 5.1.1) object using the
Application-Specific Information Element (section 5.1) into the
beacon frames.
Paul Tan Expires - August 2003 [Page 6]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
The table below shows an example of a list of beacon information
advertised by the neighboring APs received by the MN on a specific
wireless interface with an identifier, mniid.
+-------------+---------------+--------+------+-----------------+------+
|Subnet-prefix| ESSID | AP-MAC | RSSI | Care-of-Address |Status|
+-------------+---------------+--------+------+-----------------+------+
| prefix1 | essid1 | MAC1 |x dbm | prefix1:mniid | - |
+-------------+---------------+--------+------+-----------------+------+
| prefix2 | essid1 | MAC2 |x dbm | prefix2:mniid |active|
+-------------+---------------+--------+------+-----------------+------+
| prefix3 | essid2 | MAC3 |x dbm | prefix3:mniid | - |
+-------------+---------------+--------+------+-----------------+------+
| prefix4 | essid3 | MAC4 |x dbm | prefix4:mniid | - |
+-------------+---------------+--------+------+-----------------+------+
Table 1: Beacon Lists
When MN moves, the underlying driver can indicate such movement
using triggers (e.g. onL2Up during the 802.11 Assoc/Re-Assoc events)
to the mobile IP stack. Based on the earlier cached configuration of
the new subnet, MN can immediately perform mobile IP operations
without performing movement detection using Router Solicitation and
Advertisement.
4. Dynamic Candidate Access Router Discovery
MN constantly listens for any beacons frame advertised by the
neighboring APs. When MN discovers a new AP/Advertisement, it stores
the advertised capabilities information, which is encapsulated
inside the Network-Capabilities-Information Object (section 5.1)
into its Neighborhood CAR list.
+---------------+---------------+---------+---------+-----+--------+
| Subnet-prefix | ESSID | Cost | Fast-HO | QoS |Security|
+---------------+---------------+---------+---------+-----+--------+
| prefix1 | essid1 | 0 units | n | n | n |
+------------------------------------------------------------------+
| prefix2 | essid1 | 1 units | n | n | y |
+------------------------------------------------------------------+
| prefix3 | essid2 | 2 units | n | y | n |
+------------------------------------------------------------------+
| prefix4 | essid3 | 3 units | y | y | y |
+------------------------------------------------------------------+
Table 2: Neighborhood CAR list
Paul Tan Expires - August 2003 [Page 7]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
MN can store these discovered information ordered by either the
signal strength or other parameters (e.g. Pricing). To
achieve/assist fast handoff operation, information such as L2/L3
address mapping of the AR can be obtained from the Access-Router-
Information Object (section 5.1.3).
Therefore, the ability to dynamically discover neighboring CAR's
capabilities allows the MN to perform the selection of TAR based on
the mobile node's preference or requirements [6].
4.1 Operations
In this section, we will briefly describe the operation on the MN.
MN AP1 AP2 AP3 AR3
- | advertisement | | | |
| | <------------ | | | |
| | advertisement | | | |
| <--------------------------- | | |
NDP | | | | |
. . . . .
| . . . . .
. advertisement . .
- | <---------------------------------------- | |
| | | | |
- | assoc/re-assoc | |
| | ----------------------------------------> | |
PP | L3 HO | |
| | --------------------------------------------> |
- | | | | |
- Neighborhood Discovery Phase (NDP)
- MN discovers neighboring APs or networks and creates a list of
CARs with their advertised information (Table 2)
- Optionally, during the neighborhood discovery phase, MN can
configure in advance new CoA for each discovered APs on various
different subnets.
- 'Panic' Phase (PP)
- If the current associated AP's signal strength drops or if the
MN discovers a new AP, which offers 'better' service/pricing,
MN can immediately perform a handover to this new AP/AR.
- MN decides to perform association/re-association with a new AP
(e.g. AP3) based on MN's preference/requirements
- We assumed here that AP3 is associated with a different subnet;
MN will know that it has moved to a new network using the
cached information.
- Assuming MN is still attached to AP1, it quickly initiates
fast-handoff using the cached information of AP3(AR3-L2-ID,
Paul Tan Expires - August 2003 [Page 8]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
AR3-L3-ID).
- Or if the MN has already obtain a valid CoA for which the new
AR has reserved/defended, it can quickly initiate a
'lightweight-FHO' (a trigger to indicate movement confirmation)
5. Extensible Application-Specific Information Elements
We proposed to extend the current IEEE 802.11 Management frames to
carry extensible application-specific information elements. For
example, the IEEE 802.11 Beacon frame with the newly proposed IE is
shown in the figure 2.
The Extensible Application-specific IE allows future
applications/protocols to encapsulate their information into the
IEEE 802.11 frame easily, hopefully without much software
modification. With the new IE, we believe that valuable information
can then be easily included in the IEEE 802.11 Management frames and
discovered by roaming MN.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Control | Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Basic Service Set ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Sequence Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capability Information | Beacon Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp | SSID (2-34 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Rates (3-7 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| Extensible-Application-Specific IE |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. 802.11 Beacon Frame with new Ext-Application-Specific IE
Paul Tan Expires - August 2003 [Page 9]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
The above application-specific IE consists of the following fields:
Element ID, Length, and Extensible-Application-Specific Information.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Length | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Application-Specific Object +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Extensible-Application-Specific Information Element
As defined in [3], the element ID field is 1 octet long and
specifies the type of IE. The length field is 1 octet long and
specifies the length (number of octets) of the application-specific
Information field. Lastly, the application-specific object field
carries the specific application object using the following
structure.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App ID | Length | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+ Application-Specific Information +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4. Generic Application-Specific Object Structure
5.1 Application-Specific Information Objects
In this conceptual document, we have proposed several application-
specific objects to achieve our intended objective. We believed that
future application objects could be easily defined and carried
through the Extensible-Application Information Element without
defining new IEEE 802.11 information elements.
Paul Tan Expires - August 2003 [Page 10]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
5.1.1 Network-Prefix-Information Object
The format of the Network-Prefix-Information object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App_NwPrfInfo | Length | Prefix-Length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Prefix Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
App-ID App_NwPrfInfo (1)
Length 1 + Length of the prefix value in octets
Prefix-Value An IPv6 address or its prefix. The Prefix Length
field contains the number of valid leading bits in
the prefix.
5.1.2 Network-Capabilities-Information Object
The format of the Network-Capabilities-Information object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App_NwCapInfo | Length | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Capabilities-Info |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
App-ID App_NwCapInfo (2)
Length 1
Capabilities-Info TBD
5.1.3 Access-Router-Information Object
The format of the Access-Router-Information object is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| App_ARInfo | Length | .. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
| IPv6 Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Paul Tan Expires - August 2003 [Page 11]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
App-ID App_ARInfo (3)
Length 22
MAC Address A MAC address for the access router
IPv6 Address An IPv6 address for the access router
6. Requirements
MN should be capable of receiving and passing the new Extensible
Application information up from the 802.11 driver to IP layer.
The IEEE 802.11 AP should be configurable such that new Application-
specific information can be carried in the 802.11 frames without
much hassle. The AP should also be able to include this new IE into
the beacon or even the association/re-association frames.
References
[1] D.Johnson, C.Perkins and J.Arkko, Mobility Support in Ipv6,
draft-ietf-mobileip-ipv6-18.txt, May 2002
[2] Dommety, G., et. al., Fast Handovers for Mobile Ipv6, draft-
ietf-mobileip-fast-mipv6-05.txt
[3] IEEE, "Part II: Wireless LAN Medium Access Control (MAC) and
Physical Layer (PHY) Specifications, 1999
[4] T.Narten, E. Nordmark and W.Simpson, Neighbor Discovery for IP
Version 6 (IPv6), RFC 2461, December 1998
[5] Alper E. Yegin, Daichi Funato, Karim El Malki, Youngjune Gwon,
James Kempf, Mattias Pettersson, Phil Roberts, Hesham Soliman,
Atushi Takeshita, Supporting Optimisation Handover for IP
Mobility - Requirement for Underlying Systems, draft-
manyfolks-l2-mobilereq-02.txt
[6] Trossen, D., Krisharmurthi, G. Chaskar, H., Kempf, J, Issues
in Candidate Access Router Discovery for seamless IP-level
handoffs, draft-ietf-seamoby-cardiscovery-issues-04.txt, work
in progress, October 2002
Paul Tan Expires - August 2003 [Page 12]
Recommendations for Achieving Seamless IPv6 Handover
in IEEE 802.11 Networks February 2003
Acknowledgments
The author would like to thank James Kempf and Parijat (I2R) for
their review and suggestions.
Author's Addresses
Paul Tan
Institute of Communications Research (ICR)
20, TeleTech Park,
#02-34/37, Singapore Science Park II,
Singapore 117674
Phone: +65 68709324
Email: tanpaul@i2r.a-star.edu.sg