INTERNET DRAFT Koki Mitani 12 July 2004 Rie Shibui Fumio Teraoka Keio University Unified L2 Abstractions for L3-Driven Fast Handover draft-koki-mobopts-l2-abstractions-00.txt Status of This Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 a "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on January 12, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This draft proposes unified L2 abstractions for L3-driven fast handover. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information such as L2 triggers. However, in current operating systems, each protocol layer is designed independently and information exchange between protocol layers is not allowed. To solve the problem, this draft defines 9 kinds of L2 abstractions in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". K. Mitani et.al. Expires 12 January 2005 [Page i] Internet Draft L2 Abstractions 12 July 2004 Contents Status of This Memo i Copyright Notice i Abstract i 1. Introduction 2 2. Terminology 2 3. Primitives for L2 Abstractions 3 4. Definitions of Primitives 3 4.1. L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . 4 4.2. L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . 4 4.3. L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 4 4.4. L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . 4 4.5. L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . 5 4.6. L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . 5 4.7. L2-LinkToBeDown (Type 2) . . . . . . . . . . . . . . . . 5 4.8. L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 6 4.9. L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . 6 5. Security Consideration 6 References 6 Authors' Addresses 7 Appendices 8 A. Example Scenario 8 Full Copyright Statement 10 Intellectual Property Statement 10 K. Mitani et.al. Expires 12 January 2005 [Page 1] Internet Draft L2 Abstractions 12 July 2004 1. Introduction In recent years, the environment around computers is not static and changes dynamically. Especially, when a mobile node moves to a different network, its environment considerably changes. For example, in the case of wireless communication, parameters such as radio strength changes widely depends on time or site. For efficient network communication, it is vital for a protocol layer to know or utilize other layer's information. There are several proposals for seamless handovers in IPv6 network such as Fast Handovers for Mobile IPv6 (FMIPv6)[1] and Hierarchical Mobile IPv6 (HMIPv6)[2]. In FMIPv6, the network layer must know the indication of a handover from the link layer in advance to achieve seamless handovers. However, each protocol layer is designed independently and information exchange between protocol layers is not allowed. For further handover enhancements, this document defines 9 kinds of L2 triggers in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". 2. Terminology This document uses the following terms. L3-Driven Fast Handover The handover which is initiated by the network layer on a mobile node. Since it allows L3 handover preparation during communication, it can reduce packet loss during handover. L3-driven fast handover mechanism requires L2 information as a trigger of handover procedure. Peer The attachment point of a mobile node. (e.g., An access point in IEEE 802.11 networks.) Primitive A unit of information which is sent from one layer to another. There are four classes of primitives: Request, Confirm, Indication and Response. K. Mitani et.al. Expires 12 January 2005 [Page 2] Internet Draft L2 Abstractions 12 July 2004 3. Primitives for L2 Abstractions Each layer offers its services by the form of primitives. There are four classes of primitives as shown in Figure 1: Request, Confirm, Indication, and Response. The request is issued by the layer that wants to get services or information from another layer, and the confirm is the acknowledgement of the request. The indication is a notification of information to the layer that requested the service, and the response is the acknowledgement of the indication. In this architecture, each layer can communicate evenly. The primitive consists of five fields: the protocol layer id to which this primitive should be sent, the protocol id to which protocol entity this primitive should be sent, the primitive class (i.e., request, confirm, indication, or response), the primitive name, and parameters. There are three different usages of Primitives: Type 1. To provide L2 information to upper layers Type 2. To notify upper layers of L2 events Type 3. To control L2 from upper layers ------------------------------------------------------ Request Response || /\ /\ || Layer N || || || || ------------||------||----------||------||------------ || || || || \/ || || \/ Layer N-m Confirm Indication ------------------------------------------------------ Figure 1: Primitives 4. Definitions of Primitives In order to obtain and change L2 information, some sorts of Primitives described below are necessary. The following Primitives are defined. K. Mitani et.al. Expires 12 January 2005 [Page 3] Internet Draft L2 Abstractions 12 July 2004 4.1. L2-LinkStatus (Type 1) The L2-LinkStatus.request is sent to the link layer when an upper layer needs the current information of the link. In response, the L2-LinkStatus.confirm returns. The L2-LinkStatus.confirm primitive contains five special parameters: the "i/f type options", the "i/f data rate", the "security", the "condition" and the "peer". The "i/f type options" shows the option of the network interface type, such as IEEE 802.11i. The "i/f data rate" is the configured data rate of the network interface. The "security" identifies the current configured security scheme such as EAP. The "condition" and the "peer" indicates the current status about the link between the network interface and the peer. 4.2. L2-PeerList (Type 1) The L2-PeerList.request is sent to the link layer when an upper layer needs a list of the candidate peers. In response, the L2-PeerList.confirm returns with the "peer-list" parameter which is the list of candidate peers. In IEEE 802.11 networks, L2-PeerList returns all detected APs as peer candidates. 4.3. L2-PeerFound (Type 2) The L2-PeerFound.indication is asynchronously provided to an upper layer when new peers are detected. This primitive carries the "peer-list" parameter which contains the information of the new peers detected. In order to use this notification, the registration process using L2-PeerFound.request is needed in advance. The L2-PeerFound.request primitive has two special parameters: the "condition" and the "enable/disable". The "condition" parameter prevents unnecessary detection of peers (e.g., in case the quality of the radio link to a peer is very low). The "enable/disable" parameter shows whether this notification function is turned on. When this registration succeeds, the L2-PeerFound.confirm returns with "ack" parameter in response. In IEEE 802.11 networks, L2-PeerFound is notified when new peers are detected by listening beacons or scanning APs. 4.4. L2-PeerLost (Type 2) The L2-PeerLost.indication is asynchronously provided to an upper layer when a peer included in the list of candidate peers is got lost. This primitive carries the "peer-list" parameter which contains the information of the peers which disappeared from the candidates list. The registration process using the L2-PeerLost.request and the L2-PeerLost.confirm is similar to the L2-PeerFound above. K. Mitani et.al. Expires 12 January 2005 [Page 4] Internet Draft L2 Abstractions 12 July 2004 In IEEE 802.11 networks, L2-PeerLost is notified when an AP included in the list of candidate APs is got lost by listening beacons or scanning APs. 4.5. L2-LinkUp (Type 2) The L2-LinkUp.indication is asynchronously provided to an upper layer when a new link is connected. The L2-LinkUp.request contains the "enable/disable" parameter for registration operation. When the registration succeeds, the L2-LinkUp.confirm with "ack" parameter returns. In IEEE 802.11 networks, L2-LinkUp is notified when association or reassociation event occurs. 4.6. L2-LinkDown (Type 2) The L2-LinkDown.indication is asynchronously provided to an upper layer when an existing link is disconnected. The registration processing is same as the L2-LinkUp above. In IEEE 802.11 networks, L2-LinkDown is notified when disassociation event occurs. 4.7. L2-LinkToBeDown (Type 2) The L2-LinkToBeDown.indication is asynchronously provided to an upper layer when an existing link is to be disconnected. This notification contains two special parameters: the "condition" and the "peer". The "condition" shows the current link status. The "peer" is the attachment point at which the link quality is degrading. In the registration processing, the L2-LinkToBeDown.request carries not only the "enable/disable" parameter but the "condition" parameter to specify the threshold of notification. In IEEE 802.11 networks, L2-LinkToBeDown is notified when radio signal strength is going down. 4.8. L2-LinkConnect (Type 3) The L2-LinkConnect.request is sent to the link layer when an upper layer has to change or create a new link to the specific "peer". This operation begins after sending L2-LinkConnect.confirm with "ack". 4.9. L2-LinkDisconnect (Type 3) The L2-LinkDisconnect.request is sent to the link layer when an upper layer has to destroy an existing link to the specific "peer". This operation begins after sending L2-LinkDisconnect.confirm with "ack". K. Mitani et.al. Expires 12 January 2005 [Page 5] Internet Draft L2 Abstractions 12 July 2004 5. Security Consideration It is recommended that the implementers consider the security features to manage the L2 information. References [1] R. Koodli, G. Dommety, K. El-Malki, M. Khalil, C. E. Perkins, H. Soliman, G. Tsirtsis, and A. E. Yegin. Fast Handovers for Mobile IPv6, work in progress, Jan. 2004. [2] H. Soliman, C. Castelluccia, K. El-Malki, and L. Bellier. Hierarchical Mobile IPv6 mobility management (HMIPv6), work in progress, Jun. 2004. K. Mitani et.al. Expires 12 January 2005 [Page 6] Internet Draft L2 Abstractions 12 July 2004 Authors' Addresses Koki Mitani Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522 JAPAN Phone: +81-45-566-1425 EMail: koki@tera.ics.keio.ac.jp Rie Shibui Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522 JAPAN Phone: +81-45-566-1425 EMail: shibrie@tera.ics.keio.ac.jp Fumio Teraoka Graduate School of Science and Technology, KEIO University 3-14-1 Hiyoshi, Kohoku-ku, Yokohama, Kanagawa 223-8522 JAPAN Phone: +81-45-566-1425 EMail: tera@ics.keio.ac.jp K. Mitani et.al. Expires 12 January 2005 [Page 7] Internet Draft L2 Abstractions 12 July 2004 A. Example Scenario For example, the picture below shows L3-driven fast handover mechanism using the L2 triggers on MN. L2 L3 | | Low | Signal-----LinkToBeDown.ind------->| | | | Handover AP<---------PeerList.req------Preparation Scan---------PeerList.cnf--------->| | | |<-------LinkConnect.req----L3 Handover L2 Handover--LinkConnect.cnf-------->: : : : : finish---------LinkUp.ind---------->: | : | finish | | L2: Link Layer on MN L3: Network Layer on MN req: request cnf: confirm ind: indication Figure 2: L3-Driven Fast Handover Mechanism In the beginning of the L3-driven handover procedure, L2 detects radio signal strength is going down. Then L2 sends L2-LinkToBeDown.indication to L3. L3 prepares for handover (e.g., CoA generation, DAD) and sends L2-PeerList.request to L2 if the list of access points is needed. If L3 decides to perform handover according to some rules, L3 sends L2-LinkConnect.request with some parameters about candidate access points to request L2 handover. L2 handover begins after sending L2-LinkConnect.confirm to L3. When L2 handover finished, L2 sends L2-LinkUp.indication to notify L3. At last, L3 performs handover (e.g., sending BU). One of the important features of L3-driven fast handover using Primitives is that the L3 handover preparation can be done during communication. So, it can reduce disruption time during handover. K. Mitani et.al. Expires 12 January 2005 [Page 8] Internet Draft L2 Abstractions 12 July 2004 Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. K. Mitani et.al. Expires 12 January 2005 [Page 10]