IETF Mobile IP Working Group Kyungjoo Suh Internet Draft Youngjun Park Jaekwon Oh Eun-Hui Bae Document: draft-suh-mip6-arip-00.txt Samsung Electronics Expires: April 2004 October 2003 Access Router Information Protocol (ARIP) Status of This Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 This document defines Access Router Information Protocol (ARIP) whereby a mobile host can improve the handoff performance by exchanging, in advance, the information among geographically adjacent access router(AR)s. This protocol does not need a certain assumption of network topology so that it can be applied to heterogeneous networks as well as homogeneous networks. This document also describes a framework to minimize the handoff latency with the aid of ARIP. Therefore, ARIP can be combined with the protocol such as Fast Handovers (for Mobile IPv6) which tries to minimize the handoff latency. Suh, et al [Page 1] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of ARIP . . . . . . . . . . . . . . . . . . . . . . . 4 4. ARIP Operation . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1 Exchange of ARIP information among ARs . . . . . . . . . 6 4.2 Message Format for ARIP . . . . . . . . . . . . . . . . . 7 4.2.5 ARIP Update . . . . . . . . . . . . . . . . . . . . 7 4.2.5 AR-Request . . . . . . . . . . . . . . . . . . . . 9 4.2.5 AR-Reply . . . . . . . . . . . . . . . . . . . . . 10 4.2.5 MH-Request . . . . . . . . . . . . . . . . . . . . 11 4.2.5 MH-Reply . . . . . . . . . . . . . . . . . . . . . 12 4.3 Delivering neighbor ARs information to mobile hosts . . . 13 4.4 Handoff operation with ARIP . . . . . . . . . . . . . . . 14 5. Interoperability with Other Technology . . . . . . . . . . . . 17 5.1 Interoperability with the Mobile IPv6 Fast Handover . . . 17 6. Security Considerations. . . . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 Suh, et al [Page 2] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 1. Introduction Mobile IP [4] has been proposed to provide a seamless connection when a mobile host changes the point of attachment within the Internet. In general, in the basic Mobile IPv6, handoff between two access routers causes some packets for the mobile host to be lost. The handoff latency is composed of time to detect the movement, time to configure the new CoA at the new point of attachment, and time to update the new CoA to its Home Agent and its Corresponding Nodes. When a mobile host initiates a handoff procedure, it first initiates an L2 handoff process. If the mobile host uses the IEEE 802.11 based WLAN technology, it should scan for all channels to obtain the information of Access Points (AP) that gives the best radio signal quality. Sequentially checking those channels is time consuming and it is dominant part of the L2 handoff latency [1]. Before finishing the L2 handoff completely, the mobile host cannot receive proper L3 information such as Router Advertisement messages which is required to its movement detection. Existing solutions, such as Fast Handoff [6] and Hierarchical Mobile IP [7] schemes, have been focused on reducing the L3 latency. If the L2 latency can be reduced with some additional information, and coupled with the Fast handoff protocol, the total handoff latency of Mobile IP can be reduced enough to accommodate the real time traffic. This document specifies a framework to reduce the handoff latency in Mobile IP. For this purpose a new information exchange protocol, which is referred to as ARIP (Access Router Information Protocol), among geographically adjacent access routers (AR) is proposed. The main objective of the ARIP protocol is to reduce the L2 handoff latency. It is used for the mobile host to reduce the time required to perform the wireless access network discovery. The framework described here can be applied to homogeneous wireless networks as well as heterogeneous wireless networks. We give some example scenarios for this, and describe some method that also reduces the L3 handoff latency with the aid of the ARIP. 2. Terminology 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 RFC 2119. Heterogeneous Wireless Network A wireless network that provides one or more different types of wireless access technologies Homogeneous Wireless Network A wireless network that provides one type of wireless access technology Suh, et al [Page 3] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 PFBU In ARIP, PFBU message sends from MN instructing its PAR to redirect its traffic towards NAR PFBack A message from the PAR in response to PFBU 3. Overview of ARIP ARIP presents mobile hosts with an efficient handoff framework by exchanging information related to handoff process among geographically neighboring Access Routers (ARs). By ARIP operations, a mobile host can be informed, in advance, of information on neighboring ARs to which the mobile host likely to handoff. The main goal of ARIP is minimizing the layer 2 (L2) handoff latency as well as the layer 3 (L3) handoff latency that is required when a mobile host moves from one AR to another AR. ARIP can be applied to heterogeneous wireless networks as well as homogeneous wireless networks. Furthermore, ARIP is independent of layer 2 technologies and can be applied to the Fast Handover for Mobile IPv6. In the wireless network such as wireless local area networks (WLANs), ARIP lets an AR learn both L2 and L3 information on another AR by exchanging one's local L2 and L3 information with each other. L2 information includes a specific L2 wireless access technology that an AR currently providing, channel number which is specific to the (that) L2 wireless access technology, etc. L3 information includes the global address of an AR, administrative domain information, and the optional current QoS status information. After the information is exchanged, AR delivers the information to a mobile host. When the mobile host moves from one AR to another, it knows the precise information of ARs to which it is likely to handoff. When geographically neighboring ARs exchange their local L2 and L3 information with each other, the information may be delivered to mobile hosts. When a mobile host handoffs, it can figure out channels currently in use by using the ARIP information transmitted from the AR to which the mobile host handoffs. Since the mobile host scans only the channels currently in use by neighbor ARs (instead of all the channels), L2 handoff latency can greatly be reduced. Knowing L3 information about the AR to which a mobile host is likely to handoff in advance can also reduce L3 handoff latency. With the information, the reverse address translation (RAT) process [2, 5] can be avoided. In addition, the mobile host can form an address which will be used at the AR to which the mobile host handoffs and perform the DAD (Duplicate Address Detection) process in advance. Moreover, the ARIP protocol is interoperable with Fast Handovers for Mobile IPv6. Suh, et al [Page 4] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 ARIP can also let a mobile host know whether the future AR supports QoS requirements or not, by utilizing the received QoS and other functionality information. Thus, ARIP not only enables efficient handoffs among ARs but also reduces handoff latencies. Section 4 describes ARIP in detail. 4. ARIP Operation Figure 1 shows example network architecture for Access Router Information Protocol (ARIP), where R1, R2, and R3 are normal routers, AR1, AR2, AR3, and AR4 are access routers (ARs) that manage the wireless network, and MH indicates a mobile host. +-----------------------+ / \ / \ + IP Network + | (IPv4/IPv6) | + + \ / \ / +-----------------------+ | | +--------+ | R1 | +--------+ | +--+ | +------+ | | +-------+ | / \ | | | | | +-----+ | | +-----+ | R2 | | | | R3 | +-----+ | | +-----+ | | | | | | +------+ +--+ | | +--+ +--------+ | +----------+| | | | +---------+ | | | || | | | | | | +---V-+ +V--V-+ +V---V+ +V----+ | AR1 | | AR2 | | AR3 | | AR4 | +-----+ +-----+ +-----+ +-----+ +----+ | MH | +----+ ------------> Movement Figure 1: Network Architecture of ARIP Suh, et al [Page 5] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 +-----+ / \ / \ +-----+ +-----+ / \ / \ / \ / \ + +-----+ ##>AR3<## +-----+ \ / ## #/ \ \ / # \ ## \ +-----+ #>AR2V +-----+ ##>AR4 + / \ # / \ / / #### / \ / + AR1 V +-----+ +-----+ \ / \ / \ / \ / +-----+ +-----+ \ / \ / +-----+ Figure 2: Communication among geographically adjacent ARs As stated in Section 3, geographically adjacent ARs exchange their information by ARIP as shown in Figure 2. The followings are three operations of ARIP: 1) Exchange of information among ARs geographically adjacent. 2) Delivering ARIP information received from other ARs to a mobile host. 3) Handoff operation using the received information by ARIP to reduce the handoff latency Now, following sub-sections describe each of the operations in detail. 4.1 Exchange of ARIP information among ARs To exchange ARIP information among neighbor ARs, an AR MUST know the existence and its L3 identifier (global address in IPv6) of the neighboring ARs. There are two approaches for this. A simple approach is that the network administrator sets up the L3 identifiers of neighboring ARs explicitly to each AR. If network topology is simple and does not change often, this approach may be useful. All of the corresponding ARs, however, need to be updated whenever an AR is added or deleted, or the global address of the AR is changed. The other approach is that each AR learns automatically the L3 identifiers about its neighbor ARs by using the information offered by mobile hosts. This concept was introduced in [2] and [5]. The detailed process is out of scope of this document. In this approach, when performing a handoff, a mobile host informs the Suh, et al [Page 6] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 AR in the current network of the information about the previous AR. Therefore, each AR can learn the L3 identifiers about neighbor ARs in some time. The basic operation of ARIP to exchange the information among ARs is quite similar to that of routing information protocol (RIP) [3] in which topologically neighboring routers exchange their routing table with each other. RIP is a routing protocol that runs as an application level program, and ARIP can also be run as an application level program. A mobile host may or may not use the information obtained by ARIP. ARIP does not require any modification to existing base Mobile IP. The mobile host that makes use of the information exchanged among ARs includes L2 information, L3 information, and other information to speed up the handoff. Each AR exchanges the L2 information to reduce the L2 handoff latency of a mobile host. Different L2 information may be possible when different L2 radio technologies are used in wireless networks. For example, when the IEEE 802.11 WLAN is used, L2 information will be ESSID, channel number, authentication information, QoS information, etc. Each AR exchanges the L3 information to reduce the L3 handoff latency of a mobile host. The L3 information includes the global address of access router, and may include QoS information, information whether AR supports fast handoff, paging etc. The update periods of each information field can be different according to its property. The L2 information and L3 information except QoS field does not change frequently. Each L2 information, L3 information, and QoS information may have its own update period. For example, the update periods of L2 information and L3 information are the same, and can be set to n times as long as the update period of QoS information. 4.2 Message Format for ARIP 4.2.1 ARIP Update An AR sends an ARIP Update message periodically to exchange the ARIP information among geographically adjacent ARs. The ARIP Update messages use the User Datagram Protocol (UDP). 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Suh, et al [Page 7] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 IP fields: Source address IPv6 address from which the message is sent Destination address IPv6 address of neighbor AR UDP fields: Source Port Variable Destination Port TBD ARIP Update fields: Type 0 Code 0 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Required option: Global Address of the Sender Global IPv6 address of AR's interface that is currently configured to serve the wireless access network Other valid options: Lifetime of L2 information The duration for which a corresponding delivered L2 information is valid. This field is mandatory if at least one of the options in the message falls into L2 category. L2 radio info. This information is categorized into L2 information. The type of the radio access technology used in the sender. Channel info. This information is categorized into L2 information. Channel information of the wireless network. This information represents the characteristic or identification of the channel. Lifetime of L3 information The duration for which a corresponding delivered L3 information is valid. This field is mandatory if at least one of the options in the message fall into L3 category. Security info. This information is categorized into L3 information. Security related information supported by the sender Suh, et al [Page 8] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 Capability info. This information is categorized into L3 information. L3 related capability information whether the sender supports the Fast Handoff protocol, paging, etc. Lifetime of QoS information The duration for which a corresponding delivered QoS information is valid. This field is mandatory if QoS info. field exits in the message. QoS info. The capability or characteristic of the QoS of the current wireless network 4.2.2 AR-Request An AR sends an AR-Request message to request the specific information such as the QoS status or capabilities of the neighbor AR. The AR-Request messages use the User Datagram Protocol (UDP). 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP fields: Source address IPv6 address from which the message is sent Destination address IPv6 address of neighbor AR UDP fields: Source Port Variable Destination Port TBD AR-Request fields: Type 1 Code 0 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Suh, et al [Page 9] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 Required option: Global Address of the Sender Global IPv6 address of AR's interface that is currently configured to serve the wireless access network Other valid options: Required Information The type of information that the sender wish to acquire from the neighbor AR 4.2.3 AR-Reply An AR sends an AR-Reply message as response to the received AR-Request message. If the AR can reply to the received AR-Request message, AR sends an AR-Reply message with code field as 0. Otherwise, the AR sends the AR-Reply message with code field as 128. The AR-Reply messages use the User Datagram Protocol (UDP). 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP fields: Source address IPv6 address from which the message is sent Destination address Copied from the source address of the corresponding AR-Request message UDP fields: Source Port Variable Destination Port Copied from the source port of the corresponding AR-Request message AR-Reply fields: Type 2 Code 0 if the AR can reply to the AR-Request message 128 if the AR can not reply to the AR-Request message Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Suh, et al [Page 10] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 Required option: Global Address of the Sender Global IPv6 address of AR's interface that is currently configured to serve the wireless access network Other valid options: The Reply Information The corresponding information that the sender wished to acquire. Possible options are specified in section 4.2.1. 4.2.4 MH-Request An MH sends a MH-Request message to its current AR for learning the information on neighbor ARs. The MH-Request messages use the User Datagram Protocol (UDP). 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP fields: Source address IPv6 address from which the message is sent Destination address IPv6 address of the current AR UDP fields: Source Port Variable Destination Port TBD MH-Request fields: Type 3 Code 0 Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Required option: Global Address of the Sender Global IPv6 CoA address of MH Suh, et al [Page 11] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 4.2.5 MH-Reply An AR sends a MH-Reply message as response to the received MH-Request from the mobile host. The MH-Reply messages use the User Datagram Protocol (UDP). 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- IP fields: Source address IPv6 address from which the message is sent Destination address Copied from the source address of the corresponding MH-Request message UDP fields: Source Port Variable Destination Port Copied from the source port of the corresponding MH-Request message MH-Reply fields: Type 4 Code 0 if the AR has one or more information on neighbor ARs. 128 if the AR has no information on neighbor ARs. Reserved This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Required option: Global Address of the Sender Global IPv6 address of AR's interface that is currently configured to serve the wireless access network Other valid options: In the option field, the AR informs to the mobile host about the information on neighbor ARs. Therefore, the option forms the list. Each entry of the list has same format as Sub-option as follows. Suh, et al [Page 12] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 Sub-option fields: Index The index by which neighbor ARs information can be distinguished. Length The length of the information delivered to the mobile host. One plus the number of bytes in the Information. Information The set of one AR's information delivered to the mobile host. The required option and other valid options specified in section 4.2.1 are used. Other optional information derived by the operation of ARIP such as topological distance between the current AR can be included. How to measure the topological distance between ARs is out of the scope of this document. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Index | Length | Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information ... +-+-+-+-+-+-+-+-+-+-+-+- 4.3 Delivering neighbor ARs information to mobile hosts An AR may deliver the information on neighbor ARs to mobile hosts using ARIP. The delivery occurs only when the mobile host requests it explicitly via a MH-Request message. The decision when the mobile host transmits a MH-Request message depends on itself. The mobile host may send such a request to its current AR as soon as it handoffs to the AR. In this case, the information that the mobile host has become stale if the one of the current AR's neighbor AR changes its configurations or status related ARIP information. But it is still effective when the mobile host need only either one of or both of the L2 and L3 information which does not change frequently. On the other hand, the information changes so often like optional QoS information should not be used in this way. The QoS information may contain the number of hosts an AP is currently supporting, the current channel utilization, maximum bandwidth acceptable per mobile host, and etc. Thus, Qos information should be delivered to the mobile host just before the mobile host initiates the handoff procedure. This document does not specify the exact time of the ARIP information delivery, but the time depends on mobile hosts' need. The mobile host may transmit the MH-Request messages several time in order to get the up-to-date information. Suh, et al [Page 13] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 4.4 Handoff operation with ARIP Before a mobile host initiates the actual handoff process, it makes use of the information contained in the MH-Reply message. The mobile host selects the candidate ARs among the ARs contained in the message. If the radio access technology that the mobile host is capable of matches with that of an AR, it selects the AR as its candidate AR. Based on the L3 information of the selected ARs (with optional QoS field), the mobile host scans ARs selectively according to its preference. Example of the mobile host's preference on selecting candidate ARs are as follows. Note that there are other criteria for preference not considered here, and how to prioritize those criteria is out of the scope of this document. 1) Link speed of radio access technologies The mobile host may prefer an AR that provides the higher link speed. 2) QoS support The mobile host may prefer an AR that can support its QoS requirement. 3) Administrative or security domain to which the mobile host will move. If the administrative domain of the candidate AR is different so that the mobile host is not allowed to handoff, or it requires additional security procedure, the mobile host may put the AR's preference as the lowest. 4) The topological distance between ARs. If the mobile host wants to use the fast handoff protocol and it has several candidate ARs, it may prefer the closest AR as its new AR. To handover fast, there is a way using this ARIP with Fast handoff (The details are explained in section 5.1.) On the other hand, there is another way which is explained below. After the mobile host selects the candidate ARs by using the MH-reply message, the mobile host initiates a Router Solicitation for Proxy (RtSolPr) message to the PAR. After receiving several Proxy Router Advertisements (PrRtAdv) messages of the mobile host's candidate ARs from the PAR, the mobile host sends a Prepare Fast Binding Update (PFBU) message to PAR. The PFBU message contains the newly formed CoA (NCoA) by the mobile host, if the stateless address configuration is used. After PFBU message is sended, the HI message can be transmitted from PAR to NAR. When the NAR receives the HI message containing the NCoA, it has to perform the DAD and starts acts as a proxy for the mobile host. If the DAD is successful, the NAR transmits a Handover Acknowledge (HAck) to the PAR to confirm the NCoA. Then, the PAR transmits a Prepare Fast Binding Acknowledgement (PFBack) message which is newly defined in Suh, et al [Page 14] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 this document instead of a Fast Binding Acknowledgement (FBack) message for confirmation of the successful DAD via its wireless link. In contrast to the Fast Handover protocol, as a result of successful exchanging the PFBU and PFBack messages, the PAR does not start to forward packets to the NAR even after PFBack. At this point, it just establishes a binding between the PCoA and the NCoA, but marks its state as 'freeze'. The aim of newly introduced two messages, the PFBU and the PFBack messages, is to let candidate ARs for NAR to perform the DAD for the NCoA prior to occurrence of the L2 trigger. Normally the DAD procedure adds extra delays to a handoff. Whenever the mobile host receives an L2 trigger, it can initiate the Fast Handover procedure by simply sending a FBU message. When the PAR receives a FBU message it reactivates the 'freeze' binding, send FBack to MN and NAR, and starts to forward the packets to the NAR. Performing the DAD for all possible candidate NCoAs requires some extra overhead compared to the basic fast Handover protocol. But, this scheme reduces the total handoff latency and solves the "ping-pong" problem in which a mobile host moves around the boundary of wireless coverage of ARs. Figure 3 shows an example network to illustrate the reduced handoff latency with the aid of ARIP. In Figure 3, the wireless access network managed by AR1 uses the IEEE 802.11a WLAN and the channel number is 1. The wireless access network managed by AR2 uses the IEEE 802.11b WLAN and the channel number is 1. The wireless access network of AR3 supports the IEEE 802.11a WLAN with channel 4 and the 802.11b WLAN with channel 5 simultaneously. AR4 provides the IEEE 802.11g WLAN access network with channel 9. The mobile host is equipped with a wireless pc combo card which supports all of the IEEE 802.11a/b/g, but only one can be used at a time. By the operation of the ARIP protocol, each AR learns the information on its neighbor ARs. For example, AR2 may have the following knowledge about its neighbor ARs. - (Global address of AR1, IEEE 802.11a WLAN with channel 1, ESSID of the WLAN, options) - (Global address of AR3, IEEE 802.11a WLAN with channel 4 and IEEE 802.11b WLAN with channel 5, each ESSID of the WLANs, options) Suh, et al [Page 15] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 As shown in Figure 3, the mobile host moves from AR2 to AR3. When the mobile host detects that the signal strength from AR2 is getting weak, it may sends a MH-Request message to AR2 for an MH-reply message. By the MH-reply message from AR2 the mobile host learns the information on its candidate ARs and determines its preference. Assuming that the mobile host's preference is AR1's 802.11a, AR3's 802.11a, and AR3's 802.11b in an ascending order, when the mobile host initiates the L2 handoff process, it first turns on its 802.11a radio and scans the channel 1 of the IEEE 802.11a WLAN to find AR1. Because the mobile host is out of transmission range of AR1's wireless access network and moving into the coverage area of AR3's wireless access network, the scan fails. Then, the mobile host scans channel 4 of the IEEE 802.11a WLAN. And then it turns on the IEEE 802.11b radio and scans channel 5. If the mobile host finds either one of the wireless access networks provides by AR3, it can select one according to its preference. After finishing the L2 handoff, the mobile host proceeds to initiate the L3 handoff. Normal L2 handoff without the ARIP protocol may requires more time for the full scan of all channels of the IEEE 802.11a and b WLANs. +-----------------------+ / \ / \ + IP Network + | (IPv4/IPv6) | + + \ / \ / +-----------------------+ | +--+ | +------+ | | +-------+ | / \ | | | | | +-----+ | | +-----+ | R1 | | | | R2 | +-----+ | | +-----+ | | | | | | +------+ +--+ | | +--+ +--------+ | +----------+| | | | +---------+ | | | || | | | | | | +---V-+ +V--V-+ +V---V+ +V----+ | AR1 | | AR2 | | AR3 | | AR4 | +-----+ +-----+ +-----+ +-----+ 802.11a 802.11b 802.11a/b 802.11g channel1 channel1 channel4/5 channel9 +----+ | MH | M-1 M-2 +----+ ---------> ---------> Movement Figure 3: Example of handoff operation Suh, et al [Page 16] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 5. Interoperability with Other Technology 5.1 Interoperability with the Mobile IPv6 Fast Handover The Mobile IPv6 Fast Handover protocol may make use of the ARIP framework to reduce the L2 handoff latency as well as the L3 handoff latency. Basically the ARIP provides the reduced L2 handoff latency, and thus only the methods to reduce the L3 handoff are discussed in this section. The mobile host can obtain the information on neighboring ARs of the current AR by the ARIP operation. The information includes the L2 identifier (when the IEEE 802.11 WLAN AP provides the wireless access, this corresponds to L2 identifier of an AP) and L3 identifier of each neighboring AR. Thus, the RAT procedure, which maps between the L2 identifier of wireless interface of an AR (or an AP) and L3 identifier of that AR, is unnecessary and can be avoided to reduce the handoff latency. The process of the Mobile IPv6 Fast Handover with the ARIP is as follows. The PAR and NAR is a geographically adjacent neighbor AR to each other. They exchange their L2 and L3 information with each other using the ARIP. When the Pre-L2 Trigger is occurred, mobile host transmits a MH-Request message to the current AR (PAR). The Pre-L2 Trigger is an event like L2 Trigger in the Mobile IPv6 Fast Handover, but it can occur at anytime before the L2 Trigger. The Pre-L2 Trigger can be occurred rightly after at the time of completing the handoff to the PAR. When the mobile host receives the MH-Reply message containing the information on neighbor ARs of the PAR, it selects several ARs as its candidate ARs according to the rule specified in section 4.3. For these ARs, the mobile host initiates a basic Fast Handover process by sending a Router Solicitation for Proxy (RtSolPr) message to the PAR. Because the mobile host already knows the pair of L2 identifier and L3 identifier of each candidate AR, there is no need to actually scan the channels and perform the RAT procedure. After receiving several Proxy Router Advertisements (PrRtAdv) messages of the mobile host's candidate ARs from the PAR, the mobile host selects one AR as its NAR and transmits a FBU message to it. After this, the whole process is the same as the basic Fast Handovers. 6. Security Considerations The security considerations resulting from the use of this framework do not offer any higher level of security in basic mobile host operation. Therefore, in the next version of this document will include appropriate level of security for ARIP operations. Acknowledgement The authors would like to thank Young-Joo Suh, Dong-Hee Kwon, and Woo-Jae Kim for providing input to the draft and comments they had. Suh, et al [Page 17] INTERNET-DRAFT Access Router Information Protocol(ARIP) October 2003 Reference [1] A. Mishra et. al., "An Empirical Analysis of the IEEE 802.11 MAC Layer Handoff Process", ACM Computer Communication Review, 2000. [2] H. Chaskar et. al., "Candidate Access Router Discovery", draft-ietf-seamoby-card-protocol-04.txt, September 2003. [3] C. Hedrick et. al., "Routing Information Protocol", RFC 1058, June 1988. [4] D. Johnson et. al., "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-24.txt, June 2003. [5] D. Funato et. al., "Geographically Adjacent Access Router Discovery Protocol", draft-funato-seamoby-gaard-01.txt, June 2002. [6] Dommety G. (editor), Yegin A., Perkins C., Tsirtsis G., El- Malki K., and Khalil K., "Fast Handovers for Mobile IPv6", draft-ietf-mobileip-fast-mipv6-08.txt, October 2003, Work In Progress [7] Hesham Soliman, Claude Castelluccia, Karim El-Malki, and Ludovic Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mobileip-hmipv6-08.txt, June 2003, Work In Progress Author's Address Questions about this memo can be directed to: Kyungjoo Suh (Joo Suh) Global Standards and Strategy team Telecommunication R & D Center Samsung Electronics Co., LTD. Dong Suwon P.O. BOX 105, 416, Maetan-3dong, Paldal-gu, Suwon-city, Gyeonggi-do, 442-600 Korea Phone: +82-31-279-5123 Email: joo.suh@samsung.com Fax: +82-31-279-5130 Youngjun Park Email: youngjun74.park@samsung.com Jaekwon Oh Email: jaekwon.oh@samsung.com Eun-Hui Bae Email: eanny.bae@samsung.com Suh, et al [Page 18]