Network Working Group B. Sarikaya Internet-Draft R. Jaksa Expires: December 25, 2006 C. Williams Huawei USA June 23, 2006 CAPWAP Handover Protocol (CAPWAPHP) draft-sarikaya-capwap-capwaphp-02 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 December 25, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 Termination Points (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 Sarikaya, et al. Expires December 25, 2006 [Page 1] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 transfer mechanism during handover using neighbor graphs. CAPWAPHP handles local MAC and Split MAC with separate procedures. CAPWAPHP can be transported using CAPWAP protocol. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Conventions used in this document . . . . . . . . . . . . 5 1.2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 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. Message Type . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Message Element . . . . . . . . . . . . . . . . . . . . . 11 3.3. CAPWAPHP Message Elements . . . . . . . . . . . . . . . . 11 3.3.1. MAC Address . . . . . . . . . . . . . . . . . . . . . 12 3.3.2. Location Data . . . . . . . . . . . . . . . . . . . . 12 3.3.3. Result Code . . . . . . . . . . . . . . . . . . . . . 12 3.3.4. Context Block . . . . . . . . . . . . . . . . . . . . 13 4. CAPWAPHP Messages . . . . . . . . . . . . . . . . . . . . . . 15 4.1. Context Transfer Messages . . . . . . . . . . . . . . . . 15 4.1.1. Context Transfer Data Message . . . . . . . . . . . . 15 4.1.2. Context Transfer Data Reply Message . . . . . . . . . 16 4.1.3. Context Transfer Cancel Message . . . . . . . . . . . 17 5. Handoff Management in CAPWAPHP . . . . . . . . . . . . . . . . 19 5.1. First Time Association - Local MAC WTP . . . . . . . . . . 19 5.2. Reassociation - Local MAC WTP . . . . . . . . . . . . . . 22 5.3. First Time Association - Split MAC . . . . . . . . . . . . 24 5.4. Reassociation - Split MAC . . . . . . . . . . . . . . . . 26 5.5. MOBILITY_CACHE Update Request . . . . . . . . . . . . . . 27 5.5.1. Sending MOBILITY_CACHE Update Requests . . . . . . . . 27 5.5.2. Format of a MOBILITY_CACHE Update Request . . . . . . 27 5.5.3. Receiving MOBILITY_CACHE Update Requests . . . . . . . 27 5.6. MOBILITY_CACHE Update Response . . . . . . . . . . . . . . 27 5.6.1. Sending MOBILITY_CACHE Update Responses . . . . . . . 28 5.6.2. Format of a MOBILITY_CACHE Update Response . . . . . . 28 5.6.3. Receiving MOBILITY_CACHE Update Responses . . . . . . 28 5.7. Location Update Request . . . . . . . . . . . . . . . . . 28 5.7.1. Sending Location Update Requests . . . . . . . . . . . 28 5.7.2. Format of a Location Update Request . . . . . . . . . 28 5.7.3. Receiving Location Update Requests . . . . . . . . . . 28 5.8. Location Update Response . . . . . . . . . . . . . . . . . 29 5.8.1. Sending Location Update Responses . . . . . . . . . . 29 5.8.2. Format of a Location Update Response . . . . . . . . . 29 Sarikaya, et al. Expires December 25, 2006 [Page 2] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 5.8.3. Receiving Location Update Responses . . . . . . . . . 29 5.9. Layer 2 Update Frame Details . . . . . . . . . . . . . . . 29 6. Procotol Constants . . . . . . . . . . . . . . . . . . . . . . 30 7. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 32 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.1. Normative References . . . . . . . . . . . . . . . . . . . 33 9.2. Informative References . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Intellectual Property and Copyright Statements . . . . . . . . . . 36 Sarikaya, et al. Expires December 25, 2006 [Page 3] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 1. Introduction The emergence of simple 802.11 Access Points [WPA] 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. CAPWAP WG architecture document [capwap-arch] 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) [802.11f] which enables Access Points to exchange station context during Layer 2 handoffs. IEEE has recently deprecated IAPP [draft-aboba-ieee802-rel]. CAPWAPHP assumes a network configuration that consists of multiple WTPs connected either via layer 2 (Ethernet), or layer 3 (IP) to an AC. The WTPs 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 a transport mechanism based on CAPWAP. Because of this CAPWAPHP can easily be incorporated into CAPWAP. +-+802.11 frames +-+ 802.3 frames +-+ +-+ +-+ Local MAC +-+ +-+ 802.11 frames-Split MAC +-+ | |--------------------------------| | | | +-+ | | | |--------------| |----- ------ --| | | | 802.11 PHY/ | | CAPWAPHP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: CAPWAPHP Architecture CAPWAPHP aims at reducing the authentication delay during Layer 2 handoffs. CAPWAPHP protocol operations are dependent of local MAC or split MAC WTPs. CAPWAPHP can be implemented on local MAC or split MAC WTPs. This document describes the CAPWAPHP, a Layer 2 handover protocol Sarikaya, et al. Expires December 25, 2006 [Page 4] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 that allows handover of STAs from one WTP to another be managed by the AC. The rationale behind it is the fact that the AC manages a collection of WTPs and adding the task of handover management to the ACs is well warranted. In CAPWAPHP, the STA to WTP protocol is based on IEEE 802.11 and the WTP to AC transport is completely based on CAPWAP. 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 WTP. 2. For Local MAC WTPs, enable transfer of AAA context of a station among the neighboring WTPs. 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. For Split MAC WTPs, all AAA context is stored at the AC not at the WTPs. No context transfer is needed if all neighboring WTPs are Split MAP WTPs. 4. Use the generic encapsulation and transport mechanism, provided by CAPWAP. 5. Enable builtin security features to provide better protection for the WTPs and AC. 6. Ensure that the station has an association with a single WTP and when the station does a handover to another WTP, ensure that forwarding tables of the switches are updated. The CAPWAPHP protocol concerns itself on the interface between the stations and the WTP as well as the WTP 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 BCP 14 RFC 2119 Sarikaya, et al. Expires December 25, 2006 [Page 5] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 [STANDARDS]. 1.2. Acknowledgements We gratefully acknowledge Dr. Charles Clancy for clarifying Split-MAC operation. Sarikaya, et al. Expires December 25, 2006 [Page 6] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 2. Protocol Overview CAPWAPHP is a handover protocol defining how the station context maintained at each WTP when STA was connected to the WTP 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 the CAPWAP protocol for the WTP to AC communication and they are triggered by STAs' handover interactions with the WTPs. CAPWAPHP Transport Layer (CTL) is based on CAPWAP Transport Layer and is defined in section 3 of [capwap]. CTL defines the framing, fragmentation/reassembly, and multiplexing services to CAPWAPHP. CAPWAPHP begins its operation after a discovery phase in which WTPs will select an Access Router (AC) with which to associate and followed by the configuration exchange in which WTPs are provisioned and are enabled for operation. These are the phases defined in CAPWAP. CAPWAPHP handles smooth handover when a mobile station moves from one WTP to another WTP. When a mobile station moves under the range of another WTP, it sends a ReAssociation Request to the WTP. On receiving such a request from a mobile station, the Local MAC WTP sends an initiate handoff request to the AC (Hoff-Init). For both Local and Split MAC WTPs, authentication is based on IEEE 802.11i. Full 802.11i authentication is carried for the first time association of the stations. CAPWAPHP transfers AAA context to the neighbor Local MAC WTPs so that when the station reassociates with a neighbor WTP, only 4-way handshake of 802.11i authentication can be carried. For Split MAC WTPs, the context is kept at the AC and no context transfer is needed. 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 session key context. An specific example of AAA context to transfer between devices supporting IEEE 802.1X network port authentication is defined in [draft-aboba-context-802]. Sarikaya, et al. Expires December 25, 2006 [Page 7] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 --------------------------------------------------------------- | 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 WTPs monitor the activity of the mobile stations. When they haven't had any activity for a long time, TIMEOUT_PERIOD, then WTPs 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 CAPWAP [capwap], (e.g. ???Next to Fridge???). The WTPs 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 WTPs 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 for the purpose of keeping track of the neighbours (Representation of Figure 7 in [mishrashin2004]). Sarikaya, et al. Expires December 25, 2006 [Page 8] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 ---------------------------------------------- | Access Point ID | Neighbour ID | Channels | ---------------------------------------------- | 1 | 2 | {2,6,8} | | 1 | 5 | {6} | | 2 | 1 | {2,6,8} | | 2 | 3 | {6} | | 2 | 4 | (6) | | 2 | 5 | (2,6,8) | | 3 | 2 | (6) | ---------------------------------------------- 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 WTPs can communicate. 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 [TERMS] and in [capwap- arch]. Sarikaya, et al. Expires December 25, 2006 [Page 9] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 3. CAPWAPHP Packet Format All messages in CAPWAPHP are control messages. CAPWAPHP does not provide any tunneling of user data between AC and WTPs but uses CAPWAP's tunneling. CAPWAPHP protocol provides a communication channel between the WTP and the AC and has the distinct message types that are defined in Section 4. CAPWAPHP packet format follows CAPWAP control packet format as shown below: CAPWAP Control Packet (DTLS Security Required): +-----------------------------------------------------------+ | IP |UDP | DTLS | CAPWAP | Control | Message | DTLS | | Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | +-----------------------------------------------------------+ \-------authenticated-----------------/ \------------encrypted-------------------/ CAPWAPHP header has the same format as CAPWAP header defined in Section 4.1 of [capwap] when CAPWAP transport is used. All CAPWAPHP messages are sent encapsulated within the CAPWAPHP control header as the payload and have the format defined in Section 4.3.1 of [capwap]. 3.1. Message Type The Message Type field of CAPWAPHP control header identifies the function of the CAPWAPHP message. The valid values for Message Type Values are shown in Figure 5. The 32-bit message type field value is obtained using these message type values and the formula: Message Type = IANA Enterprise Number * 256 + Message Type Value An example value for IANA Enterprise number is IEEE 802.11 IANA Enterprise number which is 13277. Sarikaya, et al. Expires December 25, 2006 [Page 10] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 Description Value CAPWAP messages 1-26 Reserved 27-59 MOBILITY_CACHE Update Request 60 MOBILITY_CACHE Update Response 61 Location Update Request 62 Location Update Response 63 Associate Mobile-Request 64 Associate Mobile-Reply 65 Hoff-Init 66 Hoff-Init-Reply 67 Hoff-CachedContext 70 Hoff-CachedContext-Reply 71 Hoff-CachedContext-Update 72 Hoff-Notify 75 Context Transfer Data 0x3 Context Transfer Data Reply 0x5 Context Transfer Cancel 0x6 Figure 5: Message Type Values 3.2. Message Element CAPWAPHP messages carry zero or more message elements. 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 Message 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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. 3.3. CAPWAPHP Message Elements CAPWAPHP messages MAY include a message element. The supported message elements are defined in this section. Sarikaya, et al. Expires December 25, 2006 [Page 11] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 The allowable values for the Type field are the following: Description Type CAPWAP Reserved 1-24 Location Data 25 CAPWAP Reserved 26-27 Result Code 28 CAPWAP Reserved 29-60 Context Block 61 MAC Addresses 62 IEEE 802.11 Message Elements 1024-2047 CAPWAP types fields are as described in Section 4.3.1.1 of [capwap]. 3.3.1. MAC Address MAC address message element contains the MAC addresses. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MAC address message element normally carries Sta ID and old AP ID to which STA was attached that are of MAC Address Type. This message element MUST be included as the first message element in all CAPWAPHP messages. This message element MAY be followed by zero or more message elements such as Context Block, Location Data, etc. 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 MUST be set to zero for such messages. 3.3.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.3.3. Result Code The result code message element value is a 32-bit integer value, Sarikaya, et al. Expires December 25, 2006 [Page 12] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 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 12 STALE_MOVE 13 BAD_ASSOC 14 NO_ASSOC 15 HOFF_NOAUTH 3.3.4. 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 [draft-aboba-context-802] 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sarikaya, et al. Expires December 25, 2006 [Page 13] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 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 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. Sarikaya, et al. Expires December 25, 2006 [Page 14] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 4. CAPWAPHP Messages The message type values are as given in Figure 5. These messages contain the parameters as defined in Section 5. Handoff-Init and Handoff-Init-Reply messages are not used in this version. 4.1. Context Transfer Messages Context transfer related control messages are encapsulated into CAPWAPHP payload following the same format as in [CxTP] which is different than the other control messages described so far. 4.1.1. Context Transfer Data Message This message's Type is 0x3. CTD message format is the same as in [CxTP] as follows: Sarikaya, et al. Expires December 25, 2006 [Page 15] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V|A| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Elapsed Time (in milliseconds) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous Care-of Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ First Context Data Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Next Context Data Block ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1 Type CTD = 0x3 (Context Transfer Data) 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. 'A' bit When set, the pAR requests an acknowledgement. Length Message length in units of octets. Elapsed Time The number of milliseconds since the transmission of the first CTD message for this MN. MN's Previous IP Address Field contains either: IPv4 Address, 4 octets, or IPv6 Address, 16 octets. Context Data Block The Context Data Block 4.1.2. Context Transfer Data Reply Message This message's Type is 0x5. Context Transfer Data Reply Message is the same as in [CxTP] as follows: Sarikaya, et al. Expires December 25, 2006 [Page 16] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V|S| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FPT (if present) | Status code | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ........ ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1 Type CTDR = 0x5 (Context Transfer Data) 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. 'S' bit When set to one, this bit indicates that all feature contexts sent in CTD were received successfully. Reserved Set to zero by the sender and ignored by the receiver. Length Message length in units of octets. MN's Previous IP Address Field contains either: IPv4 Address, 4 octets, or IPv6 Address, 16 octets. FPT 16 bit unsigned integer, listing the Feature Profile Type that is being acknowledged. Status Code A context-specific return value, zero for success, nonzero when 'S' is not set to one. 4.1.3. Context Transfer Cancel Message This message's Type is 0x6. Context Transfer Cancel Message is the same as in [CxTP] as follows: Sarikaya, et al. Expires December 25, 2006 [Page 17] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Vers.| Type |V| Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ Mobile Node's Previous IP Address ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vers. Version number of CXTP protocol = 0x1 Type CTC = 0x6 (Context Transfer Cancel) Length Message length in units of octets. 'V' flag When set to '0', IPv6 addresses. When set to '1', IPv4 addresses. Reserved Set to zero by the sender and ignored by the receiver. MN's Previous IP Address Field contains either: IPv4 Address, 4 octets, or IPv6 Address, 16 octets. Sarikaya, et al. Expires December 25, 2006 [Page 18] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 5. Handoff Management in CAPWAPHP A Handoff occurs when a mobile station moves from one Wireless Termination Point (WTP) to another WTP. This move could happen because of a number of reason such as the weakening of the strength of the signal from the current WTP. During the handoff process, management frames are exchanged between station (STA) and the WTP. We present CAPWAPHP scenarios starting with the two scenarios of local MAC WTP case followed by the two scenarios of the split MAC WTP case. Context information also changes hand between the old WTP to the new WTP via the AC. We use CxTP for context transfer [CxTP]. In local MAC WTP cases below it is assumed that WTP is capable of supporting 802.1X/EAP and 802.11i authentication as well as key management. WTP also has the AAA client installed. CAPWAP specification on the other hand leaves 802.1X/EAP support and RSNA Key Management functions at the AC as well as AAA Client in Figure 6 of [capwap]. Handoff management in that case is very similar to Split MAC WTP cases as presented in Section 5.3 and Section 5.4. 5.1. First Time Association - Local MAC WTP When a WTP receives an 802.11 associate requests, it first performs any authentication necessary. The WTP then sends the Associate Mobile Request (ASRq) to the AC. This message is used by an WTP to inform the AC that a STA has requested an association with it via an 802.11 associate request. ASRq contains the STA id of the mobile (MAC Address). {ASRq, STA id, old AP id} STA id and old AP id are of MAC Adress Type. With each unique (STA id (MAC Address)) received in an 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 (ASR) with the status of SUCCESS back to the WTP. After a successful association with the WTP, 802.1X/EAP Sarikaya, et al. Expires December 25, 2006 [Page 19] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 authentication starts [802.11i]. AAA server is the authentication server (AS), WTP is the authenticator and STA is the supplicant. NAP New AP ONAP Old Neighbour AP NNAP Neighbour APs OTAP All non-neighbor APs STA NAP AC AAA ONAP NNAP OTAP Server | ARq | | | | | | |---------->| | | | | | | | ASRq | | | | | | |---------->| | | | | | | | | | | | | | | | | | | | | ASR | | | | | | |<----------| | | | | | AR | | | | | | |<----------| | | | | | /----------------------------\ |802.1X EAP authentication | \----------------------------/ | | H-CC-U | | | | | |---------->| | | | /-----------\ | CTD | | |802.11i | |------------------->| | |4-way HS | |H-Notify | | | \-----------/ |------------------------------>| | |Update | |------> | | | | 1) ARq ASSOCIATE REQUEST 2) ASRq Associtate Mobile Request 3) ASR Associate Mobile Reply 4) AR ASSOCIATE RESPONSE 802.1X/EAP Authentication 5) H-CC-U Hoff-CachedContext-Update 802.11i 4 way handshake Occurs 6) CTD Context Transfer Data 7) H-Notify Hoff-Notify (to all non-neighbor APs) 8) Update Frame Figure 6: Scenario 1- Local MAC WTP If 802.1X/EAP authentication succeeds indicating successful handoff, a Pairwise Master Key (PMK) is generated. The new AP sends the AAA context to AC with Hoff-CachedContext-Update (H-CC-U) message. The format of the message is: Sarikaya, et al. Expires December 25, 2006 [Page 20] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 {Hoff-CachedContext-Update, AP Id, status, context block} AP id is of MAC Adress Type and carries WTP MAC address and status is of Result Code Type and has the value success and the context block contains the AAA context including PMK. The new AP and STA are next involved in 802.11i 4-way handshake in order to generate the session key TK and other keys, e.g. GTK. When AC receives Hoff-CachedContext-Update message, it initiates the context update procedures. AC sends Context Transfer Data (CTD) message to all neighbor WTPs. WTPs receiving CTD first remove any stale associations with the STA and then cache the AAA context into their MOBILITY_CACHE table. AC can request an acknowledgement of CTD by setting the A bit, then WTPs respond with a Context Transfer Data Reply (CTDR) message. When a STA reassociates with this WTP, the table is consulted and if there is a matching entry, the STA context is activated in order to avoid a full 802.1X/EAP authentication exchange. After the context transfer, handoff related messaging takes place. AC sends Hoff-Notify message (H-Notify) to all non neighbor WTPs. Hoff-Notify message contains only MAC address of the station that has associated with the WTP. (Hoff-Notify STA id) WTPs 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 WTP at a given time. Upon successful handoff, WTP sends a Layer 2 Update frame to the distribution system (DS) in order to update forwarding tables in switches. Details are in Figure 10. If any other status message is received then failure status is returned back to the mobile station. See Figure 6. Sarikaya, et al. Expires December 25, 2006 [Page 21] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 5.2. Reassociation - Local MAC WTP NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP Neighbour APs STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | | H-CC | | | | | |---------->| | | | | | | | | | | | H-CC-R | | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | /-----------\ |802.11i | |4-way HS | \-----------/ | | H-CC-U | | | | | |---------->| | | | | | | | CTC | | | | |---------+--------->| | | | | | | CTD | | | |-------->+----------+---------->| | | | | | | 1) RARq RE-ASSOCIATE REQUEST 2) H-CC Hoff-CachedContext 3) H-CC-R Hoff-CachedContext-Reply 4) RAR RE-ASSOCIATE RESPONSE 802.11i 4-way Handshake Occurs 5) H-CC-U Hoff-CachedContext-Update 6) CTC Context Transfer Cancel (to all ONAP) 7) CTD Context Transfer Data (to OAP and all NNAP) Figure 7: Scenario 2 - Local MAC WTP In case STA hands over to a neighboring WTP that has already cached STA context, the signaling shown in Figure 7 is used. When a mobile station moves under the range of another WTP, it sends a ReAssociation Request to the AP. On receiving such a request from a mobile station, the WTP sends an initiate handoff request to the AC (Hoff-CachedContext). This indicates that the STA was previously associated with one of the WTP's known neighbours. Sarikaya, et al. Expires December 25, 2006 [Page 22] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 The message contains the STA id (MAC Address) of the mobile, and the id of the WTP (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. 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. With each unique (STA id (MAC Address), old AP id (MAC Address)) pair received in a Hoff-CachedContext message, AC increments 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 generated. The format of the reply is: {Hoff-CachedContext-Reply, STA id (MAC Address),status} STA id is of MAC Adress Type and status is of Result Code Type. Next 802.11i 4-way handshake will occur between STA and WTP. This will create new AAA context for STA. WTP sends Hoff-CachedContext- Update (H-CC-U) message to AC in order to update STA's context. When AC receives this message, it initiates the context update procedures. First a Context Transfer Cancel (CTC) message is sent to the old WTP. This message also serves to cancel any stale association with the old WTP. Next, Context Transfer Data message is sent to the old WTP and all other neighboring WTPs and it carries the new context. WTPs receiving CTC search STA entry in their MOBILITY_CACHE table and delete it if one is found. For WTPs receiving CTD, the action is the same as described in Section 5.1. Sarikaya, et al. Expires December 25, 2006 [Page 23] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 See Figure 7. 5.3. First Time Association - Split MAC When a Split MAC WTP receives an 802.11 associate requests ARq is tunneled to the AC. AC sends a reply frame to WTP with the status of SUCCESS. The reply also indicates that a full 802.1X/EAP authentication is needed. CAPWAP Config Request message containing Add Mobile and Mobile Session Key message elements sent from AC to WTP can be used. In the Mobile Session Key message element A-bit MUST be set to one. After a successful association with the WTP, 802.1X/EAP authentication starts. AAA server is the authentication server (AS) and STA is the supplicant. WTP acts like an authenticator to the STA and it tunnels all replies to AC to be processed at the AC. AC keeps the resulting key context, i.e. PMK. Sarikaya, et al. Expires December 25, 2006 [Page 24] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 NAP New AP ONAP Old Neighbour AP NNAP New Neighbour AP OTAP All non-neighbor APs STA NAP AC AAA Server NNAP OTAP | ARq | | | | | |---------->| | | | | | |---------->| | | | | |---------->| | | | | | | | | | | | | | | | | |<----------| | | | | |<----------| | | | | AR | | | | | |<----------| | | | | /---------------------------------\ |802.1X/EAP authentication | \---------------------------------/ /-----------------------\ |802.11i 4 way HS | \-----------------------/ | |Add Mobile | | |<----------| | |Update | | |------> | 1) ARq ASSOCIATE REQUEST 2) ARq tunneled 3) AR tunneled 4) AR ASSOCIATE RESPONSE 802.11i Authentication Occurs 5) Hoff CachedContext-Update H-CC-U 6) Update Frame Figure 8: Scenario 3 - Split MAC WTP Next, 802.11i 4-way handshake is performed between STA and AC to derive TK. AC sends the new context to WTP in CAPWAP Config Request message. CAPWAP Config Request message MUST contain Add Mobile and Mobile Session Key message elements. In the Mobile Session Key message element A-bit MUST be set to zero. Key field MUST contain the TK. AC keeps the AAA context and no context transfer related messaging occurs. After the context is transferred to STA, handoff related messaging takes place. If all WTPs are split-MAC WTPs then AC keeps all the Sarikaya, et al. Expires December 25, 2006 [Page 25] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 association state centrally and it does not need to send Hoff-Notify message (H-Notify) to all non neighbor WTPs to remove any stale associations they may have with the station whose MAC address was in the message. Upon successful handoff, WTP sends a Layer 2 Update frame to the distribution system in order to update forwarding tables in switches. Details are in Figure 10. If any other status message is received then failure status is returned back to the mobile station. See Figure 8. 5.4. Reassociation - Split MAC NAP New AP OAP Old AP ONAP Old Neighbour AP NNAP New Neighbour AP STA NAP AC OAP ONAP NNAP | RARq | | | | | |---------->| | | | | | |---------->| | | | | |---------->| | | | | | | | | | | |<----------| | | | | |<----------| | | | | RAR | | | | | |<----------| | | | | /-----------------------\ |802.11i 4-way HS | \-----------------------/ | |Add Mobile | | |<----------| 1) RARq RE-ASSOCIATE REQUEST 2) RARq tunneled 3) RAR tunneled 4) RAR RE-ASSOCIATE RESPONSE 802.11i 4-way Handshake Occurs 5) Hoff CachedContext-Update H-CC-U Figure 9: Scenario 4 - Split MAC WTP STA reassociates with a neighboring Split MAC WTP. It sends a Reassociate Request Frame. This frame is tunneled to AC. AC sends a reply frame to WTP with the status of SUCCESS. CAPWAP Config Request message containing Add Mobile and Mobile Session Key Sarikaya, et al. Expires December 25, 2006 [Page 26] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 message elements is sent from AC to WTP. In the Mobile Session Key message element A-bit MUST be set to one. This indicates that 802.11i 4-way handshake is needed. After a successful association with the WTP, and since WTP has STA context which is kept at AC, only 4-way exchange of 802.11i authentication is executed. 4-way handshake involves STA and AC and WTP does the bridging. 4-way handshake is triggered by AC picking up ANonce and then sending EAPoL-Key frame to WTP. At the end of 4-way handshake, the new context created is kept at the AC. When 4-way handshake terminates, AC sends CAPWAP Config Request message containing Add Mobile and Mobile Session Key message elements to WTP. In the Mobile Session Key message element A-bit MUST be set to zero. In some cases, TK is needed at WTP. In that case, AC transfers the TK to WTP in the Key field of Mobile Session Key message element. See Figure 9. 5.5. 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. 5.5.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. 5.5.2. Format of a MOBILITY_CACHE Update Request The MOBILITY_CACHE Update Request carries the following message elements: Station ID (MAC address) 5.5.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. 5.6. 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. Sarikaya, et al. Expires December 25, 2006 [Page 27] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 5.6.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). 5.6.2. Format of a MOBILITY_CACHE Update Response The MOBILITY_CACHE Update Response carries the following message elements: Status 5.6.3. Receiving MOBILITY_CACHE Update Responses No action is required on receiving MOBILITY_CACHE Update Responses. 5.7. Location Update Request The Location Update Request MAY be sent by the AP to the AC after receiving a (Re)Associate request. 5.7.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.7.2. Format of a Location Update Request The Location Update Request carries the following message elements: Location Data 5.7.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. Sarikaya, et al. Expires December 25, 2006 [Page 28] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 5.8. 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. 5.8.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). 5.8.2. Format of a Location Update Response The Location Update Response carries the following message elements: Status 5.8.3. Receiving Location Update Responses No action is required on receiving Location Update Responses. 5.9. Layer 2 Update Frame Details Layer 2 Update frame has the format shown in Figure 10. +--------------------------------------------------------+ | MAC DA | MAC SA | Length | DSAP | SSAP | Control | XID | +--------------------------------------------------------+ | 6 | 6 | 2 | 1 | 1 | 1 | 3 | +--------------------------------------------------------+ Figure 10: 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 [802.2]. Sarikaya, et al. Expires December 25, 2006 [Page 29] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 6. Procotol Constants CAPWAPHP_MAX_ATTEMPT_COUNT 32 CAPWAPHP_TIME_FRAME 60s CAPWAPHP_DOS_WAIT_TIME 3600s Sarikaya, et al. Expires December 25, 2006 [Page 30] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 7. Security Considerations Security Concerns raised in CAPWAP are also valid for the CAPWAPHP. CAPWAPHP secures all the message exchange with DTLS [dtls] as in CAPWAP. 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. WTPs 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 protocol constants section) within a certain time period (CAPWAPHP_TIME_FRAME as defined in protocol constants 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 protocol constants 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, et al. Expires December 25, 2006 [Page 31] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 8. Future Work Future versions of this document will contain, apart from the scenarios not yet covered, the following: A new section on fast roaming. This section will address IEEE 802.11r results [802.11r]. In particular, the need to use 802.11 authentication phase, the new key hierarchy and preauthentication will be addressed. A new section on inter domain roaming. In particular, the issues involved when roaming to a new domain requiring the change of an AC will be addressed. Clarify CAPWAP operation when CAPWAPHP is used. Sarikaya, et al. Expires December 25, 2006 [Page 32] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 9. References 9.1. Normative References [802.11f] "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. [802.11i] "IEEE Std 802.11i-2004: 802.11 Medium Access Control (MAC) Security enhancements", July 2004. [802.11r] "IEEE Std 802.11r/D2.1: 802.11 Fast BSS Transition", May 2006. [802.2] "IEEE Std 802.2: Logical Link Control", May 1998. [CxTP] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005, . [STANDARDS] "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, October 1997, . [TERMS] Manner, J. and M. Kojo, "Mobility Related Terminology", June 2004, . [WPA] "WiFi Protected Access (WPA) rev 1.6", April 2003. [capwap] Calhoun, P., Montemurro, M., and D. Stanley, "CAPWAP Protocol Specification", June 2006, . [capwap-arch] Yang, L., Zerfos, P., and E. Sadot, "Architecture Taxonomy for Control and Provisioning of Wireless Access Points(CAPWAP)", June 2005, . [dtls] Escorla, E. and N. Modadugu, "Datagram Transport Layer Security", April 2006, . Sarikaya, et al. Expires December 25, 2006 [Page 33] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 9.2. Informative References [draft-aboba-context-802] Aboba, B. and T. Moore, "A Model for Context Transfer in IEEE 802", October 2003, . [draft-aboba-ieee802-rel] Bell, L., Romanascu, D., and B. Aboba, "History of the IEEE 802/IETF Relationship", April 2005, . [mishrashin2004] 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, . Sarikaya, et al. Expires December 25, 2006 [Page 34] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: Email: sarikaya@ieee.org Robert Jaksa Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: rjaksa@huawei.com Carl Williams Huawei USA 1700 Alma Dr. Suite 100 Plano, TX 75075 Phone: +1 972-509-5599 Email: carlw@mcsr-labs.org Sarikaya, et al. Expires December 25, 2006 [Page 35] Internet-Draft CAPWAP Handover Protocol (CAPWAPHP) June 2006 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 (2006). 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, et al. Expires December 25, 2006 [Page 36]