Network Working Group K. Sidhu Internet-Draft B. Sarikaya Expires: August 3, 2004 UNBC February 3, 2004 Light Weight AP Handover Protocol (LWAPHP) draft-sarikaya-capwap-lwaphp-00 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. This Internet-Draft will expire on August 3, 2004. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This document describes the Light Weight Access Point Handover Protocol (LWAPHP) which is a protocol allowing the access router to anchor and manage 802.11 handovers of the stations between a collection of wireless Access Points. The protocol like IEEE's IAPP aims to ensure that a station is connected to a single access point and provides an efficient context transfer mechanism during handover using neighbor graphs. There are several advantages of having the access router of CAPWAP architecture to anchor 802.11 handovers as follows: LWAPHP does not define a new transport protocol, instead it relies of the transport defined by LWAPP. The neighbor graph, a rather static data structure Sidhu & Sarikaya Expires August 3, 2004 [Page 1] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 is best managed and diffused downstream by the access router. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Conventions used in this document . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 7 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . 8 4. LWAPHP Data Structures . . . . . . . . . . . . . . . . . . 9 4.1 Description of the MOBILITY_CACHE Table . . . . . . . . . 9 4.2 Description of the Location Graph Concept . . . . . . . . 9 4.3 Neighbor Graph . . . . . . . . . . . . . . . . . . . . . . 10 5. LWAPHP Packet Format . . . . . . . . . . . . . . . . . . . 12 5.1 LWAPHP Message Format . . . . . . . . . . . . . . . . . . 12 5.1.1 Flags Field . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.2 VER field . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.3 RID . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.4 Reserved . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.5 Length . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.6 Control/Status . . . . . . . . . . . . . . . . . . . . . . 12 5.1.7 Payload . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2 LWAPHP Control Messages . . . . . . . . . . . . . . . . . 14 5.2.1 Control Message Format . . . . . . . . . . . . . . . . . . 14 5.2.2 Control Channel Management . . . . . . . . . . . . . . . . 16 5.2.3 AR Configuration . . . . . . . . . . . . . . . . . . . . . 18 6. LWAPHP Message Elements . . . . . . . . . . . . . . . . . 19 6.1 Result Code . . . . . . . . . . . . . . . . . . . . . . . 19 6.2 AR Address . . . . . . . . . . . . . . . . . . . . . . . . 20 6.3 AP Payload . . . . . . . . . . . . . . . . . . . . . . . . 20 6.4 AP Name . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.5 AR Payload . . . . . . . . . . . . . . . . . . . . . . . . 21 6.6 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.7 AR Name . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.8 Location Data . . . . . . . . . . . . . . . . . . . . . . 22 6.9 Session ID . . . . . . . . . . . . . . . . . . . . . . . . 22 6.10 Session Key Payload . . . . . . . . . . . . . . . . . . . 23 6.11 Context Block . . . . . . . . . . . . . . . . . . . . . . 23 7. LWAPHP Configuration Variables . . . . . . . . . . . . . . 25 7.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . . 25 7.2 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . . 25 7.3 SilentInterval . . . . . . . . . . . . . . . . . . . . . . 25 7.4 NeighborDeadInterval . . . . . . . . . . . . . . . . . . . 25 7.5 EchoInterval . . . . . . . . . . . . . . . . . . . . . . . 25 7.6 DiscoveryInterval . . . . . . . . . . . . . . . . . . . . 26 7.7 LWAPHP_MAX_ATTEMPT_COUNT . . . . . . . . . . . . . . . . . 26 7.8 COUNTER . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.9 LWAPHP_TIME_FRAME . . . . . . . . . . . . . . . . . . . . 26 7.10 LWAPHP_DOS_WAIT_TIME . . . . . . . . . . . . . . . . . . . 26 Sidhu & Sarikaya Expires August 3, 2004 [Page 2] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 7.11 TIMEOUT_PERIOD . . . . . . . . . . . . . . . . . . . . . . 26 8. LWAPHP Transport Layer . . . . . . . . . . . . . . . . . . 27 8.1 Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1.1 Source Address . . . . . . . . . . . . . . . . . . . . . . 27 8.1.2 Destination Address . . . . . . . . . . . . . . . . . . . 27 8.1.3 Ethertype . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1.4 AR Discovery . . . . . . . . . . . . . . . . . . . . . . . 27 8.1.5 Extended LWAPHP Message Format . . . . . . . . . . . . . . 27 8.2 Layer 3 . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2.2 Fragmentation/Reassembly . . . . . . . . . . . . . . . . . 29 8.2.3 Multiplexing . . . . . . . . . . . . . . . . . . . . . . . 29 8.2.4 AR Discovery . . . . . . . . . . . . . . . . . . . . . . . 29 9. Handoff in LWAPHP . . . . . . . . . . . . . . . . . . . . 31 9.1 Association Mobile (Association-Mobile) . . . . . . . . . 32 9.1.1 Sending Associate-Mobile . . . . . . . . . . . . . . . . . 32 9.1.2 Receiving Association-Mobile . . . . . . . . . . . . . . . 32 9.2 Association Mobile Reply (Association-Mobile-Reply) . . . 33 9.2.1 Sending Associate-Mobile-Reply . . . . . . . . . . . . . . 33 9.2.2 Receiving Association-Mobile-Reply . . . . . . . . . . . . 33 9.3 Handoff Init (Hoff-Init) . . . . . . . . . . . . . . . . . 34 9.3.1 Sending Hoff-Init . . . . . . . . . . . . . . . . . . . . 34 9.3.2 Receiving Hoff-Init . . . . . . . . . . . . . . . . . . . 34 9.4 Hoff-Context-Request . . . . . . . . . . . . . . . . . . . 36 9.4.1 Sending Hoff-Context-Request . . . . . . . . . . . . . . . 36 9.4.2 Receiving Hoff-Context-Request . . . . . . . . . . . . . . 37 9.5 Hoff-Context-Reply . . . . . . . . . . . . . . . . . . . . 37 9.5.1 Sending Hoff-Context-Reply . . . . . . . . . . . . . . . . 37 9.5.2 Receiving Hoff-Context-Reply . . . . . . . . . . . . . . . 37 9.6 Hoff-Init-Reply . . . . . . . . . . . . . . . . . . . . . 38 9.6.1 Sending Hoff-Init-Reply . . . . . . . . . . . . . . . . . 39 9.6.2 Receiving Hoff-Init-Reply . . . . . . . . . . . . . . . . 39 9.7 Hoff-CachedContext . . . . . . . . . . . . . . . . . . . . 40 9.7.1 Sending Hoff-CachedContext . . . . . . . . . . . . . . . . 40 9.7.2 Receiving Hoff-CachedContext . . . . . . . . . . . . . . . 40 9.8 Hoff-CachedContext-Reply . . . . . . . . . . . . . . . . . 42 9.8.1 Sending Hoff-CachedContext-Reply . . . . . . . . . . . . . 42 9.8.2 Receiving Hoff-CachedContext-Reply . . . . . . . . . . . . 43 9.9 Hoff-CachedContext-Update . . . . . . . . . . . . . . . . 44 9.9.1 Sending Hoff-CachedContext-Update . . . . . . . . . . . . 44 9.9.2 Receiving Hoff-CachedContext-Update . . . . . . . . . . . 44 9.10 Hoff-CachedContext-New . . . . . . . . . . . . . . . . . . 44 9.10.1 Sending Hoff-CachedContext-New . . . . . . . . . . . . . . 45 9.10.2 Receiving a Hoff-CachedContext-New . . . . . . . . . . . . 45 9.11 Hoff-CachedContext-Drop . . . . . . . . . . . . . . . . . 45 9.11.1 Sending Hoff-CachedContext-Drop . . . . . . . . . . . . . 45 9.11.2 Receiving a Hoff-CachedContext-Drop . . . . . . . . . . . 45 10. Security Considerations . . . . . . . . . . . . . . . . . 47 Sidhu & Sarikaya Expires August 3, 2004 [Page 3] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 48 12. IPR Statement . . . . . . . . . . . . . . . . . . . . . . 49 References . . . . . . . . . . . . . . . . . . . . . . . . 50 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 50 Intellectual Property and Copyright Statements . . . . . . 52 Sidhu & Sarikaya Expires August 3, 2004 [Page 4] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 1. Introduction IEEE has defined the Inter-Access Point Protocol (IAPP) [10] in order to enable wireless Access Points (AP)to exchange station (STA) context during Layer 2 handoff. IAPP uses IP transport (IP multicast and TCP) in the distribution system. One can argue that this goes against APs' primary function of bridging between the wireless and wired medium. The emergence of simple Access Points in 802.11 that are managed by a router or switch (also known as an Access router, or AR) suggests that having a standardized, interoperable protocol could radically simplify the deployment and management of wireless networks, a trend that could become more important in new wireless Layer 2 protocols. LWAPP [9] is such a protocol. LWAPP assumes a network configuration that consists of multiple APs connected either via layer 2 (Ethernet), or layer 3 (IP) to an AR. The APs can be considered as remote RF interfaces, being controlled by the AR (see Figure 1). The AP forwards all 802.11 frames received to the AR via the LWAPHP protocol, which processes the frames. Similarly, packets from authorized mobiles are forwarded by the AP to the AR via this protocol. +-+ 802.11frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | LWAPHP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA AP AR Figure 1: LWAPP Architecture This document describes the Light Weight Access Point Handover Protocol (LWAPHP), a Layer 2 handover protocol allowing handover of STAs from one AP to another be managed by the AR. The rationale behind it is the fact that the LWAPP AR manages a collection of APs and adding the task of handover management to the ARs is well warranted. In LWAPHP, the STA to AP protocol is based on IEEE 802.11 and the AP to AR transport is completely based on LWAPP. Goals The following are goals for this protocol: Sidhu & Sarikaya Expires August 3, 2004 [Page 5] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 1. Provide smooth handover access to mobile stations when it enters the range of another AP. 2. Enhance the protocol code at AR so that AR is able to support and manage all major functionalities of an AP. This will help in reduction of protocol code being executed at the AP to achieve maximum efficiency of computing power of APs. 3. Use the generic encapsulation and transport mechanism, provided by LWAPP. 4. Enable builtin security features to provide better protection for the APs and AR. The LWAPHP protocol concerns itself on the interface between the stations and the AP as well as the AP and the AR. Inter-AR communication is strictly outside the scope of this document. Direct mobile to AR communication is not possible 1.1 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 [7]. Sidhu & Sarikaya Expires August 3, 2004 [Page 6] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 2. Protocol Overview LWAPHP is a handover protocol defining how the station context maintained at each AP when STA was connected to the AP is transferred to the new AP with the help of the neighbor graph maintained at the AR. LWAPHP messages and procedures defined in this document represent extensions to LWAPP for the AP to AR communication and they are triggered by STAs' handover interactions with the APs. LWAPHP Transport Layer (LTL) is based on LWAPP Transport Layer and is defined in section Section 8. LTL defines the framing, fragmentation/reassembly, and multiplexing services to LWAPHP for each transport. The Light Weight Access Protocol (LWAPHP) begins its operation after LWAPP discovery phase in which APs will select any Access Router (AR) [8] with which to associate and followed by the LWAPP configuration exchange in which APs are provisioned and are enabled for operation. LWAPHP handles smooth handover when a mobile station moves from one AP to another AP. When a mobile station moves under the range of another AP, it sends a ReAssociation Request to the AP. On receiving such a request from a mobile station, the AP sends a initiate handoff request to the AR (Hoff-Init). When an AR receives a Hoff-Init request it checks to see whether the station is authorized on the network. If authorization is granted, it also confirms the previous association and checks whether it matches with what the station is claiming. For this the MOBILITY_CAHCHE table can be used. If no association or a different association is found then appropriate error messages are returned(NO_ASSOC or BAD_ASSOC) and the station must attempt a fresh association. LWAPPHP also supports CachedContext features. The context of a station is updated in a timely fashion between APs and AR. Sidhu & Sarikaya Expires August 3, 2004 [Page 7] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 3. Definitions This Document uses terminology defined in [8] Sidhu & Sarikaya Expires August 3, 2004 [Page 8] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 4. LWAPHP Data Structures 4.1 Description of the MOBILITY_CACHE Table Access Router stores a list which contains the MAC addresses of the station and the AP they are currently associated with. This is required for security checks later on in the HOFF-INIT process. Also the Context information is stored here. The context block is similar to that of IAPP (AP Context Block) except that we have added an additional parameter, namely the AR session key context. --------------------------------------------------------------- | MAC Address of Station | MAC Address of AP | Context Block | --------------------------------------------------------------- | 1 | 5 | CB for STA 1 | | 2 | 5 | CB for STA 2 | | 3 | 7 | CB for STA 3 | --------------------------------------------------------------- where 1,2,3,5,7 represent MAC addresses CB - Context Block Figure 2: Sample MOBILITY_CACHE Table Because the MOBILITY_CACHE TABLE is soft state i.e. it only exists for a certain timeout period, the APs monitor the activity of the mobile stations. When they haven't had any activity for a long time, TIMEOUT_PERIOD, then APs send request to AR to remove entry from MOBILITY_CACHE TABLE. Entries are added/updated as part of the Association and Re-association requests. 4.2 Description of the Location Graph Concept In our implementation, the Access Router (AR) stores a list as shown in figure below for the purpose of keeping track of all the neighbour locations. Sidhu & Sarikaya Expires August 3, 2004 [Page 9] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 -------------------------- | Location A | Location B | -------------------------- | 1 | 2 | | 3 | 4 | | 5 | 8 | | 9 | 10 | | 3 | 2 | -------------------------- Both columns contain location entities (as described in the LWAPP document). The APs during the discovery phase send a location field, specifying their location. AR can use the location field in conjunction with the above list to build the neighbor graph for APs dynamically. This list (Location Graph) is a static entity and must be instantiated (or loaded) during system startup. 4.3 Neighbor Graph In our implementation, the Access Router (AR) stores a list as shown in figure below for the purpose of keeping track of the neighbours. ----------------------------------------------------- | Access Point ID | NeighBour ID | Channels | Flags | ----------------------------------------------------- | 1 | 2 | {2,6,8} | T | | 1 | 3 | {6} | T | | 2 | 1 | {2,6,8} | T | | 3 | 1 | {6} | T | ----------------------------------------------------- where 1, 2 and 3 in the first two columns represent MAC addresses. Figure 4: Sample AR Neighbor Graph list The first column contains the access point id (MAC address) of the access point for which the neighbour has been stored. Second column contains the MAC address of the neighbouring AP. Third column contains a list of channels through which these two APs can communicate. The last column is used for Flags, which is used when an AP which went offline is being brought back online (this will be discussed in details later on). The neighbour graph is a dynamic entity and gets updated when a AP starts up during the discovery phase. This neighbour graph(or list) is stored at the AR level and the AR acts as the management entity which co-ordinates the Sidhu & Sarikaya Expires August 3, 2004 [Page 10] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 association/re-association requests. Sidhu & Sarikaya Expires August 3, 2004 [Page 11] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 5. LWAPHP Packet Format This section contains the general packet header format. The LWAPHP protocol is designed to be transport agnostic. Transport details can be found in the section entitled Section 8. 5.1 LWAPHP Message Format 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ctl/Stat | Payload... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.1 Flags Field The first byte contains several flag fields. 5.1.2 VER field The VER field identifies the LWAPHP protocol version carried in this packet. For this version of the protocol, the value of this field is 0. 5.1.3 RID The RID field contains the Radio Identifier. For APs that contain more than one radio, this field is used to idenfity each Radio. 5.1.4 Reserved The reserved field MUST be set to zero unless these bits are defined for use with a specific transport (see Section 8.1). 5.1.5 Length The value of this field is unsigned and indicates the number of bytes in the Payload field. 5.1.6 Control/Status The interpretation of this field depends on the direction of transmission of the packet. Sidhu & Sarikaya Expires August 3, 2004 [Page 12] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 5.1.6.1 Status When an LWAPHP packet is transmitted from an AP to a AR, this field indicates link layer information associated with the frame. When the C bit is 0, this field is transmitted as zero and ignored on reception. For 802.11, the signal strength and signal to noise ratio with which an 802.11 frame was received, encoded in the following manner: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RSSI | SNR | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.1.6.1.1 RSSI RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. 5.1.6.1.2 SNR SNR is a signed, 8-bit value. It is the signal to noise ratio of the received 802.11 frame, in dB. 5.1.6.2 Control When an LWAPHP packet is transmitted from an AR to an AP, this field indicates on which WLANs the encapsulated 802.11 frame is to be transmitted. For unicast packets, this field is not used by the AP, but for broadcast or multicast packets, the AP may require this information if it provides encryption services. Given that a single broadcast or multicast packet may need to be sent to multiple wireless LANs (presumably each with a different broadcast key), this field must be a bit field. The bit position indicates the WLAN ID the frame is to be transmitted to. The Control field is encoded in the following manner: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN ID(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sidhu & Sarikaya Expires August 3, 2004 [Page 13] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 5.1.7 Payload The Payload field contains data equal in size to the value of the Length field, found within the LWAPHP header. 5.2 LWAPHP Control Messages The LWAPHP Control protocol provides a communication channel between the AP and the AR and falls into the following distinct messages types: Control Channel Management: Messages that fall within this classification are used for the discovery of ARs by the APs as well as the establishment and maintenance of an LWAPHP control channel. AR Configuration: The AR Configuration messages are used by the AR to push a specific configuration to the APs it has a control channel with. Messages that deal with the retrieval of statistics from the AP also fall in this category. Mobile Session Management: Mobile session management messages are used by the AR to push specific mobile policies to the AP. 5.2.1 Control Message Format All LWAPHP control messages are sent encapsulated within the LWAPHP header (see Section 5.1) with the following header values: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Type | Seq Num | Msg Element Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Msg Element [0..N] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2.1.1 Message Type The Message Type field identifies the function of the LWAPHP control message. The valid values for Message Type are the following: Description Value LWAPP messages 1-27 Sidhu & Sarikaya Expires August 3, 2004 [Page 14] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 Reserved 28-39 MOBILITY_CACHE Update Request 40 MOBILITY_CACHE Update Response 41 Location Update Request 42 Location Update Response 43 Association-Mobile 44 Association-Mobile-Reply 45 Hoff-Init 46 Hoff-Init-Reply 47 Hoff-Context-Request 48 Hoff-Context-Reply 49 Hoff-CachedContext 50 Hoff-CachedContext-Reply 51 Hoff-CachedContext-Update 52 Hoff-CachedContext-New 53 Hoff-CachedContext-Drop 54 5.2.1.2 Sequence Number The Sequence Number Field is an identifier value to match request/ response packet exchanges. When an LWAPHP packet with a request message type is received, the value of the sequence number field is copied into the corresponding response packet. 5.2.1.3 Msg Element Length The Length field indicates the number of bytes following the Session ID field. 5.2.1.4 Session ID The Session ID is a 32-bit unsigned integer that is used to identify the security context for encrypted exchanges between the AP and the AR. 5.2.1.5 Message Element[0..N] The message element(s) carry the information pertinent to each of the control message types. The total length of the message elements is indicated in the Msg Element Length field. The format of a message element uses the standard TLV format shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sidhu & Sarikaya Expires August 3, 2004 [Page 15] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 | Type | Length | Value ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Type identifies the character of the information carried in the Value field and Length indicates the number of bytes in the Value field. The LWAPHP message elements are defined in Section 6 5.2.2 Control Channel Management The Control Channel Management messages are used by the AP and AR to create and maintain a channel of communication on which various other commands may be transmitted, such as configuration, firmware update, etc. A few Control Channel Management messages are Discovery, Join, Echo and Key-Update. Discovery message is used primarily by AP for primarily detecting potential ARs in the network. Join message are sent by an AP on receiving one or more Discovery replies. Echo message is a keepalive mechanism for the LWAPHP control messages. Finally, Key-Update message is used for updating session key for secure messaging between AP and AR. All of the above messages are based on the LWAPP version. 5.2.2.1 MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request is sent by the AP to the AR to delete the entry for the specified mobile station from the MOBILITY_CACHE Table. 5.2.2.1.1 Sending MOBILITY_CACHE Update Requests APs monitor stations associated with them for activity. If no activity is seen for TIMOUT_PERIOD then AP send MOBILITY_CACHE Update Requests to AR. Thus, station id (MAC address) is required as part of the message. 5.2.2.1.2 Format of a MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request carries the following message elements: Station ID (MAC address) Sidhu & Sarikaya Expires August 3, 2004 [Page 16] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 5.2.2.1.3 Receiving MOBILITY_CACHE Update Requests When a AR receives a MOBILITY_CACHE Update Request it deletes the corresponding entry from the MOBILITY_CACHE Table. It then responds with a MOBILITY_CACHE Update Response. 5.2.2.2 MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response is sent by AR to AP to inform the AP whether the request to delete the station was successful or not. 5.2.2.2.1 Sending MOBILITY_CACHE Update Responses MOBILITY_CACHE Update Responses are sent by a AR after receiving a MOBILITY_CACHE Update Request. Response is a status element (SUCCESS or FAILURE). 5.2.2.2.2 Format of a MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response carries the following message elements: Status 5.2.2.2.3 Receiving MOBILITY_CACHE Update Responses No action is required on receiving MOBILITY_CACHE Update Responses. 5.2.2.3 Location Update Request The Location Update Request is sent by the AP to the AR after receiving a Join request. 5.2.2.3.1 Sending Location Update Requests AP sends Location Update request so that the neighbour graph list can be updated. This requires the location information of the AP. 5.2.2.3.2 Format of a Location Update Request The Location Update Request carries the following message elements: Location Data Sidhu & Sarikaya Expires August 3, 2004 [Page 17] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 5.2.2.3.3 Receiving Location Update Requests When a AR receives a Location Update Request it first checks to see if it can find location data in the MOBILITY_CACHE Table. If the data is same then it turns the flags on in the Neighbour graph list to make AP-neighbour pairs active. If entry is not found or is not the same (location has changed) then it deletes all entries from the neighbour graph list corresponding to that AP and then finds all the new neighbours of the AP depending upon the passed in location information and the location graph list stored at the AR. It then adds entries for all neighbours in the neighbour graph list. Finally, AR responds back with a Location Update Response message. 5.2.2.4 Location Update Response The Location Update Response is sent by AR to AP to inform the AP whether the request to update the location of AP was successful or not. 5.2.2.4.1 Sending Location Update Responses Location Update Responses are sent by a AR after receiving a Location Update Request. Response is a status element (SUCCESS or FAILURE). 5.2.2.4.2 Format of a Location Update Response The Location Update Response carries the following message elements: Status 5.2.2.4.3 Receiving Location Update Responses No action is required on receiving Location Update Responses. 5.2.3 AR Configuration The AR Configuration messages are used by the AR to perform operations such as rebooting an AP etc. No new messages have been defined apart from the reset message defined in LWAPP. The reset message is used by the AP to reboot. Sidhu & Sarikaya Expires August 3, 2004 [Page 18] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 6. LWAPHP Message Elements As previously specified, the LWAPHP messages MAY include a message element. The supported message elements are defined in this section. The allowable values for the Type field are the following: Description Type Result Code 1 AR Address 2 AP Payload 3 AP Name 4 AR Payload 5 Reserved 6-16 Test 17 Reserved 17-29 AR Name 30 Reserved 31-33 Location Data 34 Reserved 35-43 Session ID 44 Session key 45 Reserved 46-59 Context Block 60 6.1 Result Code The result code message element value is a 32-bit integer value, indicating the result of the request operation corresponding to the sequence number in the message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Result Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Result Code: The following values are supported 0 Success 1 Failure 2 STALE_MOVE Sidhu & Sarikaya Expires August 3, 2004 [Page 19] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 3 BAD_ASSOC 4 NO_ASSOC 5 HOFF_NOAUTH 6.2 AR Address The AR address message element is used to communicate the identity of the AR. The value contains two fields, as shown. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved: MUST be set to zero Mac Address: The MAC Address of the AR 6.3 AP Payload The AP payload message element is used by the AP to communicate it's current hardware/firmware configuration. The value contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Hardware Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Software Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Boot Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radios | Radios in use | Encryption Capabilities | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Hardware Version: A 32-bit integer representing the AP's hardware version number Sidhu & Sarikaya Expires August 3, 2004 [Page 20] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 Software Version: A 32-bit integer representing the AP's Firmware version number Boot Version: A 32-bit integer representing the AP's boot loader's version number Max Radios: An 8-bit value representing the number of radios (where each radio is identified via the RID field) supported by the AP Radios in use: An 8-bit value representing the number of radios present in the AP Encryption Capabilities: This 16-bit field is used by the AP to communicate it's capabilities to the AR. Since most APs support link layer encryption, the AR may opt to make use of these services. This bitfield supports the following values: 1 - Encrypt WEP 104: All packets to/from the mobile station must be encrypted using standard 104 bit WEP. 2 - Encrypt WEP 40: All packets to/from the mobile station must be encrypted using standard 40 bit WEP. 3 - Encrypt WEP 128: All packets to/from the mobile station must be encrypted using standard 128 bit WEP. 4 - Encrypt AES-CCM 128: All packets to/from the mobile station must be encrypted using 128 bit AES CCM [12]. 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must be encrypted using TKIP and authenticated using Michael [11]. 6.4 AP Name The AP name message element value is a variable length byte string. The string is NOT zero terminated. 6.5 AR Payload The AR payload message element is used by the AR to communicate it's current state. The value contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Hardware Version ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sidhu & Sarikaya Expires August 3, 2004 [Page 21] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 | HW Ver | Software Version ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SW Ver | Stations | Limit | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Limit | Radios | Max Radio | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max Radio | +-+-+-+-+-+-+-+-+ Hardware Version: A 32-bit integer representing the AP's hardware version number Software Version: A 32-bit integer representing the AP's Firmware version number Stations: A 16-bit integer representing number of mobile stations currently associated with the AR Limit: A 16-bit integer representing the maximum number of stations supported by the AR Radios: A 16-bit integer representing the number of APs currently attached to the AR Max Radio: A 16-bit integer representing the maximum number of APs supported by the AR 6.6 Test The test message element is used as padding to perform MTU discovery, and MAY contain any value, of any length. 6.7 AR Name The AR name message element contains an ASCII representation of the AR's identity. The value is a variable length byte string. The string is NOT zero terminated. 6.8 Location Data The location data message element is a variable length byte string containing user defined location information (e.g. Next to Fridge). The string is NOT zero terminated. 6.9 Session ID The session ID message element value contains a randomly generated Sidhu & Sarikaya Expires August 3, 2004 [Page 22] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 [5] unsigned 32-bit integer. 6.10 Session Key Payload Session Key Payload is based on LWAPPs Session Key Payload. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Session ID: A 32-bit value representing the session which this session key is related to Session Key: A 128-bit value randomly generated session key [5] 6.11 Context Block The Context Block is a container for information that needs to be forwarded from one AP to another upon reassociation of a STA.The format of the Information Element is shown . The Context Block is based on LWAPP Context Block 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of Context Block | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Key Payload | Context Block | Sidhu & Sarikaya Expires August 3, 2004 [Page 23] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of Context Block: A 16-bit integer that indicates the number of octets in the Context Block field. Length of Session Key Payload: a 160-bit integer which is sent by the AR to the AP and includes the randomly generated session key, which is used to protect the LWAPHP control messages. Context Block: variable length field that contains the context information being forwarded for the reassociated STA. Sidhu & Sarikaya Expires August 3, 2004 [Page 24] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 7. LWAPHP Configuration Variables An AP or AR that implements LWAPHP discovery MUST allow for the following variables to be configured by system management; default values are specified so as to make it unnecessary to configure any of these variables in many cases. 7.1 MaxDiscoveryInterval The maximum time allowed between sending discovery requests from the interface, in seconds. Must be no less than 2 seconds and no greater than 180 seconds. Default: 20 seconds. 7.2 MaxDiscoveries The maximum number of discovery requests that will be sent after an AP boots. Default: 10 7.3 SilentInterval The minimum time, in seconds, an AP MUST wait after failing to receive any responses to its discovery requests, before it MAY again send discovery requests. Default: 30 7.4 NeighborDeadInterval The minimum time, in seconds, an AP MUST wait without having received echo replies to its echo responses, before the destination for the echo replies may be considered dead. Must be no less than 2*EchoInterval seconds and no greater than 240 seconds. Default: 60 7.5 EchoInterval The minimum time, in seconds, between sending echo requests to the AR with which the AP has joined. Default: 30 Sidhu & Sarikaya Expires August 3, 2004 [Page 25] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 7.6 DiscoveryInterval The minimum time, in seconds, that an AP MUST wait after receiving a discovery reply, before sending a join request. Default: 5 7.7 LWAPHP_MAX_ATTEMPT_COUNT The maximum number of attempts allowed to connect to AP in LWAPHP_TIME_FRAME. Default: 10 7.8 COUNTER A temporary counter for each mobile station that is trying to associate or re-associate to keep track of current number of attempts with LWAPHP_TIME_FRAME seconds. 7.9 LWAPHP_TIME_FRAME The time, in seconds, that is used to see if a station is trying to achieve a DOS (denial of service) attack on an AR. Default: 5 7.10 LWAPHP_DOS_WAIT_TIME The time, in seconds, that AP must ignore communication from a mobile station before re-opening communication with it. Default: 10 7.11 TIMEOUT_PERIOD The time, in seconds, that an AP MUST wait before sending a MOBILITY_CACHE Update Request to an AR for a specific station. Default: 5 Sidhu & Sarikaya Expires August 3, 2004 [Page 26] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 8. LWAPHP Transport Layer The LWAPHP protocol can operate at layer 2 or 3. For layer 2 support, the LWAPHP frames are carried in a native Ethernet frame. As such, the protocol is not routable and depends upon layer 2 connectivity between the AP and the AR. Layer 3 support is provided by encapsulating the LWAPHP frames within UDP. 8.1 Layer 2 This section describes how the LWAPHP protocol is provided over native Ethernet frames. All LWAPHP frames are encapsulated within 802.3 frames, whose fields are defined below. 8.1.1 Source Address A MAC address belonging to the interface from which this message is sent. If multiple source addresses are configured on an interface, then the one chosen is implementation dependent. 8.1.2 Destination Address A MAC address belonging to the interface to which this message is to be sent. This destination address MAY be either an individual address or a multicast address, if more than one destination interface is intended. 8.1.3 Ethertype The Ethertype field is set to 0x88bb. 8.1.4 AR Discovery When run over Ethernet, the LWAPHP protocol is restricted to a specific Ethernet segment. The AR discovery mechanism used with this transport is for the Discovery Request message to be transmitted to a broadcast address. The ARs will receive this message and reply based on their policy. 8.1.5 Extended LWAPHP Message Format When LWAPHP is run over a layer 2 interface, the base LWAPHP header is extended to include fields that are only useful when run over this transport. The following figure and associated text describes the new fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 Sidhu & Sarikaya Expires August 3, 2004 [Page 27] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |VER| RID |C|F|L| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ctl/Stat | Payload... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.1.5.1 Flags Field The first byte contains several flag fields. The following flags are only used when LWAPHP is run over a layer 2 interface: 8.1.5.2 C Bit The C bit indicates whether this packet carries data or control information. When this bit is 0, the packet carries an encapsulated data frame. When this bit is 1, the packet carries control information for consumption by the addressed destination. 8.1.5.3 F Bit The F bit indicates whether this packet is a fragment. When this bit is 1, the packet is a fragment and MUST be combined with the other corresponding fragments to reassemble the complete information exchanged between the AP and AR. 8.1.5.4 L Bit The L bit is valid only if the 'F' bit is set and indicates whether the packet contains the last fragment of a fragmented exchange between AP and AR. When this bit is 1, the packet is not the last fragment. When this bit is 0, the packet is the last fragment. 8.1.5.5 Fragment ID The Fragment ID is a value assigned to each group of fragments making up a complete set. The value of Fragment ID is incremented with each new set of fragments. The Fragment ID wraps to zero after the maximum value has been used to identify a set of fragments. LWAPHP only supports up to 2 fragments. 8.2 Layer 3 This section defines how LWAPHP makes use of UDP transport between the AP and the AR. Sidhu & Sarikaya Expires August 3, 2004 [Page 28] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 8.2.1 Framing Communication between AP and AR is established according to the standard UDP client/server model. The connection is initiated by the AP (client) to the well-known UDP port of the AR (server) used for control messages. This UDP port number of the AR is TBD. 8.2.2 Fragmentation/Reassembly When LWAPHP is implemented at L3, the transport layer uses IP fragmentation to fragment and reassemble LWAPHP messages that are longer than MTU size used by either AP or AR. The details of IP fragmentation are covered in [3]. [ed: IP fragmentation may raise security concerns and bring additional configuration requirements for certain firewalls and NATs. One alternative is to re-use the layer 2 (application layer) fragmentation reassembly. Comments are welcomed.] 8.2.3 Multiplexing LWAPHP messages convey control information between AP and AR, as well as, 802.11 data frames or 802.11 management frames. As such, LWAPHP messages needs to be multiplexed in the transport sub-layer and be delivered to the proper software entities in the endpoints of the protocol. In case of Layer 3 connection, multiplexing is achieved by use of different UDP ports for control and data packets. As part of Join procedure, the AP and AR may negotiate different UDP ports, as well as, different IP addresses for data or session management messages. [ed: details on how to communicate this information in the protocol is still missing]. In the event the AP and AR are separated by a NAT, with the AP using private IP address space, it is the responsibility of the NAT to manage appropriate UDP port mapping. 8.2.4 AR Discovery When LWAPHP is run over routed IP network, the AP and the AR do not need to reside in the same IP subnet (broadcast domain). However, in the event the peers reside on separate IP subnets, there must exist a mechanism for the AP to discover the AR. As the AP attempts to establish communication with the AR, it sends the Discovery Request message and receives the corresponding reply Sidhu & Sarikaya Expires August 3, 2004 [Page 29] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 message from the AR. The AP may send the Discovery Request message to either limited broadcast IP address (255.255.255.255) or to the unicast IP address of the AR. Upon receipt of the message, the AR issues a Discovery Reply message to the IP address of the AP, regardless of whether Discovery Request was sent as a broadcast or unicast message. Whether the AP uses a limited IP broadcast or unicast IP address is implementation dependent. In order for the AP to use a unicast address, it must first obtain the IP address of the AR. The configuration of the AR's address in the AP is implementation dependent and outside the scope of this document. However, some possibilities is to make use of a vendor specific DHCP option, DNS name resolution, or even static provisioning of the AR's IP address in non-volatile storage. Sidhu & Sarikaya Expires August 3, 2004 [Page 30] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 9. Handoff in LWAPHP A Handoff occurs when a mobile station moves from one Acces Point (AP) to another AP. This move could happen because of a number of reason such as the weakening of the strength of the signal from the current AP. During the handoff process, management frames are exchanged between station (STA) and the AP. We are considering the case for LWAPHP where most of the management is done through the Access Router (AR) and AP are kept as lightweight as possible. Context information also changes hand between the old AP to the new AP via the AR. For the implementation of the handoff protocol we have discussed context caching as well, something similar to the lines of IAPP version. There are two main cases when a handoff takes place: Re-Association of Mobile Station when context information not available at new AP, Re-Association of Mobile Station when context already exists at new AP Sample Message Format The Hoff-Init message element carries the information pertinent to the Hoff-Init message. The total length of the message elements is indicated in the Msg Element Length field. The format of this message element uses the standard TLV format shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Message Type=46| Length = 12 | Sta ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sta ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sta ID | old AP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | old AP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where Type identifies the character of the information carried in the Value field and Length indicates the number of bytes in the Value field. Length = length of all parameters i.e. length of Sta ID + length of old AP id field Sidhu & Sarikaya Expires August 3, 2004 [Page 31] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 .i.e. Length = 2 * Length of AR Address field = 2 * 48 = 96 bits = 12 bytes 9.1 Association Mobile (Association-Mobile) This message is used by an AP to inform the AR that a STA has requested an association with it via an 802.11 associate request. This is used in a non-cached scenario as this is the first association that the mobile is making. 9.1.1 Sending Associate-Mobile When an AP receives an 802.11 associate requests, it first performs any authentication necessary. The AP then sends the Association-Mobile request to the AR. The message contains the STA id of the mobile (Mac Address). {Hoff-Init, STA id, old AP id} STA id and old AP id are of AR Adress Type 9.1.2 Receiving Association-Mobile When an AR receives a Associate-Mobile it first checks that the STA id (Mac Address) is one that is authorized to use the network. If authentication is not granted to the STA a Associate-Mobile-Reply is returned to the AP indicating failure (ASSOC-NOAUTH). With each unique (STA id (Mac Address)) received in a Associate-Mobile message, increment a COUNTER for that station. If this counter exceeds a certain LWAPHP_MAX_ATTEMPT_COUNT within an LWAPHP_TIME_FRAME unit of time, a Associate-Mobile-Reply is generated indicating how long it should be ignored (in seconds), and denoted as Associate-Mobile-IGNORE. This should prevent excess network traffic due to a malicious or malfunctioning STA. If none of these conditions are met, the AR send a Associate-Mobile-Reply with the status of SUCCESS back to the AP NAP New AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AR ONAP NNAP | ARq | | | | |---------->| | | | Sidhu & Sarikaya Expires August 3, 2004 [Page 32] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 | | ASRq | | | | |---------->| | | | | |AU | | | | | | | | | | | | | | | | | | | ASR | | | | |<----------| | | | AR | | | | |<----------| | | | | | H-CC-U | | | | |---------->| | | | | | | H-CC-N | | | |------------------->| | | | H-CC-D | | | | |-------->| | | | | | | 1) ARq ASSOSIATE REQUEST 2) ASRq Associtation Mobile Request AU Authentication Occurs 3) ASR Association Mobile Response 4) AR ASSOSIATE RESPONSE 7) H-CC-U Hoff-CachedContex-Update 8) H-CC-N Hoff-CachedContex-New (to all NNAP) 9) H-CC-D Hoff-CachedContex-Drop (to all ONAP) Figure 5: Association Request Scenario 9.2 Association Mobile Reply (Association-Mobile-Reply) This message is sent by the AR to the AP which had sent a Associate-Mobile message to it. 9.2.1 Sending Associate-Mobile-Reply The message contains the status of whether the association mobile request was processed and it was successful or not. {Associate-Mobile-Reply, Status} Status is of Result Code type. 9.2.2 Receiving Association-Mobile-Reply When a AP receives a Associate-Mobile-Reply message, it sends the station that requested the association a 802.11 associate response Sidhu & Sarikaya Expires August 3, 2004 [Page 33] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 back.The response varies depending upon the status of the Associate-Mobile-Reply message. If Status is SUCCESS then mobile station is informed about the connection and traffic from that station is now routed to the AR. If any other status message is received then failure status is returned back to the mobile station. Also, on success the AP will construct a Hoff-CachedContext-Update message and send it to the AR. This is to activate the pro-active caching for future Handoffs if required by the mobile station. See Figure 5 9.3 Handoff Init (Hoff-Init) This message is used by an AP to inform the AR that a STA has requested a re-association with it via an 802.11 re-associate request. The Hoff-Init message (as described in 1.2) is used in the non-cached scenario. 9.3.1 Sending Hoff-Init When the AP receives an 802.11 re-associate requests, it first performs any authentication necessary. The AP will then check to see if it has cached information on the STA, if it does not then sends the Hoff-Init message to the AR. If cached information does exist, a Hoff-CachedContext message is generated. The message contains the STA id of the mobile (Mac Address), and the id of the AP(Mac Address) the STA used to be associated with. {Hoff-Init, STA id(Mac Address), old AP id(Mac Address)} STA id and old AP id are of AR Adress Type. 9.3.2 Receiving Hoff-Init When an AR receives a Hoff-Init it first checks that the STA id (Mac Address) is one that is authorized to use the network. This step will actually be optional, and will usually be skipped as any STA which has access to the network already and is making a valid re-associate request has already been authorised on the original associate request. In the case where additional authentication is required though, it would happen here. If authentication is not granted to the STA a Hoff-Init-Reply is returned to the AP indicating failure (HOFF-NOAUTH). The AR also checks if the last AP the STA says it was associated with matches the entry in the MOBILE_CACHE table. If it does not, the AR sends a Hoff-Init-Reply indicating failure (HOFF-BADASSOC). If this check reveals that the STA did not have a Sidhu & Sarikaya Expires August 3, 2004 [Page 34] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 previous association within the AR MOBILE_CACHE table a Hoff-Init-Reply failure with HOFF-NOASSOC is sent, this will require the STA to attempt a fresh association. If the AP the STA is attempting to re-associate with is the AP which the AR has currently associated (for routing), then we send a Hoff-Init-Reply with HOFF-STALE to indicate a stale handoff. Sources of this stale move could be packet delay on the IP network, which could cause a situation where the old Hoff-Init was delayed meanwhile the station timed-out and attempted to re-associate again and succeeded. With each unique (STA id (Mac Address), old AP id(Mac Address) ) pair received in a Hoff-Init message, increment a counter for that pair. If this counter exceeds LWAPHP_MAX_ATTEMPT_COUNT within an LWAPHP_TIME_FRAME unit of time, a Hoff-Init-Reply is generated indicating how long it should be ignored (in seconds), and denoted as HOFF-IGNORE. This should prevent excess network traffic due to a malicious or malfunctioning STA. If none of these conditions are met, the AR send a Hoff-Context-Request to the indicated previous AP. Sidhu & Sarikaya Expires August 3, 2004 [Page 35] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AR OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-I | | | | | |---------->| | | | | | |AU | | | | | H-I-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | | | | | 1) RARq RE-ASSOSIATE REQUEST 2) H-I Hoff-Init AU Authentication Occurs 5) H-I-R Hoff-Init-Reply {NOAUTH, BADASSOC, NOASSOC, IGNORE} 6) RAR RE-ASSOSIATE RESPONSE FAIL Figure 6: Failure of types NOAUTH, BADASSOC, NOASSOC, or IGNORE non cached scenario 9.4 Hoff-Context-Request This message is generated by an AR and sent to the AP a STA has indicated it was previously associated with. It requests any stored context for that mobile. The message contains the STA id (Mac Address) for which the context is desired. {Hoff-Context-Request, STA id (Mac Address)} STA id is of AR Adress Type. 9.4.1 Sending Hoff-Context-Request When the received Hoff-Init passes the tests at the AR, it considers it a valid initiation request and generates this message for the indicated previous AP. Sidhu & Sarikaya Expires August 3, 2004 [Page 36] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 9.4.2 Receiving Hoff-Context-Request When an AP receives a Hoff-Context-Request, it checks to see what context it has for the mobile indicated by STA id (Mac Address) . If such context exists, the Hoff-Context-Reply is generated and sent to the AR. The context in this message may be null. The situation where no context is found is FFS. One option is to merely send a Hoff-Context-Reply with a null context field, so the AR and new AP could rebuild the context. The second option is to indicate failure in the Hoff-Context-Reply. This may be desirable if it is guaranteed that the AP should have context. If this context is missing, it could indicate a malfunctioning AP or other problems. 9.5 Hoff-Context-Reply The Hoff-Context-Reply encapsulates the requested STA context. It contains the mobile Id (Mac Address), the sending AP id (Mac Address) and the context {Hoff-Context-Reply, STA id (Mac Address) , AP id (Mac Address) , context block} STA id and AP id are of AR Adress Type. 9.5.1 Sending Hoff-Context-Reply The necessary conditions for sending this message is outlined in Hoff-Init. At this time the AP changes the status of the STA to cached (to signify not-connected). 9.5.2 Receiving Hoff-Context-Reply On receiving this message the AR matches the context to the corresponding Hoff-Init message using the STA id (Mac Address) and sending AP id (Mac Address) . The AR appends any context it contains for that mobile (e.g. session key) and encapsulates both into a successful Hoff-Init-Reply if the Hoff-Context-Reply indicates success, if not it generates a Hoff-Init-Reply indicating failure (HOFF-NOCXT) and in both cases in sends the message immediately to the AP. Sidhu & Sarikaya Expires August 3, 2004 [Page 37] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AR OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-I | | | | | |---------->| | | | | | |AU | | | | | | H-C-Rq | | | | | |-------->| | | | | | H-C-R | | | | | |<--------| | | | | H-I-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | 1) RARq RE-ASSOSIATE REQUEST 2) H-I Hoff-Init AU Authentication Occurs 3) H-C-Rq Hoff-Context-Request 4) H-C-R Hoff-Context-Reply {FAIL, NULL} 5) H-I-R Hoff-Init-Reply NOCXT 6) RAR RE-ASSOSIATE RESPONSE FAIL Figure 7: Failure of type NOCXT in cached scenario 9.6 Hoff-Init-Reply This message is generated to inform the AP the STA is attempting to re-associate with whether or not to accept the re-association request. The format of the reply contains: {Hoff-Init-Reply, STA id (Mac Address), status, context block} STA id and old AP id are of AR Adress Type. Status is of Result Code Type. Context block here is the AP context block plus we have added the AR session key context to this parameter. Sidhu & Sarikaya Expires August 3, 2004 [Page 38] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 9.6.1 Sending Hoff-Init-Reply Covered in Receiving Hoff-Context-Request, message generated in response to the Hoff-Context-Reply. 9.6.2 Receiving Hoff-Init-Reply When the AP receives a Hoff-Init-Reply, there are two possibilities: 1. Success indicated: incorporate received context into locally stored context and indicate to STA that it may re-associate. 2. Failure indicated: inform STA that it may not associate (if required). On success the AP will construct a Hoff-CachedContext-Update message and send it to the AR. NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AR OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-I | | | | | |---------->| | | | | | |AU | | | | | | H-C-Rq | | | | | |-------->| | | | | | H-C-R | | | | | |<--------| | | | | H-I-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | H-CC-U | | | | | |---------->| | | | | | | | | H-CC-N | | | |-------->+----------+---------->| | | | | H-CC-D | | | | |---------+--------->| | | | | | | | 1) RARq RE-ASSOSIATE REQUEST Sidhu & Sarikaya Expires August 3, 2004 [Page 39] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 2) H-I Hoff-Init AU Authentication Occurs 3) H-C-Rq Hoff-Context-Request 4) H-C-R Hoff-Context-Reply 5) H-I-R Hoff-Init-Reply 6) RAR RE-ASSOSIATE RESPONSE 7) H-CC-U Hoff-CachedContex-Update 8) H-CC-N Hoff-CachedContex-New (to OAP and all NNAP) 9) H-CC-D Hoff-CachedContex-Drop (to all ONAP) Figure 8: Success in scenario where STA is not cached at AP 9.7 Hoff-CachedContext This message is used by an AP to inform the AR that a STA has requested a re-association with it via an 802.11 re-associate request. It is used in the scenario where the AP already has cached context information for the STA. 9.7.1 Sending Hoff-CachedContext As described in Sending Hoff-Init if the AP finds the STA as cached it will send a Hoff-CachedContext message to the AR. This indicates that the STA was previously associated with one of the APs known neighbours. The message contains the STA id (Mac Address) of the mobile, and the id of the AP (Mac Address) the STA used to be associated with. {Hoff-CachedContext, STA id (Mac Address), old AP id (Mac Address)} STA id and old AP id are of AR Adress Type. 9.7.2 Receiving Hoff-CachedContext As receiving Hoff-CachedContext is the cached parallel to receiving the non-cached Hoff-Init, it follows that the procedure is very similar. When an AR receives a Hoff-CachedContext it may need to do some authentication. As in 1.3 the step is optional, and is even less likely to be required here then in the Hoff-Init case. In the case where additional authentication is required though, it would happen here. If authentication is not granted to the STA a Hoff-CachedContext-Reply is returned to the AP indicating failure (HOFF-NOAUTH). The AR also checks if the last AP the STA says it was associated with matches the entry in the MOBILE_CACHE table. If it does not, the AR sends a Hoff-Init-Reply indicating failure (HOFF-BADASSOC). If this check reveals that the STA did not have a Sidhu & Sarikaya Expires August 3, 2004 [Page 40] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 previous association within the AR MOBILE_CACHE table a Hoff-Init-Reply failure with HOFF-NOASSOC, both of these types of failure (BADASSOC, and NOASSOC) will also indicate that there is a problem somewhere, but dealing with that error will raise a LWAPHP_HANDOFF_FAILURE condition. When LWAPHP_HANDOFF_FAILURE condition is raised what will happen is for further study (FFS). If the AP the STA is attempting to re-associate with is the AP which the AR has currently associated (for routing), then we send a Hoff-CachedContext-Reply with HOFF-STALE to indicate a stale handoff. Again, as with the Hoff-Init messages, with each unique (STA id (Mac Address), old AP id (Mac Address)) pair received in a Hoff-CachedContext message, increment a counter for that pair. If this counter exceeds LWAPHP_MAX_ATTEMPT_COUNT within an LWAPHP_TIME_FRAME unit of time, a Hoff-CachedContext-Reply is generated indicating how long it should be ignored (in seconds), and denoted as HOFF-IGNORE. This should prevent excess network traffic due to a malicious or malfunctioning STA. If everything checks out, a successful Hoff-CachedContext-Reply is generated. Sidhu & Sarikaya Expires August 3, 2004 [Page 41] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AR OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-CC | | | | | |---------->| | | | | | |AU | | | | | H-CC-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | | | | | 1) RARq RE-ASSOSIATE REQUEST 2) H-CC Hoff-CachedContext AU Authentication Occurs 3) H-CC-R Hoff-CachedContext-Reply {NOAUTH, BADASSOC, NOASSOC, IGNORE} 4) RAR RE-ASSOSIATE RESPONSE FAIL Figure 9: Failure of types NOAUTH, BADASSOC, NOASSOC, or IGNORE cached scenario 9.8 Hoff-CachedContext-Reply This message is generated by an AR and sent to the AP which a STA is trying to associate with. The message contains the STA id (Mac Address). 9.8.1 Sending Hoff-CachedContext-Reply In the case of failure as determined in Receiving Hoff-CachedContext the Hoff-CachedContext-Reply will be sent indicating failure, otherwise it informs the AP that the that the mobile can be asserted as currently active. The format of the reply is: {Hoff-CachedContext-Reply, STA id (Mac Address),status} STA id is of AR Adress Type and status is of Result Code Type. Sidhu & Sarikaya Expires August 3, 2004 [Page 42] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 9.8.2 Receiving Hoff-CachedContext-Reply When the AP receives this message it can immediately change the status of the STA to active, and based on cached context communicate immediately. After the mobile is connected (active) and communicating successfully, the AP sends a Hoff-CachedContext-Update message to the AR. NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AR OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-CC | | | | | |---------->| | | | | | |AU | | | | | H-CC-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | H-CC-U | | | | | |---------->| | | | | | | | | H-CC-N | | | |-------->+----------+---------->| | | | | H-CC-D | | | | |---------+--------->| | | | | | | | 1) RARq RE-ASSOSIATE REQUEST 2) H-CC Hoff-CachedContext AU Authentication Occurs 3) H-CC-R Hoff-CachedContext-Reply 4) RAR RE-ASSOSIATE RESPONSE 5) H-CC-U Hoff-CachedContex-Update 6) H-CC-N Hoff-CachedContex-New (to OAP and all NNAP) 7) H-CC-D Hoff-CachedContex-Drop (to all ONAP) Figure 10: Success in scenario where STA is cached at AP Sidhu & Sarikaya Expires August 3, 2004 [Page 43] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 9.9 Hoff-CachedContext-Update This message will contain all the cached information from the STA as well as a flag indicating if any of the cached information was changed during the re-association. In the case where the mobile was not previously cached (message generated after Receiving Hoff-Init-Reply) the changed flag will be marked true. As the handover has already occurred, and this is setting up the fast handovers in the future, the Hoff-CachedContext-Update message can be processed at a lower priority to that of the other Hoff messages. 9.9.1 Sending Hoff-CachedContext-Update Hoff-CachedContext-Update is sent from the new AP to the AR. It will be sent as defined in Sending Hoff-CachedContext-Reply and Sending Hoff-Init-Reply, and indicates that the mobile has been successfully added to the AP, and is used to propagate new cached information for the STA. The format of the message is: {Hoff-CachedContext-Update, STA id (Mac Address), status, context block} STA id is of AR Adress Type and status is of Result Code Type. 9.9.2 Receiving Hoff-CachedContext-Update When the AR receives this message the proactive caching procedure is started. The AR will first see if any of the cached information has changed (based on the flag within the message). If there have been changes the AR will send a Hoff-CachedContext-New to all APs which are neighbours (as defined in the Neighbour list kept at the AR) of the new AP, including the previous AP. If the context has not changed then the list of APs which get the Hoff-CachedContext-New is all the APs which are neighbours of the new AP, but were not neighbours of the old access point (again including the old AP). After sending out the Hoff-CachedContext-New messages, the AR finds all the APs which were neighbours of the old AP, but not neighbours of the new AP (not including the new AP). The Aps in this list receive a request containing the Hoff-CachedContext-Drop message. 9.10 Hoff-CachedContext-New This message contains all the up to date information for the mobile, and also includes that the STAs status is cached. Sidhu & Sarikaya Expires August 3, 2004 [Page 44] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 9.10.1 Sending Hoff-CachedContext-New As described in Receiving Hoff-CachedContext-Update the Hoff-CachedContext-New message is generated at the AR and sent to neighbours of the new AP, with the exact list to be determined based on the Hoff-CachedContext-Update message. Changes in the cached context require that the message be sent to all neighbours, and no change in the context allows the message to be sent to only new neighbours. In both cases the message should be sent to the old AP. The format of the message is: {Hoff-CachedContext-New, STA id (Mac Address), context block} STA id is of AR Adress Type. 9.10.2 Receiving a Hoff-CachedContext-New When an AP receives the Hoff-CachedContext-New message it finds the entry within its table, which matches the STA id (Mac Address) in the message and it, overwrites the current entry with the information from the Hoff-CachedContext-New message. In the case of the old AP, this will update the status to cached. For all other APs (and the old AP) this will insure that the cached context is up to date, and it accurately reflects the STAs which are currently associated with neighbouring APs. 9.11 Hoff-CachedContext-Drop This Message contains a STA id (Mac Address). 9.11.1 Sending Hoff-CachedContext-Drop As with the Hoff-CachedContext-New the Hoff-CachedContext-Drop is defined within Receiving Hoff-CachedContext-Update, and is sent to APs which are no longer neighbouring the STA. That is any AP which is a neighbour of the Old AP, but not a neighbour of the new AP will get this message. The Format is: {Hoff-CachedContext-Drop, STA id (Mac Address)} STA id is of AR Adress Type. 9.11.2 Receiving a Hoff-CachedContext-Drop The AP removes the identified STA context from its cache. A check Sidhu & Sarikaya Expires August 3, 2004 [Page 45] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 can be done to ensure that the STA context is in the cache first, and that it is not currently associated with the AP in question. Sidhu & Sarikaya Expires August 3, 2004 [Page 46] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 10. Security Considerations Security Concerns raised in LWAPP are also valid for the LWAPHP. This is in reference to the public key cryptography which is used for AP-AR communication. There are primarily two main security concerns: DOS attacks and malicious mobile trying to illegally gain entrance to the network. 1. Denial Of Service attacks are one of the main security issues that can be faced by a mobile network. LWAPHP provides mechanisms to overcome such a situation if it ever arises. APs route the association/re-association requests to the AR. AR processes these requests and informs the AP of how to respond. If AR receives more than a certain threshold of association/re-assoication requests (LWAPHP_MAX_ATTEMPT_COUNT as defined in LWAPHP configuration variables section) within a certain time period (LWAPHP_TIME_FRAME as defined in LWAPHP configuration variables section) then AR assumes a DOS attack is being presented to it or there is some malicious activity going on at the mobile end. It then, informs the AP to ignore any further communication from that mobile (using the MAC address) for LWAPHP_DOS_WAIT_TIME (defined in LWAPHP configuration variables section) before opening communication with that mobile again. 2. Another important security concern is when a mobile station is trying to maliciously assume another mobile's MAC address in order to gain entry to the network. To avoid such a situation, when a mobile station requests a re-association with an AP, the mobile station is required to send in MAC address and the id (MAC address) of the AP it was previously associated with. This is passed onto the AR by the AP. AR then checks whether the entry it has in its MOBILITY_CACHE table is the same as the one being sent by the AP. If so, then access is allowed. If not, then AR assumes that it is an attempt to breach security and it doesn't allow access to the network. Sidhu & Sarikaya Expires August 3, 2004 [Page 47] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 11. Acknowledgements The authors gratefully acknowledge the contributions of: Sean Boyden, Andrew Johnson and, Tyler Nielsen of UNBC. Sidhu & Sarikaya Expires August 3, 2004 [Page 48] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 12. IPR Statement This draft is IPR free. Sidhu & Sarikaya Expires August 3, 2004 [Page 49] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 References [1] "Advanced Encryption Standard (AES)", November 2001, . [2] "Counter with CBC-MAC (CCM)", January 2003, . [3] "IP DATAGRAM REASSEMBLY ALGORITHMS", July 1992, . [4] "Key words for use in RFCs to Indicate Requirement Levels", March 1997, . [5] "Randomness Recommendations for Security", December 1994, . [6] "Assigned Numbers: RFC 1700 is Replaced by an On-line Database", January 2002, . [7] "The Internet Standards Process Revision 3", October 1996, . [8] "Mobility Related Terminology", April 2003, . [9] "Light Weight Access Point Protocol (LWAPP)", June 2003. [10] "IEEE Std 802.11f/D6: Inter-Access Point Protocol", March 2003. [11] "WiFi Protected Access (WPA) rev 1.6", April 2003. [12] "IEEE Std 802.11i/3.0: Specification for Enhanced Security", November 2003. Authors' Addresses Kiranjit S. Sidhu UNBC 3934 Enemark Crescent Prince George, BC V2N 2X5 Phone: +1 250-564-8285 EMail: sidhuk@unbc.ca Sidhu & Sarikaya Expires August 3, 2004 [Page 50] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 Behcet Sarikaya UNBC Computer Science Dept. 3333 University Way Prince George, BC V2N 4Z9 Phone: +1 250-960-5551 EMail: sarikaya@unbc.ca Sidhu & Sarikaya Expires August 3, 2004 [Page 51] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 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 (2004). 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 assignees. 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 Sidhu & Sarikaya Expires August 3, 2004 [Page 52] Internet-Draft Light Weight AP Handover Protocol (LWAPHP) February 2004 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Sidhu & Sarikaya Expires August 3, 2004 [Page 53]