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 Paul Tan Expires - August 2003 [Page 13]