RFC 5412
Lightweight Access Point Protocol
Independent Submission P. Calhoun Request for Comments: 5412 R. Suri Category: Historic N. Cam-Winget ISSN: 2070-1721 Cisco Systems, Inc. M. Williams GWhiz Arts & Sciences S. Hares B. O'Hara S. Kelly February 2010 Lightweight Access Point ProtocolAbstract
In recent years, there has been a shift in wireless LAN (WLAN) product architectures from autonomous access points to centralized control of lightweight access points. The general goal has been to move most of the traditional wireless functionality such as access control (user authentication and authorization), mobility, and radio management out of the access point into a centralized controller. The IETF's CAPWAP (Control and Provisioning of Wireless Access Points) WG has identified that a standards-based protocol is necessary between a wireless Access Controller and Wireless Termination Points (the latter are also commonly referred to as Lightweight Access Points). This specification defines the Lightweight Access Point Protocol (LWAPP), which addresses the CAPWAP's (Control and Provisioning of Wireless Access Points) protocol requirements. Although the LWAPP protocol is designed to be flexible enough to be used for a variety of wireless technologies, this specific document describes the base protocol and an extension that allows it to be used with the IEEE's 802.11 wireless LAN protocol. Status of This Memo This document is not an Internet Standards Track specification; it is published for the historical record. This document defines a Historic Document for the Internet community. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5412. IESG Note This RFC documents the LWAPP protocol as it was when submitted to the IETF as a basis for further work in the CAPWAP Working Group, and therefore it may resemble the CAPWAP protocol specification in RFC 5415 as well as other IETF work. This RFC is being published solely for the historical record. The protocol described in this RFC has not been thoroughly reviewed and may contain errors and omissions. RFC 5415 documents the standards track solution for the CAPWAP Working Group and obsoletes any and all mechanisms defined in this RFC. This RFC is not a candidate for any level of Internet Standard and should not be used as a basis for any sort of Internet deployment. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
Table of Contents
1. Introduction ....................................................8 1.1. Conventions Used in This Document ..........................9 2. Protocol Overview ..............................................10 2.1. Wireless Binding Definition ...............................11 2.2. LWAPP State Machine Definition ............................12 3. LWAPP Transport Layers .........................................20 3.1. LWAPP Transport Header ....................................21 3.1.1. VER Field ..........................................21 3.1.2. RID Field ..........................................21 3.1.3. C Bit ..............................................21 3.1.4. F Bit ..............................................21 3.1.5. L Bit ..............................................22 3.1.6. Fragment ID ........................................22 3.1.7. Length .............................................22 3.1.8. Status and WLANS ...................................22 3.1.9. Payload ............................................22 3.2. Using IEEE 802.3 MAC as LWAPP Transport ...................22 3.2.1. Framing ............................................23 3.2.2. AC Discovery .......................................23 3.2.3. LWAPP Message Header Format over IEEE 802.3 MAC Transport ......................................23 3.2.4. Fragmentation/Reassembly ...........................24 3.2.5. Multiplexing .......................................24 3.3. Using IP/UDP as LWAPP Transport ...........................24 3.3.1. Framing ............................................24 3.3.2. AC Discovery .......................................25 3.3.3. LWAPP Message Header Format over IP/UDP Transport ..25 3.3.4. Fragmentation/Reassembly for IPv4 ..................26 3.3.5. Fragmentation/Reassembly for IPv6 ..................26 3.3.6. Multiplexing .......................................26 4. LWAPP Packet Definitions .......................................26 4.1. LWAPP Data Messages .......................................27 4.2. LWAPP Control Messages Overview ...........................27 4.2.1. Control Message Format .............................28 4.2.2. Message Element Format .............................29 4.2.3. Quality of Service .................................31 5. LWAPP Discovery Operations .....................................31 5.1. Discovery Request .........................................31 5.1.1. Discovery Type .....................................32 5.1.2. WTP Descriptor .....................................33 5.1.3. WTP Radio Information ..............................34 5.2. Discovery Response ........................................34 5.2.1. AC Address .........................................35 5.2.2. AC Descriptor ......................................35 5.2.3. AC Name ............................................36 5.2.4. WTP Manager Control IPv4 Address ...................37
5.2.5. WTP Manager Control IPv6 Address ...................37
5.3. Primary Discovery Request .................................38
5.3.1. Discovery Type .....................................38
5.3.2. WTP Descriptor .....................................38
5.3.3. WTP Radio Information ..............................38
5.4. Primary Discovery Response ................................38
5.4.1. AC Descriptor ......................................39
5.4.2. AC Name ............................................39
5.4.3. WTP Manager Control IPv4 Address ...................39
5.4.4. WTP Manager Control IPv6 Address ...................39
6. Control Channel Management .....................................39
6.1. Join Request ..............................................39
6.1.1. WTP Descriptor .....................................40
6.1.2. AC Address .........................................40
6.1.3. WTP Name ...........................................40
6.1.4. Location Data ......................................41
6.1.5. WTP Radio Information ..............................41
6.1.6. Certificate ........................................41
6.1.7. Session ID .........................................42
6.1.8. Test ...............................................42
6.1.9. XNonce .............................................42
6.2. Join Response .............................................43
6.2.1. Result Code ........................................44
6.2.2. Status .............................................44
6.2.3. Certificate ........................................45
6.2.4. WTP Manager Data IPv4 Address ......................45
6.2.5. WTP Manager Data IPv6 Address ......................45
6.2.6. AC IPv4 List .......................................46
6.2.7. AC IPv6 List .......................................46
6.2.8. ANonce .............................................47
6.2.9. PSK-MIC ............................................48
6.3. Join ACK ..................................................48
6.3.1. Session ID .........................................49
6.3.2. WNonce .............................................49
6.3.3. PSK-MIC ............................................49
6.4. Join Confirm ..............................................49
6.4.1. Session ID .........................................50
6.4.2. PSK-MIC ............................................50
6.5. Echo Request ..............................................50
6.6. Echo Response .............................................50
6.7. Key Update Request ........................................51
6.7.1. Session ID .........................................51
6.7.2. XNonce .............................................51
6.8. Key Update Response .......................................51
6.8.1. Session ID .........................................51
6.8.2. ANonce .............................................51
6.8.3. PSK-MIC ............................................52
6.9. Key Update ACK ............................................52
6.9.1. WNonce .............................................52
6.9.2. PSK-MIC ............................................52
6.10. Key Update Confirm .......................................52
6.10.1. PSK-MIC ...........................................52
6.11. Key Update Trigger .......................................52
6.11.1. Session ID ........................................53
7. WTP Configuration Management ...................................53
7.1. Configuration Consistency .................................53
7.2. Configure Request .........................................54
7.2.1. Administrative State ...............................54
7.2.2. AC Name ............................................55
7.2.3. AC Name with Index .................................55
7.2.4. WTP Board Data .....................................56
7.2.5. Statistics Timer ...................................56
7.2.6. WTP Static IP Address Information ..................57
7.2.7. WTP Reboot Statistics ..............................58
7.3. Configure Response ........................................58
7.3.1. Decryption Error Report Period .....................59
7.3.2. Change State Event .................................59
7.3.3. LWAPP Timers .......................................60
7.3.4. AC IPv4 List .......................................60
7.3.5. AC IPv6 List .......................................61
7.3.6. WTP Fallback .......................................61
7.3.7. Idle Timeout .......................................61
7.4. Configuration Update Request ..............................62
7.4.1. WTP Name ...........................................62
7.4.2. Change State Event .................................62
7.4.3. Administrative State ...............................62
7.4.4. Statistics Timer ...................................62
7.4.5. Location Data ......................................62
7.4.6. Decryption Error Report Period .....................62
7.4.7. AC IPv4 List .......................................62
7.4.8. AC IPv6 List .......................................62
7.4.9. Add Blacklist Entry ................................63
7.4.10. Delete Blacklist Entry ............................63
7.4.11. Add Static Blacklist Entry ........................64
7.4.12. Delete Static Blacklist Entry .....................64
7.4.13. LWAPP Timers ......................................65
7.4.14. AC Name with Index ................................65
7.4.15. WTP Fallback ......................................65
7.4.16. Idle Timeout ......................................65
7.5. Configuration Update Response .............................65
7.5.1. Result Code ........................................65
7.6. Change State Event Request ................................65
7.6.1. Change State Event .................................66
7.7. Change State Event Response ...............................66
7.8. Clear Config Indication ...................................66
8. Device Management Operations ...................................66
8.1. Image Data Request ........................................66
8.1.1. Image Download .....................................67
8.1.2. Image Data .........................................67
8.2. Image Data Response .......................................68
8.3. Reset Request .............................................68
8.4. Reset Response ............................................68
8.5. WTP Event Request .........................................68
8.5.1. Decryption Error Report ............................69
8.5.2. Duplicate IPv4 Address .............................69
8.5.3. Duplicate IPv6 Address .............................70
8.6. WTP Event Response ........................................70
8.7. Data Transfer Request .....................................71
8.7.1. Data Transfer Mode .................................71
8.7.2. Data Transfer Data .................................71
8.8. Data Transfer Response ....................................72
9. Mobile Session Management ......................................72
9.1. Mobile Config Request .....................................72
9.1.1. Delete Mobile ......................................73
9.2. Mobile Config Response ....................................73
9.2.1. Result Code ........................................74
10. LWAPP Security ................................................74
10.1. Securing WTP-AC Communications ...........................74
10.2. LWAPP Frame Encryption ...................................75
10.3. Authenticated Key Exchange ...............................76
10.3.1. Terminology .......................................76
10.3.2. Initial Key Generation ............................77
10.3.3. Refreshing Cryptographic Keys .....................81
10.4. Certificate Usage ........................................82
11. IEEE 802.11 Binding ...........................................82
11.1. Division of Labor ........................................82
11.1.1. Split MAC .........................................83
11.1.2. Local MAC .........................................85
11.2. Roaming Behavior and 802.11 Security .....................87
11.3. Transport-Specific Bindings ..............................88
11.3.1. Status and WLANS Field ............................88
11.4. BSSID to WLAN ID Mapping .................................89
11.5. Quality of Service .......................................89
11.6. Data Message Bindings ....................................90
11.7. Control Message Bindings .................................90
11.7.1. Mobile Config Request .............................90
11.7.2. WTP Event Request .................................96
11.8. 802.11 Control Messages ..................................97
11.8.1. IEEE 802.11 WLAN Config Request ...................98
11.8.2. IEEE 802.11 WLAN Config Response .................103
11.8.3. IEEE 802.11 WTP Event ............................103
11.9. Message Element Bindings ................................105
11.9.1. IEEE 802.11 WTP WLAN Radio Configuration .........105
11.9.2. IEEE 802.11 Rate Set .............................107
11.9.3. IEEE 802.11 Multi-Domain Capability ..............107
11.9.4. IEEE 802.11 MAC Operation ........................108
11.9.5. IEEE 802.11 Tx Power .............................109
11.9.6. IEEE 802.11 Tx Power Level .......................110
11.9.7. IEEE 802.11 Direct Sequence Control ..............110
11.9.8. IEEE 802.11 OFDM Control .........................111
11.9.9. IEEE 802.11 Antenna ..............................112
11.9.10. IEEE 802.11 Supported Rates .....................113
11.9.11. IEEE 802.11 CFP Status ..........................114
11.9.12. IEEE 802.11 WTP Mode and Type ...................114
11.9.13. IEEE 802.11 Broadcast Probe Mode ................115
11.9.14. IEEE 802.11 WTP Quality of Service ..............115
11.9.15. IEEE 802.11 MIC Error Report From Mobile ........117
11.10. IEEE 802.11 Message Element Values .....................117
12. LWAPP Protocol Timers ........................................118
12.1. MaxDiscoveryInterval ....................................118
12.2. SilentInterval ..........................................118
12.3. NeighborDeadInterval ....................................118
12.4. EchoInterval ............................................118
12.5. DiscoveryInterval .......................................118
12.6. RetransmitInterval ......................................119
12.7. ResponseTimeout .........................................119
12.8. KeyLifetime .............................................119
13. LWAPP Protocol Variables .....................................119
13.1. MaxDiscoveries ..........................................119
13.2. DiscoveryCount ..........................................119
13.3. RetransmitCount .........................................119
13.4. MaxRetransmit ...........................................120
14. NAT Considerations ...........................................120
15. Security Considerations ......................................121
15.1. Certificate-Based Session Key Establishment .............122
15.2. PSK-Based Session Key Establishment .....................123
16. Acknowledgements .............................................123
17. References ...................................................123
17.1. Normative References ....................................123
17.2. Informative References ..................................124
1. Introduction
Unlike wired network elements, Wireless Termination Points (WTPs) require a set of dynamic management and control functions related to their primary task of connecting the wireless and wired mediums. Today, protocols for managing WTPs are either manual static configuration via HTTP, proprietary Layer 2-specific, or non-existent (if the WTPs are self-contained). The emergence of simple 802.11 WTPs that are managed by a WLAN appliance or switch (also known as an Access Controller, or AC) suggests that having a standardized, interoperable protocol could radically simplify the deployment and management of wireless networks. In many cases, the overall control and management functions themselves are generic and could apply to an AP for any wireless Layer 2 (L2) protocol. Being independent of specific wireless Layer 2 technologies, such a protocol could better support interoperability between Layer 2 devices and enable smoother intertechnology handovers. The details of how these functions would be implemented are dependent on the particular Layer 2 wireless technology. Such a protocol would need provisions for binding to specific technologies. LWAPP assumes a network configuration that consists of multiple WTPs communicating either via Layer 2 (Medium Access Control (MAC)) or Layer 3 (IP) to an AC. The WTPs can be considered as remote radio frequency (RF) interfaces, being controlled by the AC. The AC forwards all L2 frames it wants to transmit to a WTP via the LWAPP protocol. Packets from mobile nodes are forwarded by the WTP to the AC, also via this protocol. Figure 1 illustrates this arrangement as applied to an IEEE 802.11 binding. +-+ 802.11 frames +-+ | |--------------------------------| | | | +-+ | | | |--------------| |---------------| | | | 802.11 PHY/ | | LWAPP | | | | MAC sublayer | | | | +-+ +-+ +-+ STA WTP AC Figure 1: LWAPP Architecture
Security is another aspect of Wireless Termination Point management
that is not well served by existing solutions. Provisioning WTPs
with security credentials, and managing which WTPs are authorized to
provide service are today handled by proprietary solutions. Allowing
these functions to be performed from a centralized AC in an
interoperable fashion increases manageability and allows network
operators to more tightly control their wireless network
infrastructure.
This document describes the Lightweight Access Point Protocol
(LWAPP), allowing an AC to manage a collection of WTPs. The protocol
is defined to be independent of Layer 2 technology, but an 802.11
binding is provided for use in growing 802.11 wireless LAN networks.
Goals:
The following are goals for this protocol:
1. Centralization of the bridging, forwarding, authentication, and
policy enforcement functions for a wireless network. Optionally,
the AC may also provide centralized encryption of user traffic.
This will permit reduced cost and higher efficiency when applying
the capabilities of network processing silicon to the wireless
network, as it has already been applied to wired LANs.
2. Permit shifting of the higher-level protocol processing burden
away from the WTP. This leaves the computing resource of the WTP
to the timing-critical applications of wireless control and
access. This makes the most efficient use of the computing power
available in WTPs that are the subject of severe cost pressure.
3. Providing a generic encapsulation and transport mechanism, the
protocol may be applied to other access point types in the future
by adding the binding.
The LWAPP protocol concerns itself solely with the interface between
the WTP and the AC. Inter-AC, or mobile-to-AC communication is
strictly outside the scope of this document.
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].
2. Protocol Overview
LWAPP is a generic protocol defining how Wireless Termination Points communicate with Access Controllers. Wireless Termination Points and Access Controllers may communicate either by means of Layer 2 protocols or by means of a routed IP network. LWAPP messages and procedures defined in this document apply to both types of transports unless specified otherwise. Transport independence is achieved by defining formats for both MAC-level and IP-level transport (see Section 3). Also defined are framing, fragmentation/reassembly, and multiplexing services to LWAPP for each transport type. The LWAPP Transport layer carries two types of payload. LWAPP data messages are forwarded wireless frames. LWAPP control messages are management messages exchanged between a WTP and an AC. The LWAPP transport header defines the "C-bit", which is used to distinguish data and control traffic. When used over IP, the LWAPP data and control traffic are also sent over separate UDP ports. Since both data and control frames can exceed Path Maximum Transmission Unit (PMTU), the payload of an LWAPP data or control message can be fragmented. The fragmentation behavior is highly dependent upon the lower-layer transport and is defined in Section 3. The Lightweight Access Protocol (LWAPP) begins with a discovery phase. The WTPs send a Discovery Request frame, causing any Access Controller (AC), receiving that frame to respond with a Discovery Response. From the Discovery Responses received, a WTP will select an AC with which to associate, using the Join Request and Join Response. The Join Request also provides an MTU discovery mechanism, to determine whether there is support for the transport of large frames between the WTP and its AC. If support for large frames is not present, the LWAPP frames will be fragmented to the maximum length discovered to be supported by the network. Once the WTP and the AC have joined, a configuration exchange is accomplished that will cause both devices to agree on version information. During this exchange, the WTP may receive provisioning settings. For the 802.11 binding, this information would typically include a name (802.11 Service Set Identifier, SSID), and security parameters, the data rates to be advertised, as well as the radio channel (channels, if the WTP is capable of operating more than one 802.11 MAC and Physical Layer (PHY) simultaneously) to be used. Finally, the WTPs are enabled for operation.
When the WTP and AC have completed the version and provision exchange and the WTP is enabled, the LWAPP encapsulates the wireless frames sent between them. LWAPP will fragment its packets, if the size of the encapsulated wireless user data (Data) or protocol control (Management) frames cause the resultant LWAPP packet to exceed the MTU supported between the WTP and AC. Fragmented LWAPP packets are reassembled to reconstitute the original encapsulated payload. In addition to the functions thus far described, LWAPP also provides for the delivery of commands from the AC to the WTP for the management of devices that are communicating with the WTP. This may include the creation of local data structures in the WTP for the managed devices and the collection of statistical information about the communication between the WTP and the 802.11 devices. LWAPP provides the ability for the AC to obtain any statistical information collected by the WTP. LWAPP also provides for a keepalive feature that preserves the communication channel between the WTP and AC. If the AC fails to appear alive, the WTP will try to discover a new AC to communicate through. This document uses terminology defined in [5].2.1. Wireless Binding Definition
This draft standard specifies a protocol independent of a specific wireless access point radio technology. Elements of the protocol are designed to accommodate specific needs of each wireless technology in a standard way. Implementation of this standard for a particular wireless technology must follow the binding requirements defined for that technology. This specification includes a binding for the IEEE 802.11 (see Section 11). When defining a binding for other technologies, the authors MUST include any necessary definitions for technology-specific messages and all technology-specific message elements for those messages. At a minimum, a binding MUST provide the definition for a binding- specific Statistics message element, which is carried in the WTP Event Request message, and Add Mobile message element, which is carried in the Mobile Configure Request. If any technology-specific message elements are required for any of the existing LWAPP messages defined in this specification, they MUST also be defined in the technology-binding document. The naming of binding-specific message elements MUST begin with the name of the technology type, e.g., the binding for IEEE 802.11, provided in this standard, begins with "IEEE 802.11".
2.2. LWAPP State Machine Definition
The following state diagram represents the life cycle of a WTP-AC session: /-------------\ | v | +------------+ | C| Idle |<-----------------------------------\ | +------------+<-----------------------\ | | ^ |a ^ | | | | | \----\ | | | | | | +------------+ | | | | | -------| Key Confirm| | | | | | w/ +------------+ | | | | | | ^ | | | | |t V |5 | | | | +-----------+ +------------+ | | / | C| Run | | Key Update | | | / | r+-----------+------>+------------+ | | / | ^ |s u x| | | | v | | | | | | +--------------+ | | v |y | | C| Discovery | q| \--------------->+-------+ | | b+--------------+ +-------------+ | Reset | | | |d f| ^ | Configure |------->+-------+ | | | | | +-------------+p ^ | |e v | | ^ | | +---------+ v |i 2| | | C| Sulking | +------------+ +--------------+ | | +---------+ C| Join |--->| Join-Confirm | | | g+------------+z +--------------+ | | |h m| 3| |4 | | | | | v |o |\ | | | +------------+ \\-----------------/ \--------+---->| Image Data |C \------------------------------------/ +------------+n Figure 2: LWAPP State Machine The LWAPP state machine, depicted above, is used by both the AC and the WTP. For every state defined, only certain messages are permitted to be sent and received. In all of the LWAPP control messages defined in this document, the state for which each command is valid is specified.
Note that in the state diagram figure above, the 'C' character is used to represent a condition that causes the state to remain the same. The following text discusses the various state transitions, and the events that cause them. Idle to Discovery (a): This is the initialization state. WTP: The WTP enters the Discovery state prior to transmitting the first Discovery Request (see Section 5.1). Upon entering this state, the WTP sets the DiscoveryInterval timer (see Section 12). The WTP resets the DiscoveryCount counter to zero (0) (see Section 13). The WTP also clears all information from ACs (e.g., AC Addresses) it may have received during a previous discovery phase. AC: The AC does not need to maintain state information for the WTP upon reception of the Discovery Request, but it MUST respond with a Discovery Response (see Section 5.2). Discovery to Discovery (b): This is the state the WTP uses to determine to which AC it wishes to connect. WTP: This event occurs when the DiscoveryInterval timer expires. The WTP transmits a Discovery Request to every AC to which the WTP hasn't received a response. For every transition to this event, the WTP increments the DisoveryCount counter. See Section 5.1 for more information on how the WTP knows to which ACs it should transmit the Discovery Requests. The WTP restarts the DiscoveryInterval timer. AC: This is a noop. Discovery to Sulking (d): This state occurs on a WTP when Discovery or connectivity to the AC fails. WTP: The WTP enters this state when the DiscoveryInterval timer expires and the DiscoveryCount variable is equal to the MaxDiscoveries variable (see Section 13). Upon entering this state, the WTP will start the SilentInterval timer. While in the Sulking state, all LWAPP messages received are ignored. AC: This is a noop. Sulking to Idle (e): This state occurs on a WTP when it must restart the discovery phase.
WTP: The WTP enters this state when the SilentInterval timer (see
Section 12) expires.
AC: This is a noop.
Discovery to Join (f): This state is used by the WTP to confirm its
commitment to an AC that it wishes to be provided service.
WTP: The WTP selects the best AC based on the information it
gathered during the discovery phase. It then transmits a
Join Request (see Section 6.1) to its preferred AC. The WTP
starts the WaitJoin timer (see Section 12).
AC: The AC enters this state for the given WTP upon reception of
a Join Request. The AC processes the request and responds
with a Join Response.
Join to Join (g): This state transition occurs during the join
phase.
WTP: The WTP enters this state when the WaitJoin timer expires,
and the underlying transport requires LWAPP MTU detection
(Section 3).
AC: This state occurs when the AC receives a retransmission of a
Join Request. The WTP processes the request and responds
with the Join Response.
Join to Idle (h): This state is used when the join process has
failed.
WTP: This state transition occurs if the WTP is configured to use
pre-shared key (PSK) security and receives a Join Response
that includes an invalid PSK-MIC (Message Integrity Check)
message element.
AC: The AC enters this state when it transmits an unsuccessful
Join Response.
Join to Discovery (i): This state is used when the join process has
failed.
WTP: The WTP enters this state when it receives an unsuccessful
Join Response. Upon entering this state, the WTP sets the
DiscoveryInterval timer (see Section 12). The WTP resets
the DiscoveryCount counter to zero (0) (see Section 13).
This state transition may also occur if the PSK-MIC (see
Section 6.2.9) message element is invalid.
AC: This state transition is invalid.
Join to Join-Confirm (z): This state is used to provide key
confirmation during the join process.
WTP: This state is entered when the WTP receives a Join Response.
In the event that certificate-based security is utilized,
this transition will occur if the Certificate message
element is present and valid in the Join Response. For pre-
shared key security, the Join Response must include a valid
and authenticated PSK-MIC message element. The WTP MUST
respond with a Join ACK, which is used to provide key
confirmation.
AC: The AC enters this state when it receives a valid Join ACK.
For certificate-based security, the Join ACK MUST include
the WNonce message element. For pre-shared key security,
the message must include a valid PSK-MIC message element.
The AC MUST respond with a Join Confirm message, which
includes the Session Key message element.
Join-Confirm to Idle (3): This state is used when the join process
has failed.
WTP: This state transition occurs when the WTP receives an
invalid Join Confirm.
AC: The AC enters this state when it receives an invalid Join
ACK.
Join-Confirm to Configure (2): This state is used by the WTP and the
AC to exchange configuration information.
WTP: The WTP enters this state when it receives a successful Join
Confirm and determines that its version number and the
version number advertised by the AC are the same. The WTP
transmits the Configure Request (see Section 7.2) message to
the AC with a snapshot of its current configuration. The
WTP also starts the ResponseTimeout timer (see Section 12).
AC: This state transition occurs when the AC receives the
Configure Request from the WTP. The AC must transmit a
Configure Response (see Section 7.3) to the WTP, and may
include specific message elements to override the WTP's
configuration.
Join-Confirm to Image Data (4): This state is used by the WTP and
the AC to download executable firmware.
WTP: The WTP enters this state when it receives a successful Join
Confirm, and determines that its version number and the
version number advertised by the AC are different. The WTP
transmits the Image Data Request (see Section 8.1) message
requesting that the AC's latest firmware be initiated.
AC: This state transition occurs when the AC receives the Image
Data Request from the WTP. The AC must transmit an Image
Data Response (see Section 8.2) to the WTP, which includes a
portion of the firmware.
Image Data to Image Data (n): This state is used by the WTP and the
AC during the firmware download phase.
WTP: The WTP enters this state when it receives an Image Data
Response that indicates that the AC has more data to send.
AC: This state transition occurs when the AC receives the Image
Data Request from the WTP while already in this state, and
it detects that the firmware download has not completed.
Image Data to Reset (o): This state is used when the firmware
download is completed.
WTP: The WTP enters this state when it receives an Image Data
Response that indicates that the AC has no more data to
send, or if the underlying LWAPP transport indicates a link
failure. At this point, the WTP reboots itself.
AC: This state transition occurs when the AC receives the Image
Data Request from the WTP while already in this state, and
it detects that the firmware download has completed or if
the underlying LWAPP transport indicates a link failure.
Note that the AC itself does not reset, but it places the
specific WTP's context it is communicating with in the reset
state: meaning that it clears all state associated with the
WTP.
Configure to Reset (p): This state transition occurs if the
configure phase fails.
WTP: The WTP enters this state when the reliable transport fails
to deliver the Configure Request, or if the ResponseTimeout
timer (see Section 12) expires.
AC: This state transition occurs if the AC is unable to transmit
the Configure Response to a specific WTP. Note that the AC
itself does not reset, but it places the specific WTP's
context it is communicating with in the reset state: meaning
that it clears all state associated with the WTP.
Configure to Run (q): This state transition occurs when the WTP and
AC enter their normal state of operation.
WTP: The WTP enters this state when it receives a successful
Configure Response from the AC. The WTP initializes the
HeartBeat timer (see Section 12), and transmits the Change
State Event Request message (see Section 7.6).
AC: This state transition occurs when the AC receives the Change
State Event Request (see Section 7.6) from the WTP. The AC
responds with a Change State Event Response (see Section
7.7) message. The AC must start the Session ID and
NeighborDead timers (see Section 12).
Run to Run (r): This is the normal state of operation.
WTP: This is the WTP's normal state of operation, and there are
many events that cause this to occur:
Configuration Update: The WTP receives a Configuration Update
Request (see Section 7.4). The WTP MUST respond with a
Configuration Update Response (see Section 7.5).
Change State Event: The WTP receives a Change State Event
Response, or determines that it must initiate a Change State
Event Request, as a result of a failure or change in the state
of a radio.
Echo Request: The WTP receives an Echo Request message
(Section 6.5), to which it MUST respond with an Echo Response
(see Section 6.6).
Clear Config Indication: The WTP receives a Clear Config
Indication message (Section 7.8). The WTP MUST reset its
configuration back to manufacturer defaults.
WTP Event: The WTP generates a WTP Event Request to send
information to the AC (Section 8.5). The WTP receives a WTP
Event Response from the AC (Section 8.6).
Data Transfer: The WTP generates a Data Transfer Request to
the AC (Section 8.7). The WTP receives a Data Transfer
Response from the AC (Section 8.8).
WLAN Config Request: The WTP receives a WLAN Config Request
message (Section 11.8.1), to which it MUST respond with a WLAN
Config Response (see Section 11.8.2).
Mobile Config Request: The WTP receives an Mobile Config
Request message (Section 9.1), to which it MUST respond with a
Mobile Config Response (see Section 9.2).
AC: This is the AC's normal state of operation, and there are
many events that cause this to occur:
Configuration Update: The AC sends a Configuration Update
Request (see Section 7.4) to the WTP to update its
configuration. The AC receives a Configuration Update Response
(see Section 7.5) from the WTP.
Change State Event: The AC receives a Change State Event
Request (see Section 7.6), to which it MUST respond with the
Change State Event Response (see Section 7.7).
Echo: The AC sends an Echo Request message (Section 6.5) or
receives the associated Echo Response (see Section 6.6) from
the WTP.
Clear Config Indication: The AC sends a Clear Config
Indication message (Section 7.8).
WLAN Config: The AC sends a WLAN Config Request message
(Section 11.8.1) or receives the associated WLAN Config
Response (see Section 11.8.2) from the WTP.
Mobile Config: The AC sends a Mobile Config Request message
(Section 9.1) or receives the associated Mobile Config Response
(see Section 9.2) from the WTP.
Data Transfer: The AC receives a Data Transfer Request from
the AC (see Section 8.7) and MUST generate the associated Data
Transfer Response message (see Section 8.8).
WTP Event: The AC receives a WTP Event Request from the AC
(see Section 8.5) and MUST generate the associated WTP Event
Response message (see Section 8.6).
Run to Reset (s): This event occurs when the AC wishes for the WTP
to reboot.
WTP: The WTP enters this state when it receives a Reset Request
(see Section 8.3). It must respond with a Reset Response
(see Section 8.4), and once the reliable transport
acknowledgement has been received, it must reboot itself.
AC: This state transition occurs either through some
administrative action, or via some internal event on the AC
that causes it to request that the WTP disconnect. Note
that the AC itself does not reset, but it places the
specific WTPs context it is communicating with in the reset
state.
Run to Idle (t): This event occurs when an error occurs in the
communication between the WTP and the AC.
WTP: The WTP enters this state when the underlying reliable
transport is unable to transmit a message within the
RetransmitInterval timer (see Section 12), and the maximum
number of RetransmitCount counter has reached the
MaxRetransmit variable (see Section 13).
AC: The AC enters this state when the underlying reliable
transport in unable to transmit a message within the
RetransmitInterval timer (see Section 12), and the maximum
number of RetransmitCount counter has reached the
MaxRetransmit variable (see Section 13).
Run to Key Update (u): This event occurs when the WTP and the AC are
to exchange new keying material, with which it must use to protect
all future messages.
WTP: This state transition occurs when the KeyLifetime timer
expires (see Section 12).
AC: The WTP enters this state when it receives a Key Update
Request (see Section 6.7).
Key Update to Key Confirm (w): This event occurs during the rekey
phase and is used to complete the loop.
WTP: This state transition occurs when the WTP receives the Key
Update Response. The WTP MUST only accept the message if it
is authentic. The WTP responds to this response with a Key
Update ACK.
AC: The AC enters this state when it receives an authenticated
Key Update ACK message.
Key Confirm to Run (5): This event occurs when the rekey exchange
phase is completed.
WTP: This state transition occurs when the WTP receives the Key
Update Confirm. The newly derived encryption key and
Initialization Vector (IV) must be plumbed into the crypto
module after validating the message's authentication.
AC: The AC enters this state when it transmits the Key Update
Confirm message. The newly derived encryption key and IV
must be plumbed into the crypto module after transmitting a
Key Update Confirm message.
Key Update to Reset (x): This event occurs when the key exchange
phase times out.
WTP: This state transition occurs when the WTP does not receive a
Key Update Response from the AC.
AC: The AC enters this state when it is unable to process a Key
Update Request.
Reset to Idle (y): This event occurs when the state machine is
restarted.
WTP: The WTP reboots itself. After rebooting, the WTP will start
its LWAPP state machine in the Idle state.
AC: The AC clears out any state associated with the WTP. The AC
generally does this as a result of the reliable link layer
timing out.
(page 20 continued on part 2)
