Independent Submission
`Request for Comments: 5412
`Category: Historic
`ISSN: 2070-1721
`
`P. Calhoun
`R. Suri
`N. Cam-Winget
`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.
`
`Calhoun, et al.
`
`Historic
`
`[Page 1]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000001
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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.
`
`Calhoun, et al. Historic [Page 2]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000002
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
`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
`
`Calhoun, et al. Historic [Page 3]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000003
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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
`
`Calhoun, et al. Historic [Page 4]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000004
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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
`
`Calhoun, et al. Historic [Page 5]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000005
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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
`
`Calhoun, et al. Historic [Page 6]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000006
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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
`
`Calhoun, et al. Historic [Page 7]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000007
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
`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
`
`Calhoun, et al. Historic [Page 8]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000008
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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].
`
`Calhoun, et al. Historic [Page 9]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000009
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
`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.
`
`Calhoun, et al. Historic [Page 10]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000010
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
` 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".
`
`Calhoun, et al. Historic [Page 11]
`
`Exhibit 1011
`Hewlett Packard Enterprise Company v. Sovereign Peak Ventures, LLC
`Page 000011
`
`

`

`RFC 5412 Lightweight Access Point Protocol February 2010
`
`2.2. LWAPP State Machine Definition
`
` The following state diagram represents the life cycle of a WTP-AC
` session:
`
` /-------------\
` | v
` | +------------+
` | C| Idle |<-----------------------------------\
` | +------------+<-----------------------\ |
` | ^ |a ^ | |
` | | | \----\ | |
` | | | | +