IETF MIPSHOP Working Group Internet Draft Youngjun Park Kyungjoo Suh Document: draft-park-mipshop-netho-00.txt SAMSUNG Electronics Expires: July 2004 January 2004 Network-initiated Handover Framework for FMIPv6 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [i]. 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 In this memo, a framework provides network-initiated handover to FMIPv6 MN (mobile node) in IEEE 802.11 wireless LAN is suggested. Basic concept and mechanism of layer-2/layer-3 handover and IAPP are introduced. Suggested framework is integration of these three protocols and additional primitives. Park and Suh Expires - July 2004 [Page 1] Network-initiated Handover Framework for FMIPv6 January 2004 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 [ii]. Table of Contents 1. Introduction.................................................3 2. Terminology..................................................3 3. Handover of Mobile Node......................................4 3.1. Layer-2 Handover and Layer-3 Handover...................4 3.2. IAPP (Inter-Access Point Protocol)......................5 4. Network-initiated Handover Framwork..........................6 4.1. Suggested Handover Framework............................6 4.2. New Management Primivites...............................8 5. Error Handling..............................................10 Security Considerations........................................10 References.....................................................10 Author's Addresses.............................................11 Park and Suh Expires - July 2004 [Page 2] Network-initiated Handover Framework for FMIPv6 January 2004 1. Introduction FMIPv6 is introduced to achieve low handover latency. An idea to configure new CoA (Care-of Address) prior to layer-2 handover is suggested. Moreover, packet forwarding is used via bidirectional tunnel between previous access router and new access router to support seamless handover. In FMIPv6, Layer-2 events gives hints when to invoke handover in IP layer. One of the popular situations where Mobile IP is employed is wireless LAN. When FMIPv6 operates on the IEEE (Institute of Electrical and Electronics Engineers) 802.11 wireless LAN protocol, reassociation to the new access router is a sort of a layer-2 event. The information related to this layer-2 event can be exchanged between the access routers when IEEE 802.11 is used in conjunction with IAPP (Inter-Access Point Protocol) which is defined in IEEE 802.11F. In this memo, we suggest a framework in which MN can perform FMIPv6 network-initiated handover with very low latency by using IEEE 802.11 and IEEE 802.11F. 2. Terminology AP (Access Point): Layer-2 MAC (Medium Access Control) device which provides wireless access to MN via the WM (wireless medium). APs are interconnected by wired link called DS (Distribution System). APME (AP Management Entity): General management entity which controls overall functions of AP. APME communicates with other APME by using IAPP via IAPP SAP (Service Access Point). Also it manages MAC layer and physical layer by exchanging management primitives with MLME and PLME (Physical Layer Management Entity) of AP respectively. AR (Access Router): Layer-3 IP device which provides IP connectivity and default routing functions to MN. IAPP (Inter-Access Point Protocol): Application layer protocol defined to provide communications among different APs. IAPP packets convey APME information related to the association, reassociation, and disassociation of MNs. Park and Suh Expires - July 2004 [Page 3] Network-initiated Handover Framework for FMIPv6 January 2004 MLME (MAC Layer Management Entity): Management entity which controls functions performed at the IEEE 802.11 MAC layer of both AP and MN. All APs have two MLME, one for WM MAC and the other for DS MAC. In this memo, only activity of WM MLME is discussed. SME (Station Management Entity): General management entity which controls overall functions of AP. It manages MAC layer and physical layer by exchanging management primitives with MLME and PLME (Physical Layer Management Entity) of MN respectively. 3. Handover of Mobile Node 3.1. Layer-2 Handover and Layer-3 Handover "Reassociation" is layer-2 handover in IEEE 802.11 wireless LAN environment. Reassociation is defined to be achieved by the exchange of management primitives between APME/SME and MLME and the exchange of frame between the MAC layer of AP and MN. Detailed primitives and transported parameters are described in [v]. (1) SME of MN issues primitive which requests reassociation to MLME of MN. (2) MLME of MN sends "Reassociation Request frame" to MLME of new AP. (3) MLME of new AP sends back "Reassociation Response frame" after it verifies whether the MN is pre-authenticated. (4) MLME of MN reports primitive which confirms reassociation to SME. (5) APME of new AP is notified reassociation of MN after MLME of new AP received acknowledgement for Reassociation Response frame. The reassociation process of IEEE 802.11 wireless LAN is mobile- initiated handover because MN determines whether it changes its wireless access to new AP or not by scanning radio characteristics. Both network-initiated handover and mobile-initiated handover are supported in FMIPv6 [iv]. (1) In the mobile-initiated handover scenario, MN sends RtSolPr (Router Solicitation Proxy) and drives previous AR to send PrRtAdv (Proxy Router Advertisement) to initiate FMIPv6 handover. In the network-initiated handover scenario, previous AR sends PrRtAdv to MN in order to notify MN's handover. Park and Suh Expires - July 2004 [Page 4] Network-initiated Handover Framework for FMIPv6 January 2004 (2) After receiving PrRtAdv from previous AP, MN sends FBU (Fast Binding Update) to the previous AP. When anticipation is feasible, FBU is sent directly via the link of previous AP, but if anticipation is not feasible, FBU is sent to the new AR encapsulated in FNA (Fast Neighbor Acknowledgement) and forwarded to previous AP. The first case is called as "predictive" handover, and the second case is called as "reactive" handover. (3) FBU makes packets received by previous AR forwarded to new AP. (4) Subsequent FNA notifies MN's existence to new AR and invokes packet forwarding. Generally, Handover of layer-2 and layer-3 are independent processes. But at least reassociation - layer-2 handover - initiates after MN receives PrRtAdv and finishes before MN sends FNA. In this sense, we can say, layer-2 handover process is performed in the middle of layer-3 handover process. 3.2 IAPP (Inter-Access Point Protocol) IAPP protocol specifies message exchanging method between different APs [vi]. Also IEEE 802.11F defines some management primitives exchanged between APME and IAPP. The commands of APME are sent to other APMEs by using IAPP-specific IP packets. When a new MN makes association with an AP, APME of the AP notifies to the other APMEs that it has an association with indicated MN. When an MN reassociates with new AP, reassociated AP notifies previous AP that MN which was served by previous AP handovers to new AP, and advises to disassociate the MN. (1) MN reassociates with new AP as described in 3.1 (2) APME of new AP gives command to IAPP of new AP to send "MOVE- notify packet" to previous AP. (3) Upon receiving "MOVE-notify packet", IAPP of previous AP indicates that the MN changes wireless access to the new AP. (4) APME of previous AP conducts two actions. It disassociates MN by sending "Disassociation Request frame" and response to APME of new AP by sending "MOVE-response packet" via IAPP. (5) Upon receiving "MOVE-response packet", IAPP of new AP announce the attachment of MN to the other APs. By introducing IAPP, it is feasible to achieve seamless handover in the layer-2. Wireless link between MN and previous AP survives until previous AP receives "MOVE-notify packet", which is sent after MN Park and Suh Expires - July 2004 [Page 5] Network-initiated Handover Framework for FMIPv6 January 2004 establishes reassociation with new AP. In addition, IAPP provides a clue to previous AP so that previous AP can find MN's movement. 4. Network-initiated Handover Framework 4.1. Proposed Handover Framework Suggested framework is to run FMIPv6 on 802.11 wireless LAN in conjunction with IAPP. In this memo, we assume AP functions are integrated in ARs. In IEEE 802.11, no restriction and details about IP layer is described because IEEE 802.11 mainly deals with MAC and physical layers. Also, IAPP is defined in a single ESS in IEEE 802.11F, but we extend it to the inter-ESS region. Related discussion is written in Section 5. [NAR] [PAR] [MN] | | | | |<---Packet Delivery-->| | | | |<===Reassociation=====+======================| | | | |----MOVE-notify------>| | | | | | [PAR invokes handover] | | ^ | | |----PrRtAdv---------->| | | | | | [Movement check] | | | |<---FNA (FBU)---------+----------------------| | | | |----FBU-------------->| | | | | |<---FBACK-------------| | | | | |----FBACK-------------+--------------------->| | v | | [PAR checks handover] | | | | |<-------------Packet Delivery--------------->| | | | |<---MOVE-response-----|====Disassociation===>| | | | Figure 1 Network-initiated Handover Park and Suh Expires - July 2004 [Page 6] Network-initiated Handover Framework for FMIPv6 January 2004 In Figure 1, suggest network-initiated handover framework is shown. In the figure, dashed lines are indicating layer-3 information or data, the IP packets. And the operations related to layer-2 are expressed as double lines. Detailed description of each primitive is shown in 4.2. (1) Initially, MN sends and receives packet via previous AR, which runs on top of the function of previous AP. (2) When MN detects new AP which provides radio access of better quality, SME of MN determines reassociation. By the procedure described in 3.1, MN establishes reassociation with new AR. (3) Once reassociation with MN is set up, IAPP of new AR sends MOVE- notify packet to previous AR. Address of new AR and MN is conveyed in this packet. (4) Movement of MN is reported to previous AR when MOVE-notify packet is transmitted. The APME of previous AR invokes network-initiated FMIPv6 handover by issuing a new management primitive FMIP- HANDOVER.invoke to IP layer of previous AR. At the same time, APME starts to count a handover timer. This timer is used for APME to test whether FMIPv6 handover finishes in reasonable time. (5) When IP layer of previous AR receives FMIP-HANDOVER.invoke primitive, it generates and sends PrRtAdv. Information needed to form PrRtAdv is obtained from FMIP-HANDOVER.invoke parameters. (6) When IP layer of MN receives PrRtAdv, it issues primitive MIP- HANDOVER.request to SME to consult the association status with new AP. At the same time, IP layer starts to count a timer waiting for MIP-HANDOVER.response primitive. (7) SME of MN returns MIP-HANDOVER.response. The status of this primitive teaches MN's movement. Layer-2 association with new AR exists before MN finds its movement. Thus MN performs "reactive" FMIPv6 handover. IP layer of MN sends FBU encapsulated in FNA to new AR. (8) Reactive FMIPv6 handover is performed as defined in [iv]. (9) When handover timer in APME is expired, APME of previous AR issues MIP-HANDOVER.inquire to IP layer to check the completion of FMIPv6. IP layer returns MIP-HANDOVER.confirm in order to report FMIPv6 handover status. (10) When FMIPv6 handover is complete, MN can send and receive packet via new AR. Previous AR takes two actions. It sends Disassociation Request frame to MN and disassociate wireless link with MN. Moreover, it sends MOVE-response packet to new AR which reports that overall process of previous AR for handover of MN is finished. Park and Suh Expires - July 2004 [Page 7] Network-initiated Handover Framework for FMIPv6 January 2004 4.2. New Management Primitives Five new management primitives are defined to provide low latency in FMIPv6 handover. These primitives are used between APME/SME and IP layer. When an APME want to command or monitor the process of IP layer, it issues primitives. MIP-HANODOVER primitives are especially used in the operations related to FMIPv6 handover. MIP-HANDOVER.invoke{ WM MAC Address of New AR DS IP Address of New AR MAC Address of MN Proposed New CoA } MIP-HANDOVER.request{ WM MAC Address of NEW AR } MIP-HANDOVER.reponse{ Status } MIP-HANDOVER.inquire{ MAC Address of MN } MIP-HANDOVER.confirm{ Status } MIP-HANDOVER.invoke is generated by APME of previous AR. When APME determines to start network-initiated FMIPv6 handover, it issues this primitive to IP layer of previous AP. Upon reception of this primitive, IP layer sends PrRtAdv to MN and initiates FMIPv6 handover procedure. Some parameters are contained in MIP-HANDOVER.invoke primitive for IP layer to generate correct PrRtAdv. IP layer identifies MN by looking up MAC address of MN in the routing table. MAC/IP Address of New AR and NCoA are contained in PrRtAdv and sent to MN. These parameters Park and Suh Expires - July 2004 [Page 8] Network-initiated Handover Framework for FMIPv6 January 2004 are obtained by the information which APME received from IAPP MOVE- notify packet. MIP-HANDOVER.request is generated by IP layer of MN. When IP layer need the information of attachment status to particular AR, it issues this primitive to SME of MN. MAC address of AR is contained to identify the particular AR. MIP-HANDOVER.response primitive is a corresponding primitive to the MIP-HANDOVER.request primitive. Upon receiving MIP-HANDOVER.request primitive, SME of MN returns the reassociation status of AR, whose MAC address is passed within MIP-HANDOVER.request. If MN currently has association with requested AR, SME returns status "SUCCESS" to IP layer. If MN does not have association with requested AR, SME returns "FAILURE" to IP layer. In the proposed framework, reassociation precedes FMIPv6 handover, thus MIP-HANDOVER.response with "FAILURE" indicates some internal exception occurs in MN during the reassociation process. MIP-HANDOVER.inquire primitive is generated by APME of previous AR. When APME need to verify whether FMIPv6 handover is completed, it issues this primitive to IP layer inquiring the status of FMIPv6 handover. This primitive contains MAC address of MN to identify target MN. MIP-HANDOVER.confirm primitive is a corresponding primitive to the MIP-HANDOVER.inquire primitive. Upon receiving MIP-HANDOVER.inquire, IP layer of previous AR returns the status of FMIPv6 handover. If the handover finishes without error, status "SUCCESS" is returned. If the handover is still in process, status "FAILURE" is returned. The completion of FMIPv6 handover is decided by IP layer when a bidirectional tunnel between previous AR and new AR is established. If MN claims acknowledgement in FBU, IP layer considers that FMIPv6 handover is complete when it sends FBACK. Because IAPP information is sent by IP packet, MOVE-notify packet, not appropriate information can be delivered. For example, if APME receives duplicate MOVE-notify packet, APME invokes FMIPv6 handover initiation of MN which already moved to other AR. IP layer of AR determines that the MN is not served by itself and return primitive MIP-HANDOVER.confirm with status "INVALID" Park and Suh Expires - July 2004 [Page 9] Network-initiated Handover Framework for FMIPv6 January 2004 5. Error Handling We consider two types of errors for proposed framework. The first type of errors can be occurred during the reassociation process. In this case, SME represents reassociation exception in MIP- HANDOVER.response in the step (7) of section 4.1. Then IP layer of MN stops handover operation and timer of previous AR expires. Because FMIPv6 handover is not successfully complete, MIP-HANDOVER.confirm represents unsuccessful status to APME of previous AR. APME reinitiates FMIPv6 handover by sending PrRtAdv again. The second type of errors is due to untimely or duplicate delivery of IAPP MOVE-notify packet. When MOVE-notify packet conveys information about MN which is not connected to AR, the APME informs stale movement by using IAPP MOVE-response packet. Security Considerations In the proposed framework, strong security association is needed between two ARs which exchange information using IAPP packets. Especially when two ARs belong to the different operators, additional security mechanism is required for an AR to authenticate other ARs. The authentication process among ARs should be completed a prior to IAPP packet exchange. AR authentication process is needed in AR initialization. Two levels of authentication are applied when an MN obtains connectivity to AR. Layer-2 authentication is performed during reassociation process and IP layer authentication and security is needed in FMIPv6. Overlapped features of two levels can be integrated by individual implementation. References [i] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [ii] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 [iii] D. Johnson, C. Perkins, J. Arkko, ôMobility Support in IPv6? draft-ietf-mobileip-ipv6-24.txt (work in progress) Park and Suh Expires - July 2004 [Page 10] Network-initiated Handover Framework for FMIPv6 January 2004 [iv] Rajeev Koodli (Editor), "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-00.txt (work in progress) [v] IEEE Std 802.11, 1999 Edition (R2003) (ISO/IEC 8802-11: 1999), IEEE Standard for Information Technology - Telecommunications and Information Exchange between Systems-Local and Metropolitan Area Network-specific Requirements-part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications [vi] IEEE Std 802.11F, 2003 Edition, IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter- Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation Author's Addresses Questions about this memo can be directed to: Youngjun Park Samsung Electronics Co., Ltd. Dong Suwon P.O.BOX 105 416 Maetan-3Dong, Youngtong-Gu, Suwon-City, Gyeonggi-Do, Korea, 442-600 Email: youngjun74.park@samsung.com Kyungjoo Suh Email: joo.suh@samsung.com Park and Suh Expires - July 2004 [Page 11]