Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5412

Lightweight Access Point Protocol

Pages: 125
Historic
Errata
Part 1 of 5 – Pages 1 to 20
None   None   Next

Top   ToC   RFC5412 - Page 1
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 Protocol

Abstract

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.
Top   ToC   RFC5412 - Page 2
   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.
Top   ToC   RFC5412 - Page 3

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
Top   ToC   RFC5412 - Page 4
           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
Top   ToC   RFC5412 - Page 5
           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
Top   ToC   RFC5412 - Page 6
      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
Top   ToC   RFC5412 - Page 7
           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
Top   ToC   RFC5412 - Page 8

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
Top   ToC   RFC5412 - Page 9
   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].
Top   ToC   RFC5412 - Page 10

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.
Top   ToC   RFC5412 - Page 11
   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".
Top   ToC   RFC5412 - Page 12

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.
Top   ToC   RFC5412 - Page 13
   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.
Top   ToC   RFC5412 - Page 14
      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.
Top   ToC   RFC5412 - Page 15
       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.
Top   ToC   RFC5412 - Page 16
   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.
Top   ToC   RFC5412 - Page 17
       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).
Top   ToC   RFC5412 - Page 18
         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).
Top   ToC   RFC5412 - Page 19
   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.
Top   ToC   RFC5412 - Page 20
       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)

Next Section