MIP6 WG S. Daniel Park Internet Draft Samsung Electronics Expires: 30 July 2004 Eric Njedjou France Telecom R&D Nicolas Montavont LSIIT 31 January 2004 L2 Triggers Optimized Mobile IPv6 Vertical Handover: The 802.11/GPRS Example 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 describes a mechanism that extends Mobile IPv6 protocol to smoothly manage handovers for Mobile Nodes equipped with multiple interfaces and moving across different and heterogeneous links. For this purpose, the document provides indications on how to use the link events information to optimize L3 movement detection. Park, Njedjou, Montavont Expires - July 2004 [Page 1] Internet Draft 802.11 and GPRS Handover January 2004 Table of Contents 1. Introduction...................................................3 2. Conventions used in this document..............................4 3. Terminology....................................................4 4. Standard mobile IPv6 node behavior for movement detection and handover...........................................................5 4.1 Limitation of the standard mechanism.......................5 5. Layer 2 Triggers / Hints.......................................6 5.1 Introduction and Background................................6 5.2 Differences between L2 Triggers and L2 Hints...............7 5.3 Some Definitions...........................................7 6. Link triggers/hints optimized mobile IPv6 vertical handover....8 6.1 How the l2 information should be utilized to enhance movement detection and handover.................................8 6.1.1 Use of LINK-UP trigger...................................8 6.1.2 Use of the LINK-TYPE hint................................9 6.1.3 Use of LINK-DOWN trigger.................................9 6.2 Previously defined optimizations to movement detection....10 7. Example of 802.11 / GPRS handover.............................10 7.1 GPRS and 802.11 coexistence...............................10 7.2 GPRS and 802.11 link triggers/hints.......................11 7.2.1 GPRS....................................................11 7.2.2 802.11..................................................12 7.2.3 LINK-TYPE indication....................................13 7.3 Mobile IPv6 node recommended behavior from 802.11 to GPRS.13 7.4 Mobile IPv6 node recommended behavior from GPRS to 802.11.14 8. Security Considerations.......................................15 9. References....................................................15 9.1 Normative References......................................15 9.2 Informative References....................................15 Park, Njedjou, Montavont Expires - July 2004 [Page 2] Internet Draft 802.11 and GPRS Handover January 2004 1. Introduction In order to provide sessions continuity for wireless users, Mobile IPv6 protocol [MIPv6] is currently available. It is capable of handling IP handovers between different subnets, in a transparent way for higher-level connections. Various solutions have been developed within the IETF to provide signaling and handoff optimizations to [MIPv6], such as Hierarchical Mobility ([HMIPv6]) and Fast Handoffs ([FMIPv6]). [FMIPv6] allows a Mobile Node to anticipate its attachment with a prospective default router (behind a new link), by helping to prepare the new IP configuration in advance, in a way to enable the Mobile Node to send and receive packets as soon as it attaches to the new link. [FMIPv6] assumes that this new IP configuration is to be received through the currently used network interface. [FMIPv6] requires adding additional support to IPv6 implementation in routers, which already deployed IPv6 infrastructure may not be ready to afford. Still, today, mobile users require ubiquitous Internet access, which implies being able to support smooth handovers from one IP subnet to another each serving a radio coverage of a different technology. Mobile Nodes are more and more equipped with several interfaces of different L2 technologies. As such they may be reachable through multiple links at the same time or alternatively use each interface depending on the network environment. It is then possible to totally prepare, and more importantly, build the IP configuration to be used on a new link, while still using the currently active care-of- address (built on another link). In this case, there may be no need to use the RtSolPr/PrRtAdv exchange to learn the IP configuration to be used on the new link as this can be directly done with the new Access Router (AR) by using a second L2 interface connected to the AP serving this new link. Therefore, the new IP configuration of the target interface can be done without interfering the communication on the currently used interface if it is still connected to the network. For these reasons, [FMPv6] may not be useful for vertical handover, when the new IP configuration can be done before of the actual vertical handover. Nevertheless, the handover still needs to be made smoothly. And, In order to optimally achieve a MIPv6 vertical handoff, the generic, link-layer independent movement detection mechanism as described in Park, Njedjou, Montavont Expires - July 2004 [Page 3] Internet Draft 802.11 and GPRS Handover January 2004 [MIPv6] appears not sufficient. Effectively, it concentrates on detecting Layer3 movement while timely knowledge of L2 events might be beneficial to assist in seamless operations. In this document, we describe a link-layer triggers optimized movement detection process for Mobile IPv6 protocol. For this purpose, we briefly describe the standard [MIPv6] movement detection process and exhibit its limits. We then introduce the link triggers and hints, before describing the enhanced movement detection algorithm. We further apply the optimization to the GPRS/802.11 Mobile IPv6 handover case after having identified the link triggers/hints to be used for both technologies. 2. Conventions used in this document 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 [RFC 2119]. 3. Terminology Access Point (AP) An Access Point is a layer 2 device that is connected to the wired Network and offers the wireless link connection to the MN. Access Router (AR) A router residing on the edge of an Access Network and connected to one or more APs. An AR offers IP connectivity to Mobile Nodes. GGSN Gateway GPRS Support Node. A router between the GPRS network and an external network (i.e, the Internet). The GGSN is an example of an Access Network Gateway. GPRS General Packet Radio Service. Packet-switched data transmission service on top of the GSM network. Layer 2 Handoff (L2 Handoff) A process of terminating existing link layer connectivity and obtaining new one. This handoff alone is transparent to the routing at the IP layer. Park, Njedjou, Montavont Expires - July 2004 [Page 4] Internet Draft 802.11 and GPRS Handover January 2004 Layer 3 Handoff (L3 Handoff) A process of terminating existing network layer connectivity and obtaining new one. Mobile Node (MN) A host or router that changes its point of attachment from one network or subnet to another 4. Standard mobile IPv6 node behavior for movement detection and handover Section 11.5 of [MIPv6] describes a generic movement detection process, that uses the absence of due Router Advertisements (RAs) and Neighbor Unreachability Detection (NUD) to detect when the default router is no longer reachable. This triggers Router Discovery, initiated by the sending of RAs, to learn about the presence of a candidate new default router. After discovering new routers, the mobile node performs DAD for link-local address, selects a new router, performs prefix discovery for that router to form a new care-of address and, as a consequence, performs the binding update and route optimization. 4.1 Limitation of the standard mechanism The only use of L3 information in [MIPv6] movement detection algorithm has the following consequences; 1. A Mobile Node is not able to detect that its default router is no longer reachable unless - The RA Advertisement interval expires without the MN receiving any other advertisement. - It has packets to send 2. Moreover, a Mobile Node is not able to detect that it has lost attachment to its default router even with such hints as the reception of a new RA with a new prefix. Effectively, the reception of a new RA advertising a new prefix does not determine a lost of L3 connectivity as there might be multiple routers sharing the link. Park, Njedjou, Montavont Expires - July 2004 [Page 5] Internet Draft 802.11 and GPRS Handover January 2004 3. A Mobile Node has to wait until it receives a RA to acquire knowledge of the presence of a new router. Still, for the purpose of achieving smooth handovers from one IP subnet to another, it might be unaffordable for some time-constrained applications to realize that reachability with the default router has been lost, long after it really had. It may be unaffordable as well for such applications to wait for received RAs before discovering new routers and form a new care-of address. To quickly detect any L3 movement (i.e loss of attachment with default router and discovery of new router), link-layer indication might be precious. However current Mobile IPv6 protocol [MIPv6] does not indicate how to make use of these L2 indications , well kown as triggers, but consider it as an item for further studies. The two next sections are an attempt to address this well known deficiency to [MIPv6]. 5. Layer 2 Triggers / Hints 5.1 Introduction and Background L2 triggers were introduced in the IETF terminology a long time ago. In [manyfloks], the concept of L2 triggers was defined to optimize IP handovers between access points belonging to different subnets. In this context, five L2 triggers were proposed: two messages in reaction to a L2 handover/connection establishment (Link up and Link Down) and three messages that are issued before a L2 handover occurs (Source Trigger, Target Trigger or Mobile Trigger). These pre- handover messages were designed to help L3 operations because they allowed the anticipation of potential movements. The Fast Handoffs specification, [FMIPv6], which proposes extension to Standard Mobile IP to support smooth handover, describes a message exchange between the MN and its old and new ARs to enhance movement operation. The mechanism is based on an anticipation of movement where the MN is supposed to discover close APs. The way the MN discovers its neighboring APs is not defined in the document. Moreover, the documents says that L2 triggering can be used for anticipation and start of the Fast Handover mechanism, but as of today no general L2 trigger specification exists. [802.11fh] details how to perform a MIPv6 fast handover over IEEE 802.11 networks. The feasability of the anticipation in IEEE 802.11 Park, Njedjou, Montavont Expires - July 2004 [Page 6] Internet Draft 802.11 and GPRS Handover January 2004 networks is studied and a specific L2 trigger to IEEE 802.11 is proposed. It is also to be noted that the use of L2 information by the IP layer was discussed in MANET Working Group for ad-hoc devices. L2 triggering and L2 parameters were identified as being capable of enhancing the routing protocol in an ad-hoc environment; If a node has different choices to compute its next hop, the intensity of signal between itself and its neighbors could be considered in the choice of the next hop. More recently, a new Working Group has been setting up, called Detecting Network Attachment (DNA), which aims is to determine the operations needed to faster discover the IPv6 subnet a MN is to connect to. In this context, the information to be extracted from L2 for use by L3 has been discussed in [L2Hint] and [Parameters]. The goal of this work in progress is to provide a catalog of L2 triggers and L2 hints available at the link layer. We can expect that this catalog will lead to a generic abstraction of the L2 technologies that can be used by the IP layer for different purposes: IP attachment detection, handover optimization, anticipation of movement, etc. Such an abstraction will consist in events and states of the L2, as well as L2 parameters. An abstraction aims at defining optimized L3 operations over any L2 technologies, independently from these technologies. 5.2 Differences between L2 Triggers and L2 Hints In the specification of L2-L3 interaction, a distinction is made between L2 Triggers and L2 Hints; a L2 Trigger is an event that occured at the Link Layer that is forwarded to the upper layer (Layer 3). This event can help the Layer 3 to instantaneously react by initiating an L3 operation (such as to trigger a L3 handover). A L2 Hint is an information that can be optionally transported with a L2 trigger and that can help the Layer 3 enhance triggered operations. Therefore, it is a supplementary information transported with the L2 Trigger that even help to make L3 link discovery faster. 5.3 Some Definitions Park, Njedjou, Montavont Expires - July 2004 [Page 7] Internet Draft 802.11 and GPRS Handover January 2004 LINK-UP trigger: This event corresponds to the establishment of a new L2 link, which allows IP communication over it. This is typically a new full connection between the MN and an AP. LINK-DOWN trigger: This event corresponds to a L2 Link that has been broken down. This typically happens when a current connection between the MN and an AP has been terminated. The interface which generates this trigger can not be used for communication until a connection with an AP is made (LINK UP). LINK-TYPE hint: The type of the technology from which the trigger was generated, e.g., GPRS or WLAN. 6. Link triggers/hints optimized mobile IPv6 vertical handover 6.1 How the l2 information should be utilized to enhance movement detection and handover In this section, we try to show how information extracted from lower layer protocols, namely triggers and hints, can provide better performance for the movement detection algorithm. The gain in performance is not measured here but could be the subject of other documents. 6.1.1 Use of LINK-UP trigger When a LINK-UP indication is received from L2, the Mobile Node immediately sends a Router Solicitation message (rather than waiting for any Router Advertisement message to be received). On some types of links, routers could be configured in a way to avoid sending unsolicited Router Solicitation messages or to sending them at a frequency not adapted to mobility demands. Waiting for RAs in such cases could be really prejudicial for the performance of Mobile IPv6. It is to be noted that the random time advised by RFC 2461 between 0 and MAX_ROUTER_SOLICITATION_DELAY before sending any RS can be avoided for optimization purposes, as it is accepted that Mobile Nodes constraints render it essential the need to have the shortest possible router discovery time. The LINK UP indication should be accompanied by a LINK-TYPE indication. The use of the LINK-TYPE parameter is explained later in this section. Park, Njedjou, Montavont Expires - July 2004 [Page 8] Internet Draft 802.11 and GPRS Handover January 2004 The Mobile Node then processes the RA received as response to the RS, builds a table where it associates the RA information on the new link with the LINK-TYPE parameter, then performs DAD, Prefix Discovery, IP address auto-configuration, care-of-address construction as usual. 6.1.2 Use of the LINK-TYPE hint A Mobile Node should send at least one RS each time it discovers a new link. In doing so, when at least two RAs have been received on different links, and care-of-addresses have been correspondingly built, the Mobile Node can use the LINK-TYPE indication associated to each RA (thus to each Care-of-address) in the selection of the primary care-of address as described in [MIPv6]. In such a way, the Mobile Node would be able to choose to have its primary care-of- address on one link offering as an example, better characteristics with respect to bandwidth and latency, than any other link available. This is why it makes sense to immediately proceed to sending a Router Solicitation when a LINK-UP indication is received, as the link features deducted from the LINK-TYPE hint can lead to the preference of the newly discovered link for the choice of the primary care-of-address. It is to be reminded that the intent here is not to specify how the care-of-address should be selected but rather to indicate elements that can help this selection. 6.1.3 Use of LINK-DOWN trigger When a LINK-DOWN indication is received from L2 the Mobile Node should immediately invalidate the care-of-address associated with the link in question, this in accordance with [MIPv6], re-select a new primary care-of-address if available, or wait for the next LINK- UP indication to proceed to active Router Discovery again. This avoid loosing the time corresponding to the delay experienced in waiting for the Mobile Node to realize that it is no more receiving any RA added to the delay for performing any IP connectivity check as NUD. If the Mobile Node was already engaged in a NUD check, upon reception of a LINK-DOWN indication for the link associated with the router the check has been initiated for, the check can be Park, Njedjou, Montavont Expires - July 2004 [Page 9] Internet Draft 802.11 and GPRS Handover January 2004 immediately aborted as the result of NUD can be anticipated by the information that the link is lost. 6.2 Previously defined optimizations to movement detection A couple of Mobile IPv6 movement detection optimisations schemes have been suggested within the IETF: [FastRA] and [LinkID] seek to reduce the time taken to perform Router Discovery but from a layer 3 perspective. As for [FRD], it makes use of Layer 2 information to accelerate the process of Router Discovery but requires modifications to L2 technologies and especially Access Points. 7. Example of 802.11 / GPRS handover 7.1 GPRS and 802.11 coexistence The increasing popularity of IEEE 802.11-based WLANs, which are deployed in such areas as Hot Spots, combined to the recent advent of 2.5G wide-area wireless networks such as GPRS, has created the need to judiciously make use of these two wireless IP access technologies by taking advantage of their complementarity for moving users. While it is indicated to let the l2 handle the horizontal handover where there is no need of configuration change at IP layer as it is the case in most 802.11b and GPRS deployment scenarios, such vertical handoffs as GPRS to WLAN or vice-versa would quite often require a change of subnet. And from most views, Mobile IP looks an appropriate candidate to help perform this specific inter-technology handoff. Based on the link triggers and hints we've specified in the precedent section for each of the aforementioned technologies, we hereafter apply the optimized Mobile IPv6 movement detection process presented in section 3 to the GPRS/WLAN handoff case. Park, Njedjou, Montavont Expires - July 2004 [Page 10] Internet Draft 802.11 and GPRS Handover January 2004 ------- / \ | Internet +-------------------------------------+ \ / | ---+--- \ | | \ | | +------------+ | | | | +--+--+ +---+--+ +--+--+ | AR1 | | GGSN | | AR2 | +--+--+ +---+--+ +--+--+ | | | | \ GPRS | | \ | | \ | +-+--+ +----+ +-+--+ +--+-+ | AP |.......| AP | |SGSN| | AP | +----+ +----+ * +----+ * +----+ . . * . * . . . * . * . . . * . * . +----+ * +----+ * +----+ | MN |============> * ===> | MN | ====> | MN | +----+ movement * +----+ * +----+ * * 802.11 coverage * * 802.11 coverage * * * * * * * * * * * * * * * * * Fig. Movement scenario of a MN between GPRS and 802.11 coverage 7.2 GPRS and 802.11 link triggers/hints We identify the link triggers/hints to be used for each technology. 7.2.1 GPRS LINK-UP indication A MN that wants to establish IP level connections through its GPRS interface should first request the GPRS network to settle the necessary soft state mechanism (GPRS tunneling Protocol) between the Park, Njedjou, Montavont Expires - July 2004 [Page 11] Internet Draft 802.11 and GPRS Handover January 2004 GPRS AP (SGSN) it is attached to and the AR (GGSN) corresponding to the type of network it is requesting connection for (Intranet, Internet). This routing mechanism between the SGSN and the GGSN enable the forwarding of IP packets between the MN and external data networks as the Internet or an Intranet (via the GGSN). The process by which this is made possible is designated as a PDP Context activation. It corresponds to the IP configuration process. A PDP Context is considered activated on the MT side as soon as an "Activate PDP Context Accept" message has been received from the SGSN. As such, the reception of this message can be considered as a LINK-UP indication for the MN GPRS/UMTS interface. LINK-DOWN indication The GPRS network can initiate a PDP context deactivation at any time. A "Deactivate PDP Context Request" message is then sent by the SGSN (GPRS AP). The reception of this message is an indication that the IP configuration of the MN's GPRS interface is about to be deleted by the network. As such, the reception of the message can be considered as a LINK- DOWN trigger for the GPRS/UMTS interface 7.2.2 802.11 LINK-UP indication In order to have an IP level connection through an IEEE 802.11 network, a MN must be associated with an Access Point. The last messages exchanged between the MN and a target Access Point to establish a connection is a (Re)Association Response sent from the Access Point to the MN. This message indicates to the MN the status of the association (accepted or rejected). If the association is accepted, then the MN can usually start to send and receive IP packets through the Access Point. But, if the MN is connecting to an Access Point which uses enhanced security mechanisms as defined in [IEEE 802.11i] (MN enters a Robust Security Network), the reception of the (Re)Association Response is not the relevant trigger that informs that IP packets can be exchanged. In a Robust Security Network, an IEEE 802.1x port is used on each station (Access Point and MN) to filter packets: while a Park, Njedjou, Montavont Expires - July 2004 [Page 12] Internet Draft 802.11 and GPRS Handover January 2004 mutual authentication of both the Access Point and the MN is not done, all data packets are discarded. Instead, EAP packets are used to transport authentication. Upon the reception of an "EAP-accept" message with a successful status, the data packets are authorized to use the association between the access point and the MN. To summarize this section, in a non-secure 802.11 network, a successful (re)association response can be taken as a Link-Up trigger while in 802.1x, it is the EAP-accept message which is taken as a Link-Up trigger. LINK-DOWN indication To allow IP packets exchange with a MN using an IEEE 802.11 interface, the MN has to be authenticated and associated with an AP. As soon as the MN is no more authenticated or associated to an AP, IP connectivity is broken. Upon the reception of "Disassociation" message, the MN is considered disconnected and then has no more IP connectivity through the AP. Therefore, the "Disassociation" message is to be considered as a Link-Down trigger. It has to be noted that a Disassociation message is not required to be sent each time a MN disassociates from an AP. In IEEE 802.11, if a MN measures a poor signal with its current AP, it can disassociates by itself and no messages are sent. 7.2.3 LINK-TYPE indication The LINK-TYPE indication would generally not be directly provided by the L2. Each implementation of the L2 messages extraction will have to figure out how it is able to fetch the information. 7.3 Mobile IPv6 node recommended behavior from 802.11 to GPRS Here the Mobile Node steps outside of the 802.11b Access Point radio range it is attached to. It is assumed that no other in-range 802.11b AP is present to offer connectivity. At some time in the movement, a "disassociation" beacon will be received by the host, triggering the MN to immediately invalidate the care-of-address associated with the 802.11b interface, and select the care-of-address associated to GPRS as its primary then Park, Njedjou, Montavont Expires - July 2004 [Page 13] Internet Draft 802.11 and GPRS Handover January 2004 register it to its Home Agent. This assumes that the GPRS interface was still up. Note that power consumption considerations on Mobile Terminals as laptops and PDAs can dictate the need for deactivation of all interfaces but the one associated to the primary care-of-address. In such a case, smooth handoff operation require exploiting any hint from 802.11b layer that the MN will soon be de-associated. Reception of such a hint then anticipates the build-up of the PDP context that will be necessary to establish the GPRS care-of-address (A "Activate PDP context Request" message is sent to the SGSN): once the "Activate PDP context Accept" message is received from the network, the MN sends a RS to the IPv6 GGSN to receive router prefix information and form new care-of-address. DAD can be avoided here as the shared link concept utilized in such networks as 802.11b is not valid in 3GPP networks where every MN holds a "private" link-layer connectivity with the AP (i.e unknown to other MNs that are GPRS- connected to the same AP). The GPRS IPv6 address is then selected as primary and registered to the HA. It may happen that the 802.11b link get down before all the previous process is performed. Still, it is better to anticipate the loss of 802.11 link connection as this results in reduced packets loss. 7.4 Mobile IPv6 node recommended behavior from GPRS to 802.11 This step represents the Mobile Node arriving inside a 802.11 network. Start of this step is indicated on the Mobile Node by the reception of an "association" or "EAP-accept" message, coming from the nearest in-range Access Point. This triggers the sending by the MN of a Router Solicitation message to check router presence on the newly discovered 802.11 link and receive prefix information in order to build care-of-address after performing Duplicate Address Detection. Next, the registration process with the Home Agent is completed. For smooth handoff operation, [MIPv6] does not preclude the use of a still valid previous primary care-of-address for the reception of packets after registering a new primary care-of-address to the HA. Therefore, the Mobile Node can keep its GPRS interface and associated care-of-address active for an additional period of time that will have to be tuned according to such criteria as the GPRS link latency. Effectively, the latency encountered on such links can cause the packets sent before the new care-of-address was registered to arrive with delay. Park, Njedjou, Montavont Expires - July 2004 [Page 14] Internet Draft 802.11 and GPRS Handover January 2004 8. Security Considerations Implementations of the L2 triggers extraction should guarantee that the information received at the IP layer is originated from the MN L2 stack rather than sent by a malicious node. 9. References 9.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [MIPv6] D. Johnson, C. Perkins, J. Arkko. Mobility Support in IPv6. Internet Draft (work in progress), July 2003. [WLAN] "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999 Edition. [GPRS] 3GPP TS 03.60 (release 1998) "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS) Service description; Stage 2", version 7.9.0 [REQ] M. Wasserman, Ed. "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002 [802.11i] IEEE Sd 802.11i/D7.0, Medium Access Control (MAC) Security Enhancements, October 2003. [802.11fh] Peter J. McCann, Mobile IPv6 Fast Handover for 802.11 networks, draft-mccan-mobile-802.11fh-01.txt, expired in May 2003. 9.2 Informative References [MoveDetect]G. Delay, J. Choi, "Movement Detection Optimization in Mobile IPv6", Internet Draft, May 2003. Park, Njedjou, Montavont Expires - July 2004 [Page 15] Internet Draft 802.11 and GPRS Handover January 2004 [FASTRA] M. Khalil, J. Kempf, B. Pentland. "IPv6 Fast Router Advertisement (FastRA) ", Internet Draft (work in progress), October 2002. [LINKID] B. Pentland, G Daley, J Choi. "Router Advertisement Link Identification for Mobile IPv6 Movement Detection", Internet Draft (work in progress), May 2003 [FRD] J. Choi, D. Shin. "Fast Router Discovery with RA Caching in AP", Internet Draft (work in progress), Feb 2003. [manyfolks] A. Yegin, D. Funato, K. El Malki, Y. Gwon, J. Kempf, M. Pettersson, P.Roberts, H. Soliman, A. Takeshita, "Supporting Optimized Handover for IP Mobility - Requirements for Underlying Systems", draft-manyfolks- l2-mobilereq-02.txt, expired December 2002. [fmipv6] R. Koodli et al, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-00.txt, October 2003. [Link Hints]Alper Yegin, E. Njedjou, S. Veerepalli, N. Montavont, T. Noel, "Link-layer Hints for Detecting Network Attachments", draft-yegin-dna-l2-hints-00.txt, November 2003. [Parameter] P. Bertin, T. Noel, N. Montavont, "Parameters for Link Hints", draft-bertin-hints-params-00.txt, September 2003. Acknowledgements Leave your name Park, Njedjou, Montavont Expires - July 2004 [Page 16] Internet Draft 802.11 and GPRS Handover January 2004 Authors' Addresses Soohong Daniel Park Samsung Electronics 416, Maetan-3dong, Youngtong-gu, Suwon Korea Phone: +82 31 200 4508 Email: soohong.park@samsung.com Eric Njedjou France Telecom R&D 4, Rue du Clos Courtel BP 91226 35512 Cesson-S‰vign‰ Fr&nce Phone: +33 299124202 Email: eric.njedjou@francetelecom.com URL: http://perso.rd.francetelecom.fr Nicolas Montavont LSIIT Universit‰ Louis Pasteur Pole API, bureau C430 Boulevard Sebastien Brant Illkirch 67400 FranceT Phone: (33) 390244587 Email:montavont@dpt-info.u-strasbg.fr URL: www-r2.u-strasbg.fr/~montavont Park, Njedjou, Montavont Expires - July 2004 [Page 17] Internet Draft 802.11 and GPRS Handover January 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). 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. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. Park, Njedjou, Montavont Expires - July 2004 [Page 18] Internet Draft 802.11 and GPRS Handover January 2004 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Park, Njedjou, Montavont Expires - July 2004 [Page 19]