IRTF MobOpts RG K. Mitani Internet-Draft R. Shibui Expires: April 25, 2005 F. Teraoka KEIO University October 25, 2004 Unified L2 Abstractions for L3-Driven Fast Handover draft-koki-mobopts-l2-abstractions-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 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. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 Mitani, et al. Expires April 25, 2005 [Page 1] Internet-Draft L2 Abstractions October 2004 defines nine kinds of L2 abstractions in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 6 4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 7 4.1 L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 7 4.2 L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 7 4.3 L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 7 4.4 L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 7 4.5 L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 8 4.6 L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 8 4.7 L2-LinkQualityChange (Type 2) . . . . . . . . . . . . . . 8 4.8 L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 8 4.9 L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 8 5. Definitions of Static Parameters . . . . . . . . . . . . . . . 9 5.1 Network Interface ID (i/f id) . . . . . . . . . . . . . . 9 5.2 Network Interface Type (i/f type) . . . . . . . . . . . . 9 5.3 Network Interface Type Options (i/f type options) . . . . 9 5.4 Network Interface Data Rate (i/f rate) . . . . . . . . . . 9 6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 10 6.1 Peer (peer) . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Condition (condition) . . . . . . . . . . . . . . . . . . 10 6.3 Threshold (threshold) . . . . . . . . . . . . . . . . . . 10 6.4 Peer List (peer-list) . . . . . . . . . . . . . . . . . . 10 6.5 Security (security) . . . . . . . . . . . . . . . . . . . 10 6.6 Enable/Disable (enable/disable) . . . . . . . . . . . . . 10 6.7 Ack/Error (ack/error) . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 A. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 14 B. Example Operation for FMIPv6 . . . . . . . . . . . . . . . . . 15 Mitani, et al. Expires April 25, 2005 [Page 2] Internet-Draft L2 Abstractions October 2004 C. Example Mapping of Primitives and IEEE802.11 . . . . . . . . . 17 C.1 L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 17 C.2 L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 17 C.3 L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 17 C.4 L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 18 C.5 L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 18 C.6 L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 18 C.7 L2-LinkQualityChange . . . . . . . . . . . . . . . . . . . 18 C.8 L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 18 C.9 L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Mitani, et al. Expires April 25, 2005 [Page 3] Internet-Draft L2 Abstractions October 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 nine kinds of L2 triggers in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". Mitani, et al. Expires April 25, 2005 [Page 4] Internet-Draft L2 Abstractions October 2004 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. Mitani, et al. Expires April 25, 2005 [Page 5] Internet-Draft L2 Abstractions October 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 acknowledgment of the request. The indication is a notification of information to the layer that requested the service, and the response is the acknowledgment of the indication. In this architecture, each layer can communicate evenly. ------------------------------------------------------ Request Response || /\ /\ || Layer N || || || || ------------||------||----------||------||------------ || || || || \/ || || \/ Layer N-m Confirm Indication ------------------------------------------------------ Figure 1: Primitives 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 immediately A "request" primitive is an acquisition request for L2 informaiton. As a "confirm" primitive, L2 information returns immediately. Type 2. To notify upper layers of L2 events asynchronously "Request" and "confirm" primitives are used just for registration. When an event occurs, an "indication" primitive is asynchronously delivered to an upper layer. Type 3. To control L2 actions from upper layers Mitani, et al. Expires April 25, 2005 [Page 6] Internet-Draft L2 Abstractions October 2004 A "request" primitive is a request for operation. Ack or nack returns immediately as a "confirm" primitive. Mitani, et al. Expires April 25, 2005 [Page 7] Internet-Draft L2 Abstractions October 2004 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. 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. 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 "threshold" parameter, "condition" parameter and 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 "threshold" and the "enable/disable". The "threshold" parameter prevents unnecessary detection of peers (e.g., in case the quality level 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. 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 "threshold" parameter, "condition" Mitani, et al. Expires April 25, 2005 [Page 8] Internet-Draft L2 Abstractions October 2004 parameter and 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. 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. 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. 4.7 L2-LinkQualityChange (Type 2) The L2-LinkQualityChange.indication is asynchronously provided to an upper layer when an existing link is to be disconnected. This notification contains three special parameters: the "condition", the "threshold" and the "peer". The "condition" shows the current link status. The "threshold" is the link quality level for a decision of notification. The "peer" is the attachment point at which the link quality is degrading. In the registration processing, the L2-LinkQualityChange.request carries not only the "enable/disable" parameter but the "threshold" parameter to specify the threshold of notification. 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". Mitani, et al. Expires April 25, 2005 [Page 9] Internet-Draft L2 Abstractions October 2004 5. Definitions of Static Parameters This section lists static parameters. Once the values of static parameters are configured, they do not change frequently during communication. The following parameters are transferred as a part of primitives. 5.1 Network Interface ID (i/f id) The network interface ID identifies uniquely the network interface in a node. The identifier is an implementation-specific consideration (e.g., name, index or unique address assigned to each interface). This parameter is required for all the primitives. 5.2 Network Interface Type (i/f type) The network interface type indicates the kind of technology of the network interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is required for all the primitives. 5.3 Network Interface Type Options (i/f type options) The interface type options indicate the optional technologies configured for the network interface. (e.g., IEEE802.1x, WPA, IEEE802.11i, etc.) 5.4 Network Interface Data Rate (i/f rate) The network interface data rate is the current configured rate of data transfer. The value means maximum bandwidth of the network interface. Mitani, et al. Expires April 25, 2005 [Page 10] Internet-Draft L2 Abstractions October 2004 6. Definitions of Dynamic Parameters This section lists dynamic parameters. The values of dynamic parameters change frequently during communication. The following parameters are transferred as a part of primitives. 6.1 Peer (peer) The peer consists of two sub-parameters: the attachment ID and the network ID. The attachment ID uniquely identifies the Peer. The network ID is used for specifying the set of Peers or configuration of PPP connection. 6.2 Condition (condition) The condition consists of the following sub-parameters: available bandwidth, link quality level and noise level. These sub-parameters are abstracted information for considering current quality-of service. The abstraction algorithms of sub-parameters depend on hardware device and software implementation. The useful range of link quality level is from one(bad) to five(good). (TODO: Energy cost and movement pattern need to be considered?) 6.3 Threshold (threshold) The threshold consists of the sub-parameter: link quality level. This parameter indicates the threshold value of link quality for generating an event notification. 6.4 Peer List (peer-list) The peer list consists of arbitrary couples of two sub-parameters: peer and condition. This parameter indicates a list of peers and its condition. 6.5 Security (security) The security indicates the current configured security scheme. 6.6 Enable/Disable (enable/disable) The enable/disable flag is used for turning event notification on/ off. When an upper layer needs notifications, the "request" primitive with enable is sent to the link layer as registration. When an upper layer needs no more notifications, the "request" primitive with disable is sent. Mitani, et al. Expires April 25, 2005 [Page 11] Internet-Draft L2 Abstractions October 2004 6.7 Ack/Error (ack/error) When an upper layer requests some notifications, link layer receives and confirms this "request". If the "request" is valid, the "confirm" primitive with ack is sent. And if it is invalid, the "confirm" with Error is sent to an upper layer. Mitani, et al. Expires April 25, 2005 [Page 12] Internet-Draft L2 Abstractions October 2004 7. Security Considerations It is recommended that the implementers consider the security features to manage the L2 information. 8 References [1] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C., Soliman, H., Tsirtsis, G. and A. Yegin, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. [2] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-02 (work in progress), June 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 URI: http://www.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 URI: http://www.tera.ics.keio.ac.jp/ Mitani, et al. Expires April 25, 2005 [Page 13] Internet-Draft L2 Abstractions October 2004 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 URI: http://www.tera.ics.keio.ac.jp/ Mitani, et al. Expires April 25, 2005 [Page 14] Internet-Draft L2 Abstractions October 2004 Appendix A. Example Scenario For example, the picture below shows L3-driven fast handover mechanism using the L2 triggers on MN. L2 L3 | | Low | Signal---LinkQualityChange.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-LinkQualityChange.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. Mitani, et al. Expires April 25, 2005 [Page 15] Internet-Draft L2 Abstractions October 2004 Appendix B. Example Operation for FMIPv6 Figure 3 shows the predictive mode of FMIPv6 operation with L3-driven link switching mechanism. MN L2 MN L3 PAR L3 | | | AP<---------PeerList.req----------| | Scan---------PeerList.cnf--------->| | | |---RtSolPr-->| | |<--PrRtAdv---| |---------PeerFound.ind--------->| | | |---RtSolPr-->| | |<--PrRtAdv---| | | | ~ ~ ~ | | | Low | | Signal---LinkQualityChange.ind---->| | NAR L3 | |-----FBU---->| | | | |----HI---->| | | |<--HAck----| | |<----FBack---| | |<-------LinkConnect.req---L3 Handover | | L2 Handover--LinkConnect.cnf-------->: | : : | : : | finish---------LinkUp.ind---------->: | | :-----------FNA---------->| | finish<======packets=========| | | | MN L2 : Link Layer on Mobile Node MN L3 : Network Layer on Mobile Node PAR L3 : Network Layer on Previous Access Router NAR L3 : Network Layer on New Access Router req : request cnf : confirm ind : indication RtSolPr : Router Solicitation for Proxy PrRtAdv : Proxy Router Advertisement FBU : Fast Binding Update FBack : Fast Binding Acknowledgment FNA : Fast Neighbor Advertisement HI : Handover Initiate HAck : Handover Acknowledge Figure 3: L3-Driven Fast Handover Mechanism with FMIPv6 Mitani, et al. Expires April 25, 2005 [Page 16] Internet-Draft L2 Abstractions October 2004 When the MN establishes link connectivity with the PAR, it performs router discovery. Then, the MN can send RtSolPr message to the PAR in order to resolve access point identifiers to subnet router information. To send RtSolPr, a MN discovers one or more access points by sending L2-PeerList.request to the link layer. As a response to L2-PeerList.request, L2-PeerList.confirm returns with "peer-list" parameter which contains identifiers and conditions of nearby access points. After initial AP discovery, L2-PeerFound.indication with "peer-list" is also sent from the link layer when one or more access points are discovered. When the link layer of the MN detects radio signal strength is going down, it sends L2-LinkQualityChange.indication to the network layer. Then, the MN sends FBU to PAR as the beginning of L3 handover procedure. The NCoA required for FBU message is determined according to the MN's policy database and received PrRtAdv message. As a response to FBU, the MN receives FBack and then switches its link by L2-LinkConnect.request with specific "peer" parameter immediately. The handover policy of the MN is outside the scope of this document. After L2 handover, the link layer of the MN sends L2-LinkUp.indication to the network layer. The MN sends FNA message to NAR immediately. The NAR will send tunneled and buffered packets to the MN. Mitani, et al. Expires April 25, 2005 [Page 17] Internet-Draft L2 Abstractions October 2004 Appendix C. Example Mapping of Primitives and IEEE802.11 This section shows examples of the mapping between "primitives" and IEEE802.11 parameters. C.1 L2-LinkStatus Most of parameters for L2-LinkStatus are related to the configuration of network interface hardware. So, the operating system and the device driver module can easily collect such information. However, to create the "condition" parameter, the MN should maintain statistics and parameters related to current wireless environment. There are three sub-parameters of the "condition" parameter: available bandwidth, link quality level and noise level. An available bandwidth of the current peer can be obtained by maintaining transmission rate indication and statistics of frame transmission at every time the frame transmission occurs. A link quality level and a noise level can be updated by maintaining the following parameters and statistics at every time the frame reception occurs: receive signal strength indication (RSSI), transmission/ reception rate indication, transmit/receive latency, bit error rate, frame error rate and noise level. Some parameters can be managed by setting threshold from software. When the parameters cross the threshold, an interrupt is generated for the software. C.2 L2-PeerList In IEEE 802.11 networks, L2-PeerList returns all detected APs as peer candidates (by "peer-list" parameter). Therefore, the MN should always maintain the database of available access points according to reception of beacon frame, probe response frame and all frames. This AP database is managed in consideration of time, number of frames and signal strength. There are some network interface hardwares that can notify events to operating system only when the desired event occurs, by setting threshold from software. Moreover, the MN can transmit probe request frame for access point discovery, if needed. C.3 L2-PeerFound In IEEE 802.11 networks, L2-PeerFound is notified when new peers are detected by listening beacons or scanning APs. If the received frame (mainly beacon or probe response) is not in the AP database described in Appendix C.2, then the link layer can create L2-PeerFound.indication. Mitani, et al. Expires April 25, 2005 [Page 18] Internet-Draft L2 Abstractions October 2004 C.4 L2-PeerLost 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. If the entry in the AP database described in Appendix C.2 expires, or signal strength of the received frame (mainly beacon or probe response) is under threshold, then the link layer can create L2-PeerLost.indication. C.5 L2-LinkUp In IEEE 802.11 networks, L2-LinkUp is notified when association or reassociation event occurs. When such event occurs, the MN receives association response frame or reassociation response frame. Immediately after receiving it, the link layer can create L2-LinkUp.indication. C.6 L2-LinkDown In IEEE 802.11 networks, L2-LinkDown is notified when disassociation event occurs. When such event occurs, the MN sends disassociation frame to AP, or the entry of the specific AP is deleted from the AP database described in Appendix C.2. By detecting such events, the link layer can create L2-LinkDown.indication. C.7 L2-LinkQualityChange In IEEE 802.11 networks, L2-LinkQualityChange is notified when radio signal strength of the connected AP is going down. By maintaining parameters for a link quality level like the description in Appendix C.1, the link layer can create L2-LinkQualityChange.indication. C.8 L2-LinkConnect In IEEE802.11 networks, each AP is identified by BSSID, the service set of several APs is identified by SSID. When L2-LinkConnect is used to connect specific AP or service set, the link layer should set BSSID or SSID. Also, the channel should be set appropriately at the same time by searching database described in Appendix C.2. C.9 L2-LinkDisconnect In IEEE802.11 networks, the MN sends disassociation message to the AP for disconnection. When L2-LinkDisconnect is used for disconnection from the current AP, the link layer should send disassociation message to the appropriate AP, and stop data transmission. Mitani, et al. Expires April 25, 2005 [Page 19] Internet-Draft L2 Abstractions October 2004 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mitani, et al. Expires April 25, 2005 [Page 20] IRTF MobOpts RG K. Mitani Internet-Draft R. Shibui Expires: April 25, 2005 F. Teraoka KEIO University October 25, 2004 Unified L2 Abstractions for L3-Driven Fast Handover draft-koki-mobopts-l2-abstractions-01.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she 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 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. This Internet-Draft will expire on April 25, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 Mitani, et al. Expires April 25, 2005 [Page 1] Internet-Draft L2 Abstractions October 2004 defines nine kinds of L2 abstractions in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Primitives for L2 Abstractions . . . . . . . . . . . . . . . . 6 4. Definitions of Primitives . . . . . . . . . . . . . . . . . . 7 4.1 L2-LinkStatus (Type 1) . . . . . . . . . . . . . . . . . . 7 4.2 L2-PeerList (Type 1) . . . . . . . . . . . . . . . . . . . 7 4.3 L2-PeerFound (Type 2) . . . . . . . . . . . . . . . . . . 7 4.4 L2-PeerLost (Type 2) . . . . . . . . . . . . . . . . . . . 7 4.5 L2-LinkUp (Type 2) . . . . . . . . . . . . . . . . . . . . 8 4.6 L2-LinkDown (Type 2) . . . . . . . . . . . . . . . . . . . 8 4.7 L2-LinkQualityChange (Type 2) . . . . . . . . . . . . . . 8 4.8 L2-LinkConnect (Type 3) . . . . . . . . . . . . . . . . . 8 4.9 L2-LinkDisconnect (Type 3) . . . . . . . . . . . . . . . . 8 5. Definitions of Static Parameters . . . . . . . . . . . . . . . 9 5.1 Network Interface ID (i/f id) . . . . . . . . . . . . . . 9 5.2 Network Interface Type (i/f type) . . . . . . . . . . . . 9 5.3 Network Interface Type Options (i/f type options) . . . . 9 5.4 Network Interface Data Rate (i/f rate) . . . . . . . . . . 9 6. Definitions of Dynamic Parameters . . . . . . . . . . . . . . 10 6.1 Peer (peer) . . . . . . . . . . . . . . . . . . . . . . . 10 6.2 Condition (condition) . . . . . . . . . . . . . . . . . . 10 6.3 Threshold (threshold) . . . . . . . . . . . . . . . . . . 10 6.4 Peer List (peer-list) . . . . . . . . . . . . . . . . . . 10 6.5 Security (security) . . . . . . . . . . . . . . . . . . . 10 6.6 Enable/Disable (enable/disable) . . . . . . . . . . . . . 10 6.7 Ack/Error (ack/error) . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 A. Example Scenario . . . . . . . . . . . . . . . . . . . . . . . 14 B. Example Operation for FMIPv6 . . . . . . . . . . . . . . . . . 15 Mitani, et al. Expires April 25, 2005 [Page 2] Internet-Draft L2 Abstractions October 2004 C. Example Mapping of Primitives and IEEE802.11 . . . . . . . . . 17 C.1 L2-LinkStatus . . . . . . . . . . . . . . . . . . . . . . 17 C.2 L2-PeerList . . . . . . . . . . . . . . . . . . . . . . . 17 C.3 L2-PeerFound . . . . . . . . . . . . . . . . . . . . . . . 17 C.4 L2-PeerLost . . . . . . . . . . . . . . . . . . . . . . . 18 C.5 L2-LinkUp . . . . . . . . . . . . . . . . . . . . . . . . 18 C.6 L2-LinkDown . . . . . . . . . . . . . . . . . . . . . . . 18 C.7 L2-LinkQualityChange . . . . . . . . . . . . . . . . . . . 18 C.8 L2-LinkConnect . . . . . . . . . . . . . . . . . . . . . . 18 C.9 L2-LinkDisconnect . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Mitani, et al. Expires April 25, 2005 [Page 3] Internet-Draft L2 Abstractions October 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 nine kinds of L2 triggers in the form of "Primitive". This concept can be applied to L3-driven fast handover mechanism using "Primitives". Mitani, et al. Expires April 25, 2005 [Page 4] Internet-Draft L2 Abstractions October 2004 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. Mitani, et al. Expires April 25, 2005 [Page 5] Internet-Draft L2 Abstractions October 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 acknowledgment of the request. The indication is a notification of information to the layer that requested the service, and the response is the acknowledgment of the indication. In this architecture, each layer can communicate evenly. ------------------------------------------------------ Request Response || /\ /\ || Layer N || || || || ------------||------||----------||------||------------ || || || || \/ || || \/ Layer N-m Confirm Indication ------------------------------------------------------ Figure 1: Primitives 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 immediately A "request" primitive is an acquisition request for L2 informaiton. As a "confirm" primitive, L2 information returns immediately. Type 2. To notify upper layers of L2 events asynchronously "Request" and "confirm" primitives are used just for registration. When an event occurs, an "indication" primitive is asynchronously delivered to an upper layer. Type 3. To control L2 actions from upper layers Mitani, et al. Expires April 25, 2005 [Page 6] Internet-Draft L2 Abstractions October 2004 A "request" primitive is a request for operation. Ack or nack returns immediately as a "confirm" primitive. Mitani, et al. Expires April 25, 2005 [Page 7] Internet-Draft L2 Abstractions October 2004 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. 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. 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 "threshold" parameter, "condition" parameter and 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 "threshold" and the "enable/disable". The "threshold" parameter prevents unnecessary detection of peers (e.g., in case the quality level 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. 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 "threshold" parameter, "condition" Mitani, et al. Expires April 25, 2005 [Page 8] Internet-Draft L2 Abstractions October 2004 parameter and 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. 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. 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. 4.7 L2-LinkQualityChange (Type 2) The L2-LinkQualityChange.indication is asynchronously provided to an upper layer when an existing link is to be disconnected. This notification contains three special parameters: the "condition", the "threshold" and the "peer". The "condition" shows the current link status. The "threshold" is the link quality level for a decision of notification. The "peer" is the attachment point at which the link quality is degrading. In the registration processing, the L2-LinkQualityChange.request carries not only the "enable/disable" parameter but the "threshold" parameter to specify the threshold of notification. 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". Mitani, et al. Expires April 25, 2005 [Page 9] Internet-Draft L2 Abstractions October 2004 5. Definitions of Static Parameters This section lists static parameters. Once the values of static parameters are configured, they do not change frequently during communication. The following parameters are transferred as a part of primitives. 5.1 Network Interface ID (i/f id) The network interface ID identifies uniquely the network interface in a node. The identifier is an implementation-specific consideration (e.g., name, index or unique address assigned to each interface). This parameter is required for all the primitives. 5.2 Network Interface Type (i/f type) The network interface type indicates the kind of technology of the network interface (e.g., IEEE802.11a/b/g, 3GPP, etc.). This parameter is required for all the primitives. 5.3 Network Interface Type Options (i/f type options) The interface type options indicate the optional technologies configured for the network interface. (e.g., IEEE802.1x, WPA, IEEE802.11i, etc.) 5.4 Network Interface Data Rate (i/f rate) The network interface data rate is the current configured rate of data transfer. The value means maximum bandwidth of the network interface. Mitani, et al. Expires April 25, 2005 [Page 10] Internet-Draft L2 Abstractions October 2004 6. Definitions of Dynamic Parameters This section lists dynamic parameters. The values of dynamic parameters change frequently during communication. The following parameters are transferred as a part of primitives. 6.1 Peer (peer) The peer consists of two sub-parameters: the attachment ID and the network ID. The attachment ID uniquely identifies the Peer. The network ID is used for specifying the set of Peers or configuration of PPP connection. 6.2 Condition (condition) The condition consists of the following sub-parameters: available bandwidth, link quality level and noise level. These sub-parameters are abstracted information for considering current quality-of service. The abstraction algorithms of sub-parameters depend on hardware device and software implementation. The useful range of link quality level is from one(bad) to five(good). (TODO: Energy cost and movement pattern need to be considered?) 6.3 Threshold (threshold) The threshold consists of the sub-parameter: link quality level. This parameter indicates the threshold value of link quality for generating an event notification. 6.4 Peer List (peer-list) The peer list consists of arbitrary couples of two sub-parameters: peer and condition. This parameter indicates a list of peers and its condition. 6.5 Security (security) The security indicates the current configured security scheme. 6.6 Enable/Disable (enable/disable) The enable/disable flag is used for turning event notification on/ off. When an upper layer needs notifications, the "request" primitive with enable is sent to the link layer as registration. When an upper layer needs no more notifications, the "request" primitive with disable is sent. Mitani, et al. Expires April 25, 2005 [Page 11] Internet-Draft L2 Abstractions October 2004 6.7 Ack/Error (ack/error) When an upper layer requests some notifications, link layer receives and confirms this "request". If the "request" is valid, the "confirm" primitive with ack is sent. And if it is invalid, the "confirm" with Error is sent to an upper layer. Mitani, et al. Expires April 25, 2005 [Page 12] Internet-Draft L2 Abstractions October 2004 7. Security Considerations It is recommended that the implementers consider the security features to manage the L2 information. 8 References [1] Koodli, R., Dommety, G., Malki, K., Khalil, M., Perkins, C., Soliman, H., Tsirtsis, G. and A. Yegin, "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-03 (work in progress), October 2004. [2] Soliman, H., Castelluccia, C., Malki, K. and L. Bellier, "Hierarchical Mobile IPv6 mobility management (HMIPv6)", draft-ietf-mipshop-hmipv6-02 (work in progress), June 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 URI: http://www.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 URI: http://www.tera.ics.keio.ac.jp/ Mitani, et al. Expires April 25, 2005 [Page 13] Internet-Draft L2 Abstractions October 2004 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 URI: http://www.tera.ics.keio.ac.jp/ Mitani, et al. Expires April 25, 2005 [Page 14] Internet-Draft L2 Abstractions October 2004 Appendix A. Example Scenario For example, the picture below shows L3-driven fast handover mechanism using the L2 triggers on MN. L2 L3 | | Low | Signal---LinkQualityChange.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-LinkQualityChange.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. Mitani, et al. Expires April 25, 2005 [Page 15] Internet-Draft L2 Abstractions October 2004 Appendix B. Example Operation for FMIPv6 Figure 3 shows the predictive mode of FMIPv6 operation with L3-driven link switching mechanism. MN L2 MN L3 PAR L3 | | | AP<---------PeerList.req----------| | Scan---------PeerList.cnf--------->| | | |---RtSolPr-->| | |<--PrRtAdv---| |---------PeerFound.ind--------->| | | |---RtSolPr-->| | |<--PrRtAdv---| | | | ~ ~ ~ | | | Low | | Signal---LinkQualityChange.ind---->| | NAR L3 | |-----FBU---->| | | | |----HI---->| | | |<--HAck----| | |<----FBack---| | |<-------LinkConnect.req---L3 Handover | | L2 Handover--LinkConnect.cnf-------->: | : : | : : | finish---------LinkUp.ind---------->: | | :-----------FNA---------->| | finish<======packets=========| | | | MN L2 : Link Layer on Mobile Node MN L3 : Network Layer on Mobile Node PAR L3 : Network Layer on Previous Access Router NAR L3 : Network Layer on New Access Router req : request cnf : confirm ind : indication RtSolPr : Router Solicitation for Proxy PrRtAdv : Proxy Router Advertisement FBU : Fast Binding Update FBack : Fast Binding Acknowledgment FNA : Fast Neighbor Advertisement HI : Handover Initiate HAck : Handover Acknowledge Figure 3: L3-Driven Fast Handover Mechanism with FMIPv6 Mitani, et al. Expires April 25, 2005 [Page 16] Internet-Draft L2 Abstractions October 2004 When the MN establishes link connectivity with the PAR, it performs router discovery. Then, the MN can send RtSolPr message to the PAR in order to resolve access point identifiers to subnet router information. To send RtSolPr, a MN discovers one or more access points by sending L2-PeerList.request to the link layer. As a response to L2-PeerList.request, L2-PeerList.confirm returns with "peer-list" parameter which contains identifiers and conditions of nearby access points. After initial AP discovery, L2-PeerFound.indication with "peer-list" is also sent from the link layer when one or more access points are discovered. When the link layer of the MN detects radio signal strength is going down, it sends L2-LinkQualityChange.indication to the network layer. Then, the MN sends FBU to PAR as the beginning of L3 handover procedure. The NCoA required for FBU message is determined according to the MN's policy database and received PrRtAdv message. As a response to FBU, the MN receives FBack and then switches its link by L2-LinkConnect.request with specific "peer" parameter immediately. The handover policy of the MN is outside the scope of this document. After L2 handover, the link layer of the MN sends L2-LinkUp.indication to the network layer. The MN sends FNA message to NAR immediately. The NAR will send tunneled and buffered packets to the MN. Mitani, et al. Expires April 25, 2005 [Page 17] Internet-Draft L2 Abstractions October 2004 Appendix C. Example Mapping of Primitives and IEEE802.11 This section shows examples of the mapping between "primitives" and IEEE802.11 parameters. C.1 L2-LinkStatus Most of parameters for L2-LinkStatus are related to the configuration of network interface hardware. So, the operating system and the device driver module can easily collect such information. However, to create the "condition" parameter, the MN should maintain statistics and parameters related to current wireless environment. There are three sub-parameters of the "condition" parameter: available bandwidth, link quality level and noise level. An available bandwidth of the current peer can be obtained by maintaining transmission rate indication and statistics of frame transmission at every time the frame transmission occurs. A link quality level and a noise level can be updated by maintaining the following parameters and statistics at every time the frame reception occurs: receive signal strength indication (RSSI), transmission/ reception rate indication, transmit/receive latency, bit error rate, frame error rate and noise level. Some parameters can be managed by setting threshold from software. When the parameters cross the threshold, an interrupt is generated for the software. C.2 L2-PeerList In IEEE 802.11 networks, L2-PeerList returns all detected APs as peer candidates (by "peer-list" parameter). Therefore, the MN should always maintain the database of available access points according to reception of beacon frame, probe response frame and all frames. This AP database is managed in consideration of time, number of frames and signal strength. There are some network interface hardwares that can notify events to operating system only when the desired event occurs, by setting threshold from software. Moreover, the MN can transmit probe request frame for access point discovery, if needed. C.3 L2-PeerFound In IEEE 802.11 networks, L2-PeerFound is notified when new peers are detected by listening beacons or scanning APs. If the received frame (mainly beacon or probe response) is not in the AP database described in Appendix C.2, then the link layer can create L2-PeerFound.indication. Mitani, et al. Expires April 25, 2005 [Page 18] Internet-Draft L2 Abstractions October 2004 C.4 L2-PeerLost 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. If the entry in the AP database described in Appendix C.2 expires, or signal strength of the received frame (mainly beacon or probe response) is under threshold, then the link layer can create L2-PeerLost.indication. C.5 L2-LinkUp In IEEE 802.11 networks, L2-LinkUp is notified when association or reassociation event occurs. When such event occurs, the MN receives association response frame or reassociation response frame. Immediately after receiving it, the link layer can create L2-LinkUp.indication. C.6 L2-LinkDown In IEEE 802.11 networks, L2-LinkDown is notified when disassociation event occurs. When such event occurs, the MN sends disassociation frame to AP, or the entry of the specific AP is deleted from the AP database described in Appendix C.2. By detecting such events, the link layer can create L2-LinkDown.indication. C.7 L2-LinkQualityChange In IEEE 802.11 networks, L2-LinkQualityChange is notified when radio signal strength of the connected AP is going down. By maintaining parameters for a link quality level like the description in Appendix C.1, the link layer can create L2-LinkQualityChange.indication. C.8 L2-LinkConnect In IEEE802.11 networks, each AP is identified by BSSID, the service set of several APs is identified by SSID. When L2-LinkConnect is used to connect specific AP or service set, the link layer should set BSSID or SSID. Also, the channel should be set appropriately at the same time by searching database described in Appendix C.2. C.9 L2-LinkDisconnect In IEEE802.11 networks, the MN sends disassociation message to the AP for disconnection. When L2-LinkDisconnect is used for disconnection from the current AP, the link layer should send disassociation message to the appropriate AP, and stop data transmission. Mitani, et al. Expires April 25, 2005 [Page 19] Internet-Draft L2 Abstractions October 2004 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. Disclaimer of Validity 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. 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mitani, et al. Expires April 25, 2005 [Page 20]