Network Working Group B. Sarikaya Internet-Draft UNBC Expires: November 26, 2005 May 25, 2005 CAPWAP Handover Protocol (CAPWAPHP) draft-sarikaya-capwap-capwaphp-00 Status of this Memo 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 November 26, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document describes the Control And Provisioning of Wireless Access Points (CAPWAP) Handover Protocol (CAPWAPHP) which is a protocol allowing the access controller of CAPWAP Working Group architecture 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. CAPWAPHP is local MAC/ Split MAC/ remote MAC agnostic and can be transported by LWAPP, CTP, WiCoP Sarikaya Expires November 26, 2005 [Page 1] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 or SLAPP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Conventions used in this document . . . . . . . . . . . . 6 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 7 2.1 Description of the MOBILITY_CACHE Table . . . . . . . . . 7 2.2 Description of the Location Graph Concept . . . . . . . . 8 2.3 Description of the Neighbor Graph Concept . . . . . . . . 8 2.4 Definitions . . . . . . . . . . . . . . . . . . . . . . . 9 3. CAPWAPHP Packet Format . . . . . . . . . . . . . . . . . . . 10 3.1 CAPWAPHP Message Header Format-LWAPP Transport . . . . . . 10 3.1.1 Flags Field . . . . . . . . . . . . . . . . . . . . . 10 3.1.2 VER field . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3 RID . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4 Flags and Frag ID . . . . . . . . . . . . . . . . . . 10 3.1.5 Length . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.6 Status . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.7 RSSI . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.8 SNR . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.9 WLAN IDs . . . . . . . . . . . . . . . . . . . . . . . 11 3.1.10 Payload . . . . . . . . . . . . . . . . . . . . . . 12 3.2 CAPWAPHP Message Header Format-CTP Transport . . . . . . . 12 3.3 CAPWAPHP Message Header Format-WiCoP Transport . . . . . . 12 3.4 CAPWAPHP Message Header Format-SLAPP Transport . . . . . . 13 3.5 CAPWAPHP Messages . . . . . . . . . . . . . . . . . . . . 13 3.5.1 Message Format . . . . . . . . . . . . . . . . . . . . 13 3.6 CAPWAPHP Message Elements . . . . . . . . . . . . . . . . 16 3.6.1 Result Code . . . . . . . . . . . . . . . . . . . . . 16 3.6.2 Location Data . . . . . . . . . . . . . . . . . . . . 17 3.6.3 Context Block . . . . . . . . . . . . . . . . . . . . 17 3.7 CAPWAPHP Transport Layer . . . . . . . . . . . . . . . . . 18 3.7.1 Layer 2 . . . . . . . . . . . . . . . . . . . . . . . 18 3.7.2 Layer 3 Using LWAPP . . . . . . . . . . . . . . . . . 19 3.7.3 Layer 3 Using CTP . . . . . . . . . . . . . . . . . . 19 3.7.4 Layer 3 Using WiCoP . . . . . . . . . . . . . . . . . 19 3.7.5 Layer 3 Using SLAPP . . . . . . . . . . . . . . . . . 20 4. Handoff Management in CAPWAPHP . . . . . . . . . . . . . . . 21 4.1 First Time Association (Associate-Mobile) . . . . . . . . 22 4.1.1 Sending Associate-Mobile . . . . . . . . . . . . . . . 22 4.1.2 Receiving Associate-Mobile . . . . . . . . . . . . . . 22 4.2 Associate Mobile Reply . . . . . . . . . . . . . . . . . . 23 4.2.1 Sending Associate-Mobile-Reply . . . . . . . . . . . . 23 4.2.2 Receiving Associate-Mobile-Reply . . . . . . . . . . . 24 4.2.3 Receiving Hoff-CachedContext-Update . . . . . . . . . 24 4.2.4 Sending Hoff-Notify Message . . . . . . . . . . . . . 24 4.2.5 Receiving Hoff-Notify Message . . . . . . . . . . . . 24 Sarikaya Expires November 26, 2005 [Page 2] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.3 Handoff Init (Hoff-Init) . . . . . . . . . . . . . . . . . 24 4.3.1 Sending Hoff-Init . . . . . . . . . . . . . . . . . . 25 4.3.2 Receiving Hoff-Init . . . . . . . . . . . . . . . . . 25 4.4 Hoff-Context-Request . . . . . . . . . . . . . . . . . . . 26 4.4.1 Sending Hoff-Context-Request . . . . . . . . . . . . . 26 4.4.2 Receiving Hoff-Context-Request . . . . . . . . . . . . 27 4.5 Hoff-Context-Reply . . . . . . . . . . . . . . . . . . . . 27 4.5.1 Sending Hoff-Context-Reply . . . . . . . . . . . . . . 27 4.5.2 Receiving Hoff-Context-Reply . . . . . . . . . . . . . 27 4.6 Hoff-Init-Reply . . . . . . . . . . . . . . . . . . . . . 28 4.6.1 Sending Hoff-Init-Reply . . . . . . . . . . . . . . . 29 4.6.2 Receiving Hoff-Init-Reply . . . . . . . . . . . . . . 29 4.7 Hoff-CachedContext . . . . . . . . . . . . . . . . . . . . 30 4.7.1 Sending Hoff-CachedContext . . . . . . . . . . . . . . 31 4.7.2 Receiving Hoff-CachedContext . . . . . . . . . . . . . 31 4.8 Hoff-CachedContext-Reply . . . . . . . . . . . . . . . . . 32 4.8.1 Sending Hoff-CachedContext-Reply . . . . . . . . . . . 32 4.8.2 Receiving Hoff-CachedContext-Reply . . . . . . . . . . 33 4.9 Hoff-CachedContext-Update . . . . . . . . . . . . . . . . 34 4.9.1 Sending Hoff-CachedContext-Update . . . . . . . . . . 34 4.9.2 Receiving Hoff-CachedContext-Update . . . . . . . . . 34 4.10 Hoff-CachedContext-New . . . . . . . . . . . . . . . . . 34 4.10.1 Sending Hoff-CachedContext-New . . . . . . . . . . . 35 4.10.2 Receiving a Hoff-CachedContext-New . . . . . . . . . 35 4.11 Hoff-CachedContext-Drop . . . . . . . . . . . . . . . . 35 4.11.1 Sending Hoff-CachedContext-Drop . . . . . . . . . . 35 4.11.2 Receiving a Hoff-CachedContext-Drop . . . . . . . . 36 4.12 MOBILITY_CACHE Update Request . . . . . . . . . . . . . 36 4.12.1 Sending MOBILITY_CACHE Update Requests . . . . . . . 36 4.12.2 Format of a MOBILITY_CACHE Update Request . . . . . 36 4.12.3 Receiving MOBILITY_CACHE Update Requests . . . . . . 36 4.13 MOBILITY_CACHE Update Response . . . . . . . . . . . . . 36 4.13.1 Sending MOBILITY_CACHE Update Responses . . . . . . 36 4.13.2 Format of a MOBILITY_CACHE Update Response . . . . . 36 4.13.3 Receiving MOBILITY_CACHE Update Responses . . . . . 37 4.14 Location Update Request . . . . . . . . . . . . . . . . 37 4.14.1 Sending Location Update Requests . . . . . . . . . . 37 4.14.2 Format of a Location Update Request . . . . . . . . 37 4.14.3 Receiving Location Update Requests . . . . . . . . . 37 4.15 Location Update Response . . . . . . . . . . . . . . . . 37 4.15.1 Sending Location Update Responses . . . . . . . . . 37 4.15.2 Format of a Location Update Response . . . . . . . . 38 4.15.3 Receiving Location Update Responses . . . . . . . . 38 4.16 Layer 2 Update Frame Details . . . . . . . . . . . . . . 38 5. Security Considerations . . . . . . . . . . . . . . . . . . 39 6. IPR Statement . . . . . . . . . . . . . . . . . . . . . . . 40 6.1 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 40 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 Sarikaya Expires November 26, 2005 [Page 3] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 Author's Address . . . . . . . . . . . . . . . . . . . . . . 41 Intellectual Property and Copyright Statements . . . . . . . 42 Sarikaya Expires November 26, 2005 [Page 4] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 1. Introduction The emergence of simple 802.11 Access Points that are managed by a router (also known as an access controller, or AC) suggests that having a standardized, interoperable protocol called CAPWAP 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 [3], CTP [9] and WiCoP [10] are examples of such a protocol. SLAPP [11] provides a discovery phase followed by mutual AC and AP authentication followed by an image download protocol. CAPWAP WG architecture document [8] defines several architectures for deploying IEEE WLANs. CAPWAPHP is a protocol between the wireless termination points (WTP) and the access controller (AC) in order to manage the mobility of the stations (STA) in a single administrative domain. The protocol architecture is shown in Figure 1. WTP represents the physical device for an access point (AP). CAPWAPHP borrows ideas from IEEE 802.11F, the Inter-Access Point Protocol (IAPP) [5] which enables Access Points to exchange station context during Layer 2 handoffs. IEEE has recently deprecated IAPP [13]. CAPWAPHP assumes a network configuration that consists of multiple APs connected either via layer 2 (Ethernet), or layer 3 (IP) to an AC. The APs can be considered as remote RF interfaces, being controlled by the AC (see Figure 1) where AC could be connected to WTPs directly or there may be switched/ routed connections between the AC and WTPs. In this version of CAPWAPHP, we support split-MAC and local-MAC WTPs and define several transport mechanisms for CAPWAPHP: LWAPP [3], CTP [9], WiCoP and SLAPP [10][11]. Because of this CAPWAPHP can easily be incorporated into one of these protocols. +-+ 802.11frames +-+ | |----------------- Direct --| | | | +-+ Switched | | | |--------------| |----- Routed --| | | | 802.11 PHY/ | | CAPWAPHP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: CAPWAPHP Architecture CAPWAPHP does not require any real-time or non real-time MAC primitives to be transported to the AC and thereafter handled by the AC. CAPWAPHP aims at reducing the authentication delay during Layer 2 handoffs. Therefore CAPWAPHP protocol is independent of local MAC, Sarikaya Expires November 26, 2005 [Page 5] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 split MAC or remote MAC approaches. CAPWAPHP can be implemented on local MAC, split MAC or remote MAC APs. This document describes the CAPWAPHP, a Layer 2 handover protocol that allows handover of STAs from one AP to another be managed by the AC. The rationale behind it is the fact that the AC manages a collection of APs and adding the task of handover management to the ACs is well warranted. In CAPWAPHP, the STA to AP protocol is based on IEEE 802.11 and the AP to AC transport is completely based on either one of LWAPP, CTP, WiCoP or SLAPP. In future releases, the transport will be based on CAPWAP WG's protocol. CAPWAPHP will be extended for 802.16 controller anchored handover management of 802.16e mobiles connected to 802.16 base stations. Goals The following are goals for this protocol: 1. Provide smooth handover access to mobile stations when it enters the range of another AP. 2. Enable transfer of AAA context of a station among the neighboring APs. Neighbors to an AP are determined by the neighbor graph which is maintained at the AC. Handover time is reduced by AAA context transfer in the wired medium because the station can be authenticated faster. 3. Use the generic encapsulation and transport mechanism, provided by either one of LWAPP, CTP, WiCoP or SLAPP. 4. Enable builtin security features to provide better protection for the APs and AC. 5. Ensure that the station has an association with a single AP and when the station does a handover to another AP, ensure that forwarding tables of the switches are updated. The CAPWAPHP protocol concerns itself on the interface between the stations and the AP as well as the AP and the AC. Inter-AC communication is strictly outside the scope of this document. Direct mobile to AC communication is not possible unless AC is also the subnet router. 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 [1]. Sarikaya Expires November 26, 2005 [Page 6] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 2. Protocol Overview CAPWAPHP 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 AC. CAPWAPHP messages and procedures defined in this document represent extensions to either one of LWAPP, CTP or WiCoP for the AP to AC communication and they are triggered by STAs' handover interactions with the APs. CAPWAPHP Transport Layer (CTL) is based on either one of LWAPP, CTP, WiCoP or SLAPP Transport Layer and is defined in section Section 3.7. CTL defines the framing, fragmentation/ reassembly, and multiplexing services to CAPWAPHP for each transport. CAPWAPHP begins its operation after a discovery phase in which APs will select an Access Router (AC) with which to associate and followed by the configuration exchange in which APs are provisioned and are enabled for operation. These are the phases defined in AP management protocols such as LWAPP, CTP or WiCoP. CAPWAPHP 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 an initiate handoff request to the AC (Hoff-Init). When an AC 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_CACHE 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. CAPWAPHP also supports CachedContext features. The context of a station is updated in a timely fashion between APs and AC. 2.1 Description of the MOBILITY_CACHE Table Access controller 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 AC Sarikaya Expires November 26, 2005 [Page 7] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 session key context. An specific example of AAA context to transfer between devices supporting IEEE 802.1X network port authentication is defined in [12]. --------------------------------------------------------------- | 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 AC to remove entry from MOBILITY_CACHE Table. Entries are added/updated as part of the Association and Re-association requests. 2.2 Description of the Location Graph Concept The access controller (AC) stores a list as shown in the figure below for the purpose of keeping track of all the neighbour locations. -------------------------- | Location A | Location B | -------------------------- | 1 | 2 | | 3 | 4 | | 5 | 8 | | 9 | 10 | | 3 | 2 | -------------------------- Location A is the MAC address of AP and Location B is its location similar to the location Data of LWAPP [3], (e.g. ???Next to Fridge???). The APs during the discovery phase send a location field, specifying their location. AC 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. 2.3 Description of the Neighbor Graph Concept The access controller (AC) stores a list as shown in the figure below Sarikaya Expires November 26, 2005 [Page 8] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 for the purpose of keeping track of the neighbours (Representation of Figure 7 in [14]). ----------------------------------------------------- | Access Point ID | NeighBour ID | Channels | Flags | ----------------------------------------------------- | 1 | 2 | {2,6,8} | T | | 1 | 5 | {6} | T | | 2 | 1 | {2,6,8} | T | | 2 | 3 | {6} | T | | 2 | 4 | (6) | T | | 2 | 5 | (2,6,8) | T | | 3 | 2 | (6) | T | ----------------------------------------------------- where 1, 2, 3, 4, and 5 in the first two columns represent MAC addresses. Figure 4: Sample AC 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 an AP starts up during the discovery phase. This neighbour graph(or list) is stored at the AC level and the AC acts as the management entity which co-ordinates the association/re-association requests. 2.4 Definitions This Document uses terminology defined in [2] Sarikaya Expires November 26, 2005 [Page 9] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 3. CAPWAPHP Packet Format This section contains the general packet header format. The CAPWAPHP protocol is designed to be transport agnostic. Transport details can be found in Section 3.7. CAPWAPHP packets take the format described in Section 3.1 when transported in LWAPP, take the format described in Section 3.2 when transported CTP, take the format described in Section 3.3 when transported in WiCoP. 3.1 CAPWAPHP Message Header Format-LWAPP Transport CAPWAPHP message header has the following format when LWAPP transport is used. 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 |C|F|L| Frag ID | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status/WLANs | Payload... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: LWAPP Message Header 3.1.1 Flags Field The first byte contains several flag fields. 3.1.2 VER field The VER field identifies the CAPWAPHP protocol version carried in this packet. For this version of the protocol, the value of this field is 0. 3.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. 3.1.4 Flags and Frag ID As defined in [3]. Sarikaya Expires November 26, 2005 [Page 10] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 3.1.5 Length The value of this field is unsigned and indicates the number of bytes in the Payload field. 3.1.6 Status When an CAPWAPHP packet is transmitted from an AP to an AC, 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.7 RSSI RSSI is a signed, 8-bit value. It is the received signal strength indication, in dBm. 3.1.8 SNR SNR is a signed, 8-bit value. It is the signal to noise ratio of the received 802.11 frame, in dB. 3.1.9 WLAN IDs When a CAPWAPHP packet is transmitted from an AC 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 WLAN IDs field is encoded in the following manner: Sarikaya Expires November 26, 2005 [Page 11] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WLAN ID(s) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3.1.10 Payload The Payload field contains data equal in size to the value of the Length field, found within the CAPWAPHP header. 3.2 CAPWAPHP Message Header Format-CTP Transport CAPWAPHP message header has the following format when CTP transport is used. 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 |0|0|0|P|E| Type | Policy | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Id. | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Payload... +-+-+-+-+ Figure 6: CTP Message Header Format Ver Field, Flags Field are as defined in [9]. Type Field is a 1 byte field that identifies the message type. Session ID Field is a 2 byte field that includes a unique session identifier provisioned by the AC after successful authentication. The other fields are as defined in [9]. 3.3 CAPWAPHP Message Header Format-WiCoP Transport CAPWAPHP message header has the format shown in Figure 7 when WiCoP transport is used. Sarikaya Expires November 26, 2005 [Page 12] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 0 31 | 7 15 23 | |-------|-------|-------|-------|-------|-------|-------|-------| | | +---------------+-+-+-+-+-+-+-+-+-------------------------------+ | Version |M|D|C|R|E|F|L| | Reserve | +---------------+-+-+-+-+-+-+-+-+-------------------------------+ | Fragment ID | Fragment No. | Length | +---------------+---------------+-------------------------------+ Figure 7: WiCoP Message Header Format Version and other fields are as defined in [10]. Length specifies the length of the payload that follows. 3.4 CAPWAPHP Message Header Format-SLAPP Transport CAPWAPHP message header has the format shown in Figure 8 when SLAPP transport is used. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maj | Min | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: SLAPP Message Header Format Maj and Min are as described in [11]. Type is the message type as defined in Figure 11. Length is the length of the entire message including this header. 3.5 CAPWAPHP Messages All messages in CAPWAPHP are control messages. CAPWAPHP does not provide any tunneling of user data between AC and APs. CAPWAPHP protocol provides a communication channel between the AP and the AC and has the following distinct message types: Messages defined here. 3.5.1 Message Format All CAPWAPHP messages are sent encapsulated within the CAPWAPHP header (see Section 3.1) as the payload in LWAPP: Sarikaya Expires November 26, 2005 [Page 13] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 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] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 If CTP transport is used, the message payload takes the format given in Figure 9. If WiCoP transport is used, messages follow the WiCoP message header in Figure 7 and the message format is as given in Figure 10. 0 31 | 7 15 23 | |-------|-------|-------|-------|-------|-------|-------|-------| | | +---------------+---------------+-------------------------------+ | Msg Type | Reserve | Seq Num | +---------------+---------------+-------------------------------+ | Msg Element Length | +-------------------------------+ Figure 10 3.5.1.1 Message Type The Message Type field identifies the function of the CAPWAPHP message. The valid values for Message Type are shown in Figure 11. Sarikaya Expires November 26, 2005 [Page 14] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 Description Value LWAPP/CTP/WiCoP/SLAPP messages 1-40 Reserved 41-59 MOBILITY_CACHE Update Request 60 MOBILITY_CACHE Update Response 61 Location Update Request 62 Location Update Response 63 Association-Mobile-Request 64 Association-Mobile-Reply 65 Hoff-Init 66 Hoff-Init-Reply 67 Hoff-Context-Request 68 Hoff-Context-Reply 69 Hoff-CachedContext 70 Hoff-CachedContext-Reply 71 Hoff-CachedContext-Update 72 Hoff-CachedContext-New 73 Hoff-CachedContext-Drop 74 Hoff-Notify 75 Figure 11: Message Type Values 3.5.1.2 Sequence Number The Sequence Number Field is an identifier value to match request/ response packet exchanges. When an CAPWAPHP packet with a request message type is received, the value of the sequence number field is copied into the corresponding response packet. 3.5.1.3 Msg Element Length The Length field indicates the number of bytes following the Session ID field. 3.5.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 AC. 3.5.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 Sarikaya Expires November 26, 2005 [Page 15] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 CAPWAPHP message elements are defined next in Section 3.6 3.6 CAPWAPHP Message Elements As previously specified, the CAPWAPHP 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 LWAPP/CTP/WiCoP/Reserved 2-34 Location Data 35 LWAPP/CTP/Reserved 36-60 Context Block 61 LWAPP types fields are as described in [3] and CTP type fields are as described in [9] and WiCoP message elements are defined in [10]. 3.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 Sarikaya Expires November 26, 2005 [Page 16] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 0 Success 1 Failure 2 STALE_MOVE 3 BAD_ASSOC 4 NO_ASSOC 5 HOFF_NOAUTH 3.6.2 Location Data The location data message element is a variable length byte string containing user defined location information. The string is NOT zero terminated. 3.6.3 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 below. AAA context containing selected fields from [12] will be transported in this field. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of Context Block: A 16-bit integer that indicates the number of octets in the Context Block field. Sarikaya Expires November 26, 2005 [Page 17] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 Length of Session Key Payload: a 160-bit integer which is sent by the AC to the AP and includes the randomly generated session key, which is used to protect the CAPWAPHP control messages. Context Block: variable length field that contains the context information being forwarded for the reassociated STA. 3.7 CAPWAPHP Transport Layer The CAPWAPHP protocol can operate at layer 2 or 3 using LWAPP or at layer 3 using CTP or WiCoP. For layer 2 support, the CAPWAPHP 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 AC. Layer 3 support is provided by encapsulating the CAPWAPHP frames within UDP. 3.7.1 Layer 2 This section describes how the CAPWAPHP protocol is provided over native Ethernet frames. All CAPWAPHP frames are encapsulated within 802.3 frames, whose fields are defined below. 3.7.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 [3]. 3.7.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 [3]. 3.7.1.3 Ethertype The Ethertype field is set to 0x88bb. 3.7.1.4 CAPWAPHP Message Header Format over 802.3 MAC CAPWAPHP header is the same as described in Section 3.1. However, fragmentation/reassembly is managed using F,L and Frag ID fields. Multiplexing of control and data messages is done using the C bit. Sarikaya Expires November 26, 2005 [Page 18] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 3.7.2 Layer 3 Using LWAPP CAPWAPHP makes use of IPv4/UDP transport between the AP and the AC. Frame formats, framing, AC discovery, fragmentation/reassembly and multiplexing are as described in [3]. 3.7.2.1 CAPWAPHP Message Header Format over IPv4/UDP F and L bits and Frag ID field bits are not used and MUST be set to zero. The frame format is the same as LWAPP Control Frame as shown below: +--------------------------------------------+ | MAC Header | IP | UDP |CAPWAPHP Header[C=1]| +--------------------------------------------+ | Control Message | Message Elements ... | +-----------------+----------------------+ where CAPWAPHP Header is as shown in Figure 5 with C bit set to 1 and control message follows Figure 9. 3.7.3 Layer 3 Using CTP CAPWAPHP messages between APs and ACs are delivered by a UDP transport and the UDP port number is [TBD] as in [9]. The frame format is shown below: +--------------------------------------------+ | MAC Header | IP | UDP |Control Message | +--------------------------------------------+ | Message Elements ... | +----------------------+ In this case, CAPWAPHP message has the CTP header format given in Figure 6. 3.7.4 Layer 3 Using WiCoP CAPWAPHP messages between APs and ACs can be delivered by a UDP transport although in [10] only IPSEC transport is mentioned. If an IPSEC connection is available, CAPWAPHP messages are transported using IPSEC transport. The frame format is shown below: +--------------------------------------------+ | MAC Header | IP | UDP |CAPWAPHP Header[C=1]| +--------------------------------------------+ | Control Message | Message Elements ... | +-----------------+----------------------+ Sarikaya Expires November 26, 2005 [Page 19] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 where CAPWAPHP Header is as shown in Figure 7 with C bit set to 1 and control message has the WiCoP header format given in Figure 10. 3.7.5 Layer 3 Using SLAPP When SLAPP is used to transport CAPWAPHP, the rest of the message takes the format described in Figure 9. SLAPP provides a discovery phase to enable WTPs to discover an AC. SLAPP next provides secure authentication between AC and WTP using a connectionless (Datagram Transport Layer Security-DTLS) protocol. After this phase, CAPWAPHP can be used for station mobility management. Sarikaya Expires November 26, 2005 [Page 20] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4. Handoff Management in CAPWAPHP 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 CAPWAPHP where most of the management is done through the access controller (AC) and APs are kept as lightweight as possible. Context information also changes hand between the old AP to the new AP via the AC. 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 format of the first CAPWAPHP 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 | Length | Sta ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sta ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sta ID | old AP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | old AP ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This element may be followed by zero or more message elements such as Context Block, Location Data, etc. Type identifies the message (Hoff-Init, etc.) Value field and Length indicates the number of bytes in the Value field. Type values are as listed in Figure 11. Length = length of all parameters i.e. length of Sta ID + length of old AP id field i.e. Length = 2 * Length of AP Address field = 2 * 48 = 96 bits = Sarikaya Expires November 26, 2005 [Page 21] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 12 bytes if both Sta ID and Old AP Id fields are used. Note that some of the CAPWAPHP messages described below do not carry any station ID fields, e.g. MOBILITY_CACHE Update Response. The length field is set to zero for such messages. Sta ID and old AP ID are of MAC Address Type (as in Section 3.7.1). The Hoff-Init message element carries the information pertinent to the Hoff-Init message. 4.1 First Time Association (Associate-Mobile) This message is used by an AP to inform the AC 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. 4.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 AC. The message contains the STA id of the mobile (MAC Address). {Associate-Mobile, STA id, old AP id} STA id and old AP id are of MAC Adress Type. 4.1.2 Receiving Associate-Mobile When an AC receives a Associate-Mobile it first checks that the STA id (MAC Address) is the one that is authorized to use the network. If authentication is not granted to the STA, an 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 CAPWAPHP_MAX_ATTEMPT_COUNT within an CAPWAPHP_TIME_FRAME unit of time, an 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 AC send a Associate-Mobile- Reply with the status of SUCCESS back to the AP. Sarikaya Expires November 26, 2005 [Page 22] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 NAP New AP ONAP Old Neighbour AP NNAP New Neighbour AP OTAP All non-neighbor APs STA NAP AC ONAP NNAP OTAP | ARq | | | | | |---------->| | | | | | | ASRq | | | | | |---------->| | | | | | |AU | | | | | | | | | | | | | | | | | | | | | | | ASR | | | | | |<----------| | | | | AR | | | | | |<----------| | | | | | | H-CC-U | | | | | |---------->| | | | | | | | H-CC-N | | | | |------------------->| | | | |H-Notify | | | | | |------------------------------>| | | | | | | 1) ARq ASSOCIATE REQUEST 2) ASRq Associtate Mobile Request AU Authentication Occurs 3) ASR Associate Mobile Reply 4) AR ASSOCIATE RESPONSE 7) H-CC-U Hoff-CachedContext-Update 8) H-CC-N Hoff-CachedContext-New(to all NNAP) 9) H-Notify Hoff-Notify (to all non-neighbor APs) Figure 12: Associate Request Scenario 4.2 Associate Mobile Reply This message is sent by the AC to the AP which had sent an Associate- Mobile message to it. 4.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} Sarikaya Expires November 26, 2005 [Page 23] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 Status is of Result Code type. 4.2.2 Receiving Associate-Mobile-Reply When an AP receives an Associate-Mobile-Reply message, it sends the station that requested the association an 802.11 associate response 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 AC. Upon successful handoff, AP sends a Layer 2 Update frame to the distribution system in order to update forwarding tables in switches. Details are in Figure 18. 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 AC. This is to activate the pro-active caching for future Handoffs if required by the mobile station. 4.2.3 Receiving Hoff-CachedContext-Update When AC receives an Hoff-CachedContext-Update message it sends an Hoff-CachedContext-New message to all the neighboring APs. Details are described in Section 4.10.1. AC also sends an Hoff-Notify message to all other APs to the first time association of the station in the LAN segment. 4.2.4 Sending Hoff-Notify Message Hoff-Notify message contains only MAC address of the station that has associated with the AP. (Hoff-Notify STA id) 4.2.5 Receiving Hoff-Notify Message APs receive Hoff-Notify message remove any stale associations they may have with the station whose MAC address was in the message. Hoff-Notify message has the purpose of ensuring that a station is associated with a single AP at a given time. See Figure 12. 4.3 Handoff Init (Hoff-Init) This message is used by an AP to inform the AC that a STA has requested a re-association with it via an 802.11 re-associate request. The Hoff-Init message is used in the non-cached scenario. Sarikaya Expires November 26, 2005 [Page 24] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.3.1 Sending Hoff-Init When the AP receives an 802.11 re-associate request, 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 AC. 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 Sta ID or Old AP ID Type. 4.3.2 Receiving Hoff-Init When an AC 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 AC also checks if the last AP the STA says it was associated with matches the entry in the MOBILITY_CACHE table. If it does not, the AC sends a Hoff-Init-Reply indicating failure (HOFF-BADASSOC). If this check reveals that the STA did not have a previous association within the AC MOBILITY_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 AC 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 CAPWAPHP_MAX_ATTEMPT_COUNT within an CAPWAPHP_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 AC sends a Hoff-Context- Sarikaya Expires November 26, 2005 [Page 25] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 Request to the indicated previous AP. NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-I | | | | | |---------->| | | | | | |AU | | | | | H-I-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | | | | | 1) RARq RE-ASSOCIATE REQUEST 2) H-I Hoff-Init AU Authentication Occurs 5) H-I-R Hoff-Init-Reply {NOAUTH, BADASSOC, NOASSOC, IGNORE} 6) RAR RE-ASSOCIATE RESPONSE FAIL Figure 13: Failure of types NOAUTH, BADASSOC, NOASSOC, or IGNORE non cached scenario 4.4 Hoff-Context-Request This message is generated by an AC 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 MAC Adress Type. 4.4.1 Sending Hoff-Context-Request When the received Hoff-Init passes the tests at the AC, it considers it a valid initiation request and generates this message for the indicated previous AP. Sarikaya Expires November 26, 2005 [Page 26] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.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). AP also removes the association it had with STA id in order to ensure a single association of stations at a given time. If such context exists, the Hoff-Context-Reply is generated and sent to the AC. 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 AC 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. 4.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 MAC Adress Type. 4.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). 4.5.2 Receiving Hoff-Context-Reply On receiving this message the AC matches the context to the corresponding Hoff-Init message using the STA id (MAC Address) and sending AP id (MAC Address) . The AC 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. Sarikaya Expires November 26, 2005 [Page 27] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-I | | | | | |---------->| | | | | | |AU | | | | | | H-C-Rq | | | | | |-------->| | | | | | H-C-R | | | | | |<--------| | | | | H-I-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | 1) RARq RE-ASSOCIATE 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-ASSOCIATE RESPONSE FAIL Figure 14: Failure of type NOCXT in cached scenario 4.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 MAC Adress Type. Status is of Result Code Type. Context block here is the AP context block plus we have added the AC session key context to this parameter. Sarikaya Expires November 26, 2005 [Page 28] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.6.1 Sending Hoff-Init-Reply Covered in Receiving Hoff-Context-Request, message generated in response to the Hoff-Context-Reply. 4.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 AC. Sarikaya Expires November 26, 2005 [Page 29] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC 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-ASSOCIATE REQUEST 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-ASSOCIATE RESPONSE 7) H-CC-U Hoff-CachedContext-Update 8) H-CC-N Hoff-CachedContext-New(to OAP and all NNAP) 9) H-CC-D Hoff-CachedContext-Drop (to all ONAP) Figure 15: Success in scenario where STA is not cached at AP 4.7 Hoff-CachedContext This message is used by an AP to inform the AC 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. Sarikaya Expires November 26, 2005 [Page 30] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.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 AC. This indicates that the STA was previously associated with one of the AP's 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 MAC Adress Type. 4.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 AC receives a Hoff-CachedContext it may need to do some authentication. As in Section 4.3.2 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 AC also checks if the last AP the STA says it was associated with matches the entry in the MOBILITY_CACHE table. If it does not, the AC sends a Hoff-Init-Reply indicating failure (HOFF- BADASSOC). If this check reveals that the STA did not have a previous association within the AC MOBILITY_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 CAPWAPHP_HANDOFF_FAILURE condition. When CAPWAPHP_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 AC 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 CAPWAPHP_MAX_ATTEMPT_COUNT within an CAPWAPHP_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 Sarikaya Expires November 26, 2005 [Page 31] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 generated. NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-CC | | | | | |---------->| | | | | | |AU | | | | | H-CC-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | | | | | 1) RARq RE-ASSOCIATE REQUEST 2) H-CC Hoff-CachedContext AU Authentication Occurs 3) H-CC-R Hoff-CachedContext-Reply(NOAUTH,BADASSOC,NOASSOC,IGNORE) 4) RAR RE-ASSOCIATE RESPONSE FAIL Figure 16: Failure of types NOAUTH, BADASSOC, NOASSOC, or IGNORE cached scenario 4.8 Hoff-CachedContext-Reply This message is generated by an AC and sent to the AP which a STA is trying to associate with. The message contains the STA id (MAC Address). 4.8.1 Sending Hoff-CachedContext-Reply In the case of failure as determined in Section 4.7.2, 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} Sarikaya Expires November 26, 2005 [Page 32] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 STA id is of MAC Adress Type and status is of Result Code Type. 4.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 the cached context, it can start communication immediately. After the mobile is connected (active) and communicating successfully, the AP sends a Hoff- CachedContext-Update message to the AC. AP sends a Layer 2 Update frame to the distribution system in order to update forwarding tables in switches. Details are in Figure 18. NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-CC | | | | | |---------->| | | | | | |AU | | | | | H-CC-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | | | H-CC-U | | | | | |---------->| | | | | | | | | H-CC-N | | | |-------->+----------+---------->| | | | | H-CC-D | | | | |---------+--------->| | | | | | | | 1) RARq RE-ASSOCIATE REQUEST 2) H-CC Hoff-CachedContext AU Authentication Occurs 3) H-CC-R Hoff-CachedContext-Reply 4) RAR RE-ASSOCIATE 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-CachedContext-Drop (to all ONAP) Figure 17: Success in scenario where STA is cached at AP Sarikaya Expires November 26, 2005 [Page 33] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.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. 4.9.1 Sending Hoff-CachedContext-Update Hoff-CachedContext-Update is sent from the new AP to the AC. It will be sent as defined in Section 4.8.1 and Section 4.6.1, 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 MAC Adress Type and status is of Result Code Type. 4.9.2 Receiving Hoff-CachedContext-Update When the AC receives this message the proactive caching procedure is started. The AC will first see if any of the cached information has changed (based on the flag within the message). If there have been changes the AC will send a Hoff-CachedContext-New to all APs which are neighbours (as defined in the Neighbour list kept at the AC) 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 AC 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. 4.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. Sarikaya Expires November 26, 2005 [Page 34] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.10.1 Sending Hoff-CachedContext-New As described in Section 4.9.2 the Hoff-CachedContext-New message is generated at the AC 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. All APs that receive Hoff-CachedContext-New message MUST remove stale or previous associations that they may have with STA. The format of the message is: {Hoff-CachedContext-New, STA id (MAC Address), context block} STA id is of MAC Adress Type. 4.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. 4.11 Hoff-CachedContext-Drop This Message contains a STA id (MAC Address). 4.11.1 Sending Hoff-CachedContext-Drop As with the Hoff-CachedContext-New the Hoff-CachedContext-Drop is defined within Section 4.9.2, 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 MAC Adress Type. Sarikaya Expires November 26, 2005 [Page 35] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.11.2 Receiving a Hoff-CachedContext-Drop The AP removes the identified STA context from its cache. A check 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. 4.12 MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request is sent by the AP to the AC to delete the entry for the specified mobile station from the MOBILITY_CACHE Table. 4.12.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 AC. Thus, station id (MAC address) is required as part of the message. 4.12.2 Format of a MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request carries the following message elements: Station ID (MAC address) 4.12.3 Receiving MOBILITY_CACHE Update Requests When an AC 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. 4.13 MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response is sent by AC to AP to inform the AP whether the request to delete the station was successful or not. 4.13.1 Sending MOBILITY_CACHE Update Responses MOBILITY_CACHE Update Responses are sent by a AC after receiving a MOBILITY_CACHE Update Request. Response is a status element (SUCCESS or FAILURE). 4.13.2 Format of a MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response carries the following message elements: Sarikaya Expires November 26, 2005 [Page 36] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 Status 4.13.3 Receiving MOBILITY_CACHE Update Responses No action is required on receiving MOBILITY_CACHE Update Responses. 4.14 Location Update Request The Location Update Request is sent by the AP to the AC after receiving a Join request. 4.14.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. 4.14.2 Format of a Location Update Request The Location Update Request carries the following message elements: Location Data 4.14.3 Receiving Location Update Requests When a AC 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 AC. It then adds entries for all neighbours in the neighbour graph list. Finally, AC responds back with a Location Update Response message. 4.15 Location Update Response The Location Update Response is sent by AC to AP to inform the AP whether the request to update the location of AP was successful or not. 4.15.1 Sending Location Update Responses Location Update Responses are sent by a AC after receiving a Location Update Request. Response is a status element (SUCCESS or FAILURE). Sarikaya Expires November 26, 2005 [Page 37] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 4.15.2 Format of a Location Update Response The Location Update Response carries the following message elements: Status 4.15.3 Receiving Location Update Responses No action is required on receiving Location Update Responses. 4.16 Layer 2 Update Frame Details Layer 2 Update frame has the format shown in Figure 18. +--------------------------------------------------------+ | MAC DA | MAC SA | Length | DSAP | SSAP | Control | XID | +--------------------------------------------------------+ | 6 | 6 | 2 | 1 | 1 | 1 | 3 | +--------------------------------------------------------+ Figure 18: L2 Update Frame Format where MAC DA takes 6 octets and is the broadcast MAC address, MAC SA is 6 octets and is the MAC address of STA that has just been associated/ reassociated successfully. The Length field is set to 8 octets. The values of both DSAP and SSAP fields of length 1 octet is null. The Control field is of length 1 octet, XID Information Field is of length 3 octets. Control and XID fields are defined in [4]. Sarikaya Expires November 26, 2005 [Page 38] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 5. Security Considerations Security Concerns raised in LWAPP are also valid for the CAPWAPHP. This is in reference to the public key cryptography which is used for AP-AC 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. CAPWAPHP provides mechanisms to overcome such a situation if it ever arises. APs route the association/re-association requests to the AC. AC processes these requests and informs the AP of how to respond. If AC receives more than a certain threshold of association/re-assoication requests (CAPWAPHP_MAX_ATTEMPT_COUNT as defined in CAPWAPHP configuration variables section) within a certain time period (CAPWAPHP_TIME_FRAME as defined in CAPWAPHP configuration variables section) then AC 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 CAPWAPHP_DOS_WAIT_TIME (defined in CAPWAPHP 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 AC by the AP. AC 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 AC assumes that it is an attempt to breach security and it doesn't allow access to the network. Sarikaya Expires November 26, 2005 [Page 39] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 6. IPR Statement This draft is IPR free. 6.1 Acknowledgements The author gratefully acknowledges the contributions of S. Boyden, A. Johnson, T. Nielson, K. Sidhu and R. Pringle of UNBC. 7. References [1] "The Internet Standards Process Revision 3", RFC 2026, October 1996, . [2] "Mobility Related Terminology", April 2003, . [3] Calhoun, P., O'Hara, B., Kelly, S., Suri, R., Williams, M., Hares, S., and N. Cam Winget, "Light Weight Access Point Protocol (LWAPP)", March 2005, . [4] "IEEE Std 802.2: Logical Link Control", May 1998. [5] "IEEE Std 802.11F: IEEE Trial-Use Recommended Practice for Multi-Vendor Access Point Interoperability via an Inter-Access Point Protocol Across Distribution Systems Supporting IEEE 802.11 Operation", July 2003. [6] "WiFi Protected Access (WPA) rev 1.6", April 2003. [7] "IEEE Std 802.11i/3.0: Specification for Enhanced Security", November 2003. [8] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", November 2004, . [9] Singh , I., Francisco, P., Pakulski , K., and F. Backes , "CAPWAP Tunneling Protocol (CTP)", April 2005, . [10] Iino, S., Govindan, S., Sugiura, M., and H. Cheng, "Wireless LAN Control Protocol (WiCoP)", March 2005, . Sarikaya Expires November 26, 2005 [Page 40] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 [11] Narasimhan, P. and D. Harkins, "SLAPP : Secure Light Access Point Protocol", March 2005, . [12] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", October 2003, . [13] Bell, L., Romanascu, D., and B. Aboba, "History of the IEEE 802/IETF Relationship", April 2005, . [14] Mishra, A., Shin, M., Petroni, N., Clancy, C., and W. Arbaugh, "Proactive Key Distribution Using Neighbor Graphs", IEEE Wireless Communications pp.26-36, February 2004, . Author's Address Behcet Sarikaya UNBC Computer Science Dept. 3333 University Way Prince George, BC V2N 4Z9 Phone: +1 250-960-5551 Email: sarikaya@unbc.ca Sarikaya Expires November 26, 2005 [Page 41] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) May 2005 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 (2005). 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. Sarikaya Expires November 26, 2005 [Page 42]