idnits 2.17.1 draft-ohara-capwap-lwapp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 25. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4193. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4200. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4206. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of lines with control characters in the document. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 3167 has weird spacing: '...gmented frame...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Feb 2005) is 7010 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '2' is defined on line 4090, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 4127, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. '3') ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Unknown state RFC: RFC 815 (ref. '8') -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '11') (Obsoleted by RFC 4301) Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun 3 Internet-Draft B. O'Hara 4 Expires: August 5, 2005 Airespace 5 S. Kelly 6 Facetime Communications 7 R. Suri 8 Airespace 9 M. Williams 10 Nokia, Inc. 11 S. Hares 12 Nexthop Technologies, Inc. 13 Feb 2005 15 Light Weight Access Point Protocol (LWAPP) 16 draft-ohara-capwap-lwapp-01.txt 18 Status of this Memo 20 This document is an Internet-Draft and is subject to all provisions 21 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 22 author represents that any applicable patent or other IPR claims of 23 which he or she is aware have been or will be disclosed, and any of 24 which he or she become aware will be disclosed, in accordance with 25 RFC 3668. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as 30 Internet-Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on August 5, 2005. 45 Copyright Notice 47 Copyright (C) The Internet Society (2005). 49 Abstract 51 In the recent years, there has been a shift in wireless LAN product 52 architectures from autonomous access points to centralized control of 53 light weight access points. The general goal has been to move most 54 of the traditional wireless functionality such as access control 55 (user authentication and authorization), mobility and radio 56 management out of the access point into a centralized controller. 58 The IETF's CAPWAP WG has identified that a standards based protocol 59 is necessary between a wireless Access Controller and Wireless 60 Termination Points (the latter are also commonly referred to as Light 61 Weight Access Points). This specification defines the Light Weight 62 Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol 63 requirements. Although the LWAPP protocol is designed to be flexible 64 enough to be used for a variety of wireless technologies, this 65 specific document describes the base protocol, and an extension that 66 allows it to be used with the IEEE's 802.11 wireless LAN protocol. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 71 1.1 Conventions used in this document . . . . . . . . . . . 8 72 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 73 2.1 Wireless Binding Definition . . . . . . . . . . . . . . 11 74 2.2 LWAPP State Machine Definition . . . . . . . . . . . . . 11 75 3. LWAPP Transport Layers . . . . . . . . . . . . . . . . . . . 18 76 3.1 LWAPP Transport Header . . . . . . . . . . . . . . . . . 18 77 3.1.1 VER Field . . . . . . . . . . . . . . . . . . . . . 18 78 3.1.2 RID Field . . . . . . . . . . . . . . . . . . . . . 18 79 3.1.3 C Bit . . . . . . . . . . . . . . . . . . . . . . . 18 80 3.1.4 F Bit . . . . . . . . . . . . . . . . . . . . . . . 18 81 3.1.5 L Bit . . . . . . . . . . . . . . . . . . . . . . . 19 82 3.1.6 Fragment ID . . . . . . . . . . . . . . . . . . . . 19 83 3.1.7 Length . . . . . . . . . . . . . . . . . . . . . . . 19 84 3.1.8 Status and WLANS . . . . . . . . . . . . . . . . . . 19 85 3.1.9 Payload . . . . . . . . . . . . . . . . . . . . . . 19 86 3.2 Using IEEE 802.3 MAC as LWAPP transport . . . . . . . . 19 87 3.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . 19 88 3.2.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 20 89 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC 90 transport . . . . . . . . . . . . . . . . . . . . . 20 91 3.2.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 20 92 3.2.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 20 93 3.3 Using IPv4/UDP as LWAPP transport . . . . . . . . . . . 20 94 3.3.1 Framing . . . . . . . . . . . . . . . . . . . . . . 20 95 3.3.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 21 96 3.3.3 LWAPP Message Header format over IPv4/UDP transport 21 97 3.3.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 22 98 3.3.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 22 99 4. LWAPP Packet Definitions . . . . . . . . . . . . . . . . . . 23 100 4.1 LWAPP Data Messages . . . . . . . . . . . . . . . . . . 23 101 4.2 LWAPP Control Messages Overview . . . . . . . . . . . . 23 102 4.2.1 Control Message Format . . . . . . . . . . . . . . . 24 103 4.2.2 Message Element Format . . . . . . . . . . . . . . . 26 104 5. LWAPP Discovery Operations . . . . . . . . . . . . . . . . . 28 105 5.1 Discovery Request . . . . . . . . . . . . . . . . . . . 28 106 5.1.1 Discovery Type . . . . . . . . . . . . . . . . . . . 29 107 5.1.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 29 108 5.1.3 WTP Radio Information . . . . . . . . . . . . . . . 30 109 5.2 Discovery Response . . . . . . . . . . . . . . . . . . . 30 110 5.2.1 AC Descriptor . . . . . . . . . . . . . . . . . . . 31 111 5.2.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 31 112 5.2.3 WTP Manager Control IP Address . . . . . . . . . . . 32 113 5.3 Primary Discovery Request . . . . . . . . . . . . . . . 32 114 5.3.1 Discovery Type . . . . . . . . . . . . . . . . . . . 33 115 5.3.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 33 116 5.3.3 WTP Radio Information . . . . . . . . . . . . . . . 33 117 5.4 Primary Discovery Response . . . . . . . . . . . . . . . 33 118 5.4.1 AC Descriptor . . . . . . . . . . . . . . . . . . . 33 119 5.4.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 33 120 5.4.3 WTP Manager Control IP Address . . . . . . . . . . . 33 121 6. Control Channel Management . . . . . . . . . . . . . . . . . 35 122 6.1 Join Request . . . . . . . . . . . . . . . . . . . . . . 35 123 6.1.1 AC Address . . . . . . . . . . . . . . . . . . . . . 35 124 6.1.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 36 125 6.1.3 WTP Name . . . . . . . . . . . . . . . . . . . . . . 36 126 6.1.4 Location Data . . . . . . . . . . . . . . . . . . . 36 127 6.1.5 WTP Radio Information . . . . . . . . . . . . . . . 37 128 6.1.6 Certificate . . . . . . . . . . . . . . . . . . . . 37 129 6.1.7 Session ID . . . . . . . . . . . . . . . . . . . . . 37 130 6.1.8 Test . . . . . . . . . . . . . . . . . . . . . . . . 37 131 6.2 Join Response . . . . . . . . . . . . . . . . . . . . . 38 132 6.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 38 133 6.2.2 Status . . . . . . . . . . . . . . . . . . . . . . . 39 134 6.2.3 Certificate . . . . . . . . . . . . . . . . . . . . 39 135 6.2.4 Session Key . . . . . . . . . . . . . . . . . . . . 39 136 6.2.5 WTP Manager Data IP Address . . . . . . . . . . . . 40 137 6.3 Echo Request . . . . . . . . . . . . . . . . . . . . . . 40 138 6.4 Echo Response . . . . . . . . . . . . . . . . . . . . . 40 139 6.5 Key Update Request . . . . . . . . . . . . . . . . . . . 41 140 6.5.1 Session ID . . . . . . . . . . . . . . . . . . . . . 41 141 6.6 Key Update Response . . . . . . . . . . . . . . . . . . 41 142 6.6.1 Session Key . . . . . . . . . . . . . . . . . . . . 42 143 6.7 Key Update Trigger . . . . . . . . . . . . . . . . . . . 42 144 6.7.1 Session ID . . . . . . . . . . . . . . . . . . . . . 42 145 7. WTP Configuration Management . . . . . . . . . . . . . . . . 43 146 7.1 Configure Request . . . . . . . . . . . . . . . . . . . 43 147 7.1.1 Administrative State . . . . . . . . . . . . . . . . 43 148 7.1.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 44 149 7.1.3 AC Name with Index . . . . . . . . . . . . . . . . . 44 150 7.1.4 WTP Board Data . . . . . . . . . . . . . . . . . . . 44 151 7.1.5 Statistics Timer . . . . . . . . . . . . . . . . . . 45 152 7.1.6 WTP Static IP Address Information . . . . . . . . . 45 153 7.1.7 WTP Reboot Statistics . . . . . . . . . . . . . . . 46 154 7.2 Configure Response . . . . . . . . . . . . . . . . . . . 46 155 7.2.1 Decryption Error Report Period . . . . . . . . . . . 47 156 7.2.2 Change State Event . . . . . . . . . . . . . . . . . 47 157 7.2.3 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 48 158 7.2.4 AC List . . . . . . . . . . . . . . . . . . . . . . 48 159 7.2.5 WTP Fallback . . . . . . . . . . . . . . . . . . . . 48 160 7.2.6 Idle Timeout . . . . . . . . . . . . . . . . . . . . 49 161 7.3 Configuration Update Request . . . . . . . . . . . . . . 49 162 7.3.1 WTP Name . . . . . . . . . . . . . . . . . . . . . . 49 163 7.3.2 Change State Event . . . . . . . . . . . . . . . . . 50 164 7.3.3 Administrative State . . . . . . . . . . . . . . . . 50 165 7.3.4 Statistics Timer . . . . . . . . . . . . . . . . . . 50 166 7.3.5 Location Data . . . . . . . . . . . . . . . . . . . 50 167 7.3.6 Decryption Error Report Period . . . . . . . . . . . 50 168 7.3.7 AC List . . . . . . . . . . . . . . . . . . . . . . 50 169 7.3.8 Add Blacklist Entry . . . . . . . . . . . . . . . . 50 170 7.3.9 Delete Blacklist Entry . . . . . . . . . . . . . . . 51 171 7.3.10 Add Static Blacklist Entry . . . . . . . . . . . . . 51 172 7.3.11 Delete Static Blacklist Entry . . . . . . . . . . . 52 173 7.3.12 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 52 174 7.3.13 AC Name with Index . . . . . . . . . . . . . . . . . 52 175 7.3.14 WTP Fallback . . . . . . . . . . . . . . . . . . . . 52 176 7.3.15 Idle Timeout . . . . . . . . . . . . . . . . . . . . 52 177 7.4 Configuration Update Response . . . . . . . . . . . . . 52 178 7.4.1 Result Code . . . . . . . . . . . . . . . . . . . . 53 179 7.5 Change State Event Request . . . . . . . . . . . . . . . 53 180 7.5.1 Change State Event . . . . . . . . . . . . . . . . . 53 181 7.6 Change State Event Response . . . . . . . . . . . . . . 53 182 7.7 Clear Config Indication . . . . . . . . . . . . . . . . 54 183 8. Device Management Operations . . . . . . . . . . . . . . . . 55 184 8.1 Image Data Request . . . . . . . . . . . . . . . . . . . 55 185 8.1.1 Image Download . . . . . . . . . . . . . . . . . . . 55 186 8.1.2 Image Data . . . . . . . . . . . . . . . . . . . . . 55 187 8.2 Image Data Response . . . . . . . . . . . . . . . . . . 56 188 8.3 Reset Request . . . . . . . . . . . . . . . . . . . . . 56 189 8.4 Reset Response . . . . . . . . . . . . . . . . . . . . . 56 190 8.5 WTP Event Request . . . . . . . . . . . . . . . . . . . 56 191 8.5.1 Decryption Error Report . . . . . . . . . . . . . . 57 192 8.5.2 Duplicate IP Address . . . . . . . . . . . . . . . . 57 193 8.6 WTP Event Response . . . . . . . . . . . . . . . . . . . 58 194 8.7 Data Transfer Request . . . . . . . . . . . . . . . . . 58 195 8.7.1 Data Transfer Mode . . . . . . . . . . . . . . . . . 58 196 8.7.2 Data Transfer Data . . . . . . . . . . . . . . . . . 59 197 8.8 Data Transfer Response . . . . . . . . . . . . . . . . . 59 198 9. Mobile Session Management . . . . . . . . . . . . . . . . . 60 199 9.1 Mobile Config Request . . . . . . . . . . . . . . . . . 60 200 9.1.1 Delete Mobile . . . . . . . . . . . . . . . . . . . 60 201 9.2 Mobile Config Response . . . . . . . . . . . . . . . . . 61 202 9.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 61 203 10. Session Key Generation . . . . . . . . . . . . . . . . . . 62 204 10.1 Securing WTP-AC communications . . . . . . . . . . . . . 62 205 10.2 LWAPP Frame Encryption . . . . . . . . . . . . . . . . . 63 206 10.3 Authenticated Key Exchange . . . . . . . . . . . . . . . 63 207 10.4 Refreshing Cryptographic Keys . . . . . . . . . . . . . 65 208 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . 67 209 11.1 Transport specific bindings . . . . . . . . . . . . . . 67 210 11.1.1 Status and WLANS field . . . . . . . . . . . . . . . 67 211 11.2 Data Message bindings . . . . . . . . . . . . . . . . . 68 212 11.3 Control Message bindings . . . . . . . . . . . . . . . . 68 213 11.3.1 Mobile Config Request . . . . . . . . . . . . . . . 68 214 11.3.2 WTP Event Request . . . . . . . . . . . . . . . . . 72 215 11.4 802.11 Control Messages . . . . . . . . . . . . . . . . 74 216 11.4.1 IEEE 802.11 WLAN Config Request . . . . . . . . . . 74 217 11.4.2 IEEE 802.11 WLAN Config Response . . . . . . . . . . 78 218 11.4.3 IEEE 802.11 WTP Event . . . . . . . . . . . . . . . 78 219 11.5 Message Element Bindings . . . . . . . . . . . . . . . . 79 220 11.5.1 IEEE 802.11 WTP WLAN Radio Configuration . . . . . . 80 221 11.5.2 IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 81 222 11.5.3 IEEE 802.11 Multi-domain Capability . . . . . . . . 82 223 11.5.4 IEEE 802.11 MAC Operation . . . . . . . . . . . . . 82 224 11.5.5 IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 84 225 11.5.6 IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 84 226 11.5.7 IEEE 802.11 Direct Sequence Control . . . . . . . . 84 227 11.5.8 IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 85 228 11.5.9 IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 86 229 11.5.10 IEEE 802.11 Supported Rates . . . . . . . . . . . 86 230 11.5.11 IEEE 802.11 CFP Status . . . . . . . . . . . . . . 87 231 11.5.12 IEEE 802.11 WTP Mode and Type . . . . . . . . . . 87 232 11.5.13 IEEE 802.11 Broadcast Probe Mode . . . . . . . . . 88 233 11.5.14 IEEE 802.11 WTP Quality of Service . . . . . . . . 88 234 11.5.15 IEEE 802.11 MIC Error Report From Mobile . . . . . 89 235 11.6 IEEE 802.11 Message Element Values . . . . . . . . . . . 90 236 12. LWAPP Protocol Timers . . . . . . . . . . . . . . . . . . 91 237 12.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 91 238 12.2 SilentInterval . . . . . . . . . . . . . . . . . . . . . 91 239 12.3 NeighborDeadInterval . . . . . . . . . . . . . . . . . . 91 240 12.4 EchoInterval . . . . . . . . . . . . . . . . . . . . . . 91 241 12.5 DiscoveryInterval . . . . . . . . . . . . . . . . . . . 91 242 12.6 RetransmitInterval . . . . . . . . . . . . . . . . . . . 91 243 12.7 ResponseTimeout . . . . . . . . . . . . . . . . . . . . 92 244 12.8 KeyLifetime . . . . . . . . . . . . . . . . . . . . . . 92 245 13. LWAPP Protocol Variables . . . . . . . . . . . . . . . . . 93 246 13.1 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 93 247 13.2 DiscoveryCount . . . . . . . . . . . . . . . . . . . . . 93 248 13.3 RetransmitCount . . . . . . . . . . . . . . . . . . . . 93 249 13.4 MaxRetransmit . . . . . . . . . . . . . . . . . . . . . 93 250 14. Security Considerations . . . . . . . . . . . . . . . . . 94 251 15. IANA Considerations . . . . . . . . . . . . . . . . . . . 95 252 16. IPR Statement . . . . . . . . . . . . . . . . . . . . . . 96 253 17. References . . . . . . . . . . . . . . . . . . . . . . . . 97 254 17.1 Normative References . . . . . . . . . . . . . . . . . . 97 255 17.2 Informational References . . . . . . . . . . . . . . . . 97 256 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 98 257 Intellectual Property and Copyright Statements . . . . . . . 100 259 1. Introduction 261 Unlike wired network elements, Wireless Termination Points (WTPs) 262 require a set of management and control functions related to their 263 primary task of connecting the wireless and wired mediums. Today, 264 protocols for managing WTPs are either Layer 2 specific or 265 non-existent (if the WTPs are self-contained). The emergence of 266 simple 802.11 WTPs that are managed by a WLAN appliance or switch 267 (also known as an Access Controller, or AC) suggests that having a 268 standardized, interoperable protocol could radically simplify the 269 deployment and management of wireless networks. In many cases the 270 overall control and management functions themselves are generic and 271 could apply to any wireless Layer 2 protocol. Being independent of 272 specific wireless Layer 2 technologies, such a protocol could better 273 support interoperability between Layer 2 devices and enable smoother 274 intertechnology handovers. 276 The details of how these functions would be implemented are dependent 277 on the particular Layer 2 wireless technology. Such a protocol would 278 need provisions for binding to specific technologies. 280 LWAPP assumes a network configuration that consists of multiple WTPs 281 communicating either via layer 2 (MAC) or layer 3 (IP) to an AC. The 282 WTP can be considered as remote RF interfaces, being controlled by 283 the AC. The AC forwards all L2 frames it wants to transmit to an WTP 284 via the LWAPP protocol. Packets from mobile nodes are forwarded by 285 the WTP to the AC, also via this protocol. Figure 1 illustrates this 286 arrangement as applied to an IEEE 802.11 binding. 288 +-+ 802.11frames +-+ 289 | |--------------------------------| | 290 | | +-+ | | 291 | |--------------| |---------------| | 292 | | 802.11 PHY/ | | LWAPP | | 293 | | MAC sublayer | | | | 294 +-+ +-+ +-+ 295 STA WTP AC 297 Figure 1: LWAPP Architecture 299 Security is another aspect of Wireless Termination Point management 300 that is not well served by existing solutions. Provisioning WTPs 301 with security credentials, and managing which WTPs are authorized to 302 provide service are today handled by proprietary solutions. Allowing 303 these functions to be performed from a centralized AC in an 304 interoperable fashion increases managability and allows network 305 operators to more tightly control their wireless network 306 infrastructure. 308 This document describes the Light Weight Access Point Protocol 309 (LWAPP), allowing an AC to manage a collection of WTPs. The protocol 310 is defined to be independent of Layer 2 technology, but an 802.11 311 binding is provided for use in growing 802.11 wireless LAN networks. 313 Goals 315 The following are goals for this protocol: 316 1. Centralization of the bridging, forwarding, authentication and 317 policy enforcement functions for a wireless network. Optionally, 318 the AC may also provide centralized encryption of user traffic. 319 This will permit reduced cost and higher efficiency when applying 320 the capabilities of network processing silicon to the wireless 321 network, as it has already been applied to wired LANs. 322 2. Permit shifting of the higher level protocol processing burden 323 away from the WTP. This leaves the computing resource of the WTP 324 to the timing critical applications of wireless control and 325 access. This makes the most efficient use of the computing power 326 available in WTPs that are the subject of severe cost pressure. 327 3. Providing a generic encapsulation and transport mechanism, the 328 protocol may be applied to other access point protocols in the 329 future by adding the binding. 331 The LWAPP protocol concerns itself solely on the interface between 332 the WTP and the AC. Inter-AC, or mobile to AC communication is 333 strictly outside the scope of this document. 335 1.1 Conventions used in this document 337 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 338 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 339 document are to be interpreted as described in RFC 2119 [1]. 341 2. Protocol Overview 343 LWAPP is a generic protocol defining how Wireless Termination Points 344 communicate with Access Controllers. Wireless Termination Points and 345 Access Controllers may communicate either by means of Layer 2 346 protocols or by means of a routed IP network. 348 LWAPP messages and procedures defined in this document apply to both 349 types of transports unless specified otherwise. Transport 350 independence is achieved by defining formats for both MAC level and 351 IP level transport (see Section 3). Also defined are framing, 352 fragmentation/reassembly, and multiplexing services to LWAPP for each 353 transport type. 355 The LWAPP Transport layer carries two types of payload. LWAPP Data 356 Messages are forwarded wireless frames. LWAPP Control Messages are 357 management messages exchanged between an WTP and is AC. The LWAPP 358 transport header defines the "C-bit", which is used to distinguish 359 data and control traffic. When used over IP, the LWAPP data and 360 control traffic are also sent over separate UDP ports. Since both 361 data and control frames can exceed PMTU, the payload of an LWAPP data 362 or control message can be fragmented. The fragmentation behavior is 363 highly dependent upon the lower layer transport and is defined in 364 Section 3. 366 Layer 2 LWAPP Data Frame 367 +-----------------------------------------------------------+ 368 | MAC Header | LWAPP Header [C=0] | Forwarded Data ... | 369 +-----------------------------------------------------------+ 371 Layer 3 LWAPP Data Frame 372 +--------------------------------------------+ 373 | MAC Header | IP | UDP | LWAPP Header [C=0] | 374 +--------------------------------------------+ 375 |Forwarded Data ... | 376 +-------------------+ 378 Layer 2 LWAPP Control Frame 379 +---------------------------------------------------+ 380 | MAC Header | LWAPP Header [C=1] | Control Message | 381 +---------------------------------------------------+ 382 | Message Elements ... | 383 +----------------------+ 385 Layer 3 LWAPP Control Frame 386 +--------------------------------------------+ 387 | MAC Header | IP | UDP | LWAPP Header [C=1] | 388 +--------------------------------------------+ 389 | Control Message | Message Elements ... | 390 +-----------------+----------------------+ 392 The Light Weight Access Protocol (LWAPP) begins with a discovery 393 phase. The WTPs send a Discovery Request frame, causing any Access 394 Controller (AC) , receiving that frame to respond with a Discovery 395 Response. From the Discovery Responses received, an WTP will select 396 an AC with which to associate, using the Join Request and Join 397 Response. The Join Request also provides an MTU discovery mechanism, 398 to determine whether there is support for the transport of large 399 frames between the WTP and it's AC. If support for large frames is 400 not present, the LWAPP frames will be fragmented to the maximum 401 length discovered to be supported by the network. 403 Once the WTP and the AC have joined, a configuration exchange is 404 accomplished that will cause both devices to agree on version 405 information. During this exchange the WTP may receive provisioning 406 settings. For the 802.11 binding, this information would typically 407 include a name (802.11 Service Set Identifier, SSID), and security 408 parameters, the data rates to be advertised as well as the radio 409 channel (channels, if the WTP is capable of operating more than one 410 802.11 MAC and PHY simultaneously) to be used. Finally, the WTPs are 411 enabled for operation. 413 When the WTP and AC have completed the version and provision exchange 414 and the WTP is enabled, the LWAPP encapsulates the wireless frames 415 sent between them. LWAPP will fragment its packets, if the size of 416 the encapsulated wireless user data (Data) or protocol control 417 (Management) frames causes the resultant LWAPP packet to exceed the 418 MTU supported between the WTP and AC. Fragmented LWAPP packets are 419 reassembled to reconstitute the original encapsulated payload. 421 In addition to the functions thus far described, LWAPP also provides 422 for the delivery of commands from the AC to the WTP for the 423 management of devices that are communicating with the WTP. This may 424 include the creation of local data structures in the WTP for the 425 managed devices and the collection of statistical information about 426 the communication between the WTP and the 802.11 devices. LWAPP 427 provides the ability for the AC to obtain any statistical information 428 collected by the WTP. 430 LWAPP also provides for a keep alive feature that preserves the 431 communication channel between the WTP and AC. If the AC fails to 432 appear alive, the WTP will try to discover a new AC to communicate 433 through. 435 This Document uses terminology defined in [5] 437 2.1 Wireless Binding Definition 439 This draft standard specifies a protocol independent of a specific 440 wireless access point radio technology. Elements of the protocol are 441 designed to accommodate specific needs of each wireless technology in 442 a standard way. Implementation of this standard for a particular 443 wireless technology must follow the binding requirements defined for 444 that technology. This specification includes a binding for the IEEE 445 802.11 (see Section 11). 447 When defining a bindings for other technologies, the authors MUST 448 include any necessary definitions for technology-specific messages 449 and all technology-specific message elements for those messages. At 450 a minimum, a binding MUST provide definition of binding-specific 451 Statistics message element, which is carried in the WTP Event Request 452 message, and Add Mobile message element, which is carried in the 453 Mobile Configure Request. If any technology specific message 454 elements are required for any of the existing LWAPP messages defined 455 in this specification, they MUST also be defined in the technology 456 binding document. 458 The naming of binding-specific message elements MUST begin with the 459 name of the technology type, e.g., the binding for IEEE 802.11, 460 provided in this standard, begins with "IEEE 802.11"." 462 2.2 LWAPP State Machine Definition 464 The following state diagram represents the lifecycle of an WTP-AC 465 session: 467 /-------------\ 468 | v 469 | +------+ 470 | C| Idle |<-------------------------------------\ 471 | +------+<--------------------------\ | 472 | ^ | ^ | | 473 | | | \---------------\ | | 474 | | | | | | 475 | / | +---------+-->+------------+ | 476 | / | C| Run | | Key Update | | 477 | / | +---------+<--+------------+ | 478 | / v | ^ | | | 479 | | +-----------+ | | | v | 480 | | C| Discovery |<--------/ | \------------>+-------+ 481 | | +-----------+ +-----------+ | Reset | 482 | | | \ ^ /-->| Configure |------->+-------+ 483 | | v \ \ / +-----------+ ^ 484 | +---------+ v \ / | 485 | C| Sulking | +------+ | 486 | +---------+ C| Join |----------------------\ | 487 | +------+ v | 488 \ | +------------+ 489 \-----------------/ C| Image Data | 490 +------------+ 492 Figure 3: LWAPP State Machine 494 The LWAPP state machine, depicted above, is used by both the AC and 495 the WTP. For every state defined, only certain messages are 496 permitted to be sent and received. In all of the LWAPP control 497 messages defined in this specification, the specific state for which 498 they are valid is specified. 500 Note that in the state diagram figure above, the 'C' character is 501 used to represent a condition that causes the state to remain the 502 same. 504 The following text discusses the various state transitions, and the 505 events that cause them. 506 Idle to Discovery: This is the initialization state. 507 WTP: The WTP enters the Discovery state prior to transmitting the 508 first Discovery Request (see Section 5.1). Upon entering this 509 state, the WTP sets the DiscoveryInterval timer (see 510 Section 12). The WTP resets the DiscoveryCount counter to zero 511 (0) (see Section 13). The WTP also clears all information from 512 ACs (e.g., AC Addresses) it may have received during a previous 513 Discovery phase. 515 AC: The AC does not need to maintain state information for the WTP 516 upon reception of the Discovery Request, but it MUST respond 517 with a Discovery Response (see Section 5.2). 518 Discovery to Discovery: This is the state the WTP uses to determine 519 which AC it wishes to connect to. 520 WTP: This event occurs when the DiscoveryInterval timer expires. 521 The WTP transmits a Discovery Request to every AC which the WTP 522 hasn't received a response to. For every transition to this 523 event, the WTP increments DisoveryCount counter. See 524 Section 5.1) for more information on how the WTP knows which 525 ACs it should transmit the Discovery Requests to. The WTP 526 restarts the DiscoveryInterval timer. 527 AC: This is a noop. 528 Discovery to Sulking: This state occurs on a WTP when Discovery or 529 connectivity to the AC fails. 530 WTP: The WTP enters this state when the DiscoveryInterval timer 531 expires and the DiscoveryCount variable is equal to the 532 MaxDiscoveries variable (see Section 13). Upon entering this 533 state, the WTP will start the SilentInterval timer. While in 534 the Sulking state, all LWAPP messages received are ignored. 535 AC: This is a noop. 536 Sulking to Idle: This state occurs on a WTP when it must restart the 537 discovery phase. 538 WTP: The WTP enters this state when the SilentInterval timer (see 539 Section 12) expires. 540 AC: This is a noop. 541 Discovery to Join: This state is used by the WTP to confirm its 542 commitment to an AC that it wishes to be provided service. 543 WTP: The WTP selects the best AC based on the information it 544 gathered during the Discovery Phase. It then transmits a Join 545 Request (see Section 6.1 to its preferred AC. The WTP starts 546 the WaitJoin Timer (see Section 12). 547 AC: The AC enters this state for the given WTP upon reception of a 548 Join Request. The WTP processes the request and responds with 549 a Join Response. 550 Join to Join: This state transition during the join phase. 551 WTP: The WTP enters this state when the WaitJoin timer expires, 552 and the underlying transport requires LWAPP MTU detection 553 Section 3). 554 AC: This state occurs when the AC receives a retransmission of a 555 Join Request. The WTP processes the request and responds with 556 the Join Response.. 557 Join to Idle: This state is used when the join process failed. 558 WTP: This state transition is invalid. 559 AC: The AC enters this state when it transmits an unsuccessful 560 Join Response. 562 Join to Discovery: This state is used when the join process failed. 563 WTP: The WTP enters this state when it receives an unsuccessful 564 Join Response. Upon entering this state, the WTP sets the 565 DiscoveryInterval timer (see Section 12). The WTP resets the 566 DiscoveryCount counter to zero (0) (see Section 13). 567 AC: This state transition is invalid. 568 Join to Configure: This state is used by the WTP and the AC to 569 exchange configuration information. 570 WTP: The WTP enters this state when it receives a successful Join 571 Response, and determines that its version number and the 572 version number advertised by the AC are the same. The WTP 573 transmits the Configure Request (see Section 7.1) message to 574 the AC with a snapshot of its current configuration. The WTP 575 also starts the ResponseTimeout timer (see Section 12). 576 AC: This state transition transition occurs when the AC receives 577 the Configure Request from the WTP. The AC must transmit a 578 Configure Response (see Section 7.2) to the WTP, and may 579 include specific message elements to override the WTP's 580 configuration. 581 Join to Image Data: This state is used by the WTP and the AC to 582 download executable firmware. 583 WTP: The WTP enters this state when it receives a successful Join 584 Response, and determines that its version number and the 585 version number advertised by the AC are different. The WTP 586 transmits the Image Data Request (see Section 8.1) message 587 requesting that the AC's latest firmware be initiated. 588 AC: This state transition transition occurs when the AC receives 589 the Image Data Request from the WTP. The AC must transmit a 590 Image Data Response (see Section 8.2) to the WTP, which 591 includes a portion of the firmware. 592 Image Data to Image Data: This state is used by WTP and the AC during 593 the firmware download phase. 594 WTP: The WTP enters this state when it receives a Image Data 595 Response that indicates that the AC has more data to send. 596 AC: This state transition transition occurs when the AC receives 597 the Image Data Request from the WTP while already in this 598 state, and it detects that the firmware download has not 599 completed. 600 Image Data to Reset: This state is used when the firmware download is 601 completed. 602 WTP: The WTP enters this state when it receives a Image Data 603 Response that indicates that the AC has no more data to send, 604 or if the underlying LWAPP transport indicates a link failure. 605 At this point, the WTP reboots itself. 606 AC: This state transition occurs when the AC receives the Image 607 Data Request from the WTP while already in this state, and it 608 detects that the firmware download has completed, or if the 609 underlying LWAPP transport indicates a link failure. Note that 610 the AC itself does not reset, but it places the specific WTPs 611 context it is communicating with in the reset state, meaning 612 that it clears all state associated with the WTP. 613 Configure to Reset: This state transition occurs if the Configure 614 phase fails. 615 WTP: The WTP enters this state when the reliable transport fails 616 to deliver the Configure Request, or if the ResponseTimeout 617 Timer (see Section 12)expires. 618 AC: This state transition occurs if the AC is unable to transmit 619 the Configure Response. Note that the AC itself does not 620 reset, but it places the specific WTPs context it is 621 communicating with in the reset state, meaning that it clears 622 all state associated with the WTP. 623 Configure to Run: This state transition occurs when the WTP and AC 624 enters their normal state of operation. 625 WTP: The WTP enters this state when it receives a successful 626 Configure Response from the AC. The WTP initializes the 627 HeartBeat Timer (see Section 12), and transmits the Change 628 State Event Request message (see Section 7.5). 629 AC: This state transition occurs when the AC receives the Change 630 State Event Request (see Section 7.5) from the WTP. The AC 631 responds with a Change State Event Response (see Section 7.6) 632 message. The AC must start the Session ID and Neighbor Dead 633 timers (see Section 12). 634 Run to Run: This is the normal state of operation. 635 WTP: This is the WTP's normal state of operation, and there are 636 many events that cause this to occur: 637 Configuration Update: The WTP receives a Configuration Update 638 Request (see Section 7.3). The WTP MUST respond with a 639 Configuration Update Response (see Section 7.4). 640 Change State Event: The WTP receives a Change State Event 641 Response, or determines that it must initiate a Change State 642 Event Request, as a result of a failure or change in the 643 state of a radio. 644 Echo Request: The WTP receives an Echo Request message 645 Section 6.3), which it MUST respond with an Echo Response 646 (see Section 6.4). 647 Clear Config Indication: The WTP receives a Clear Config 648 Indication message Section 7.7). The WTP MUST reset its 649 configuration back to manufacturer defaults. 650 WTP Event: The WTP generates a WTP Event Request to send 651 information to the AC Section 8.5). The WTP receives a WTP 652 Event Response from the AC Section 8.6). 653 Data Transfer: The WTP generates a Data Transfer Request to the 654 AC Section 8.7). The WTP receives a Data Transfer Response 655 from the AC Section 8.8). 657 WLAN Config Request: The WTP receives an WLAN Config Request 658 message Section 11.4.1), which it MUST respond with an WLAN 659 Config Response (see Section 11.4.2). 660 Mobile Config Request: The WTP receives an Mobile Config 661 Request message Section 9.1), which it MUST respond with an 662 Mobile Config Response (see Section 9.2). 663 AC: This is the AC's normal state of operation, and there are many 664 events that cause this to occur: 665 Configuration Update: The AC sends a Configuration Update 666 Request (see Section 7.3) to the AP to update its 667 configuration. The AC receives a Configuration Update 668 Response (see Section 7.4) from the WTP. 669 Change State Event: The AC receives a Change State Event 670 Request (see Section 7.5), which it MUST respond to with the 671 Change State Event Response (see Section 7.6). 672 Echo: The AC sends an Echo Request message Section 6.3) or 673 receives the associated Echo Response (see Section 6.4) from 674 the WTP. 675 Clear Config Indication: The AC sends a Clear Config Indication 676 message Section 7.7). 677 WLAN Config: The AC sends an WLAN Config Request message 678 Section 11.4.1) or receives the associated WLAN Config 679 Response (see Section 11.4.2) from the WTP. 680 Mobile Config: The AC sends an Mobile Config Request message 681 Section 9.1) or receives the associated Mobile Config 682 Response (see Section 9.2) from the WTP. 683 Data Transfer: The AC receives a Data Transfer Request from the 684 AC (see Section 8.7) and MUST generate the associated Data 685 Transfer Response message (see Section 8.8). 686 WTP Event: The AC receives a WTP Event Request from the AC (see 687 Section 8.5) and MUST generate the associated WTP Event 688 Response message (see Section 8.6). 689 Run to Reset: This event occurs when the AC wishes for the WTP re 690 reboot. 691 WTP: The WTP enters this state when it receives a Reset Request 692 (see Section 8.3). It must respond with a Reset Response (see 693 Section 8.4), and once the reliable transport acknowledgement 694 has been received, it must reboot itself. 695 AC: This state transition occurs either through some 696 administrative action, or via some internal event on the AC 697 that causes it to request that the WTP disconnect. Note that 698 the AC itself does not reset, but it places the specific WTPs 699 context it is communicating with in the reset state. 700 Run to Idle: This event occurs when an error occurs in the 701 communication between the WTP and the AC. 703 WTP: The WTP enters this state when the underlying reliable 704 transport in unable to transmit a message within the 705 RetransmitInterval timer (see Section 12), and the maximum 706 number of RetransmitCount counter has reached the MaxRetransmit 707 variable (see Section 13). 708 AC: The AC enters this state when the underlying reliable 709 transport in unable to transmit a message within the 710 RetransmitInterval timer (see Section 12), and the maximum 711 number of RetransmitCount counter has reached the MaxRetransmit 712 variable (see Section 13). 713 Run to Key Update: This event occurs when the WTP and the AC are to 714 exchange new keying material, with which it must use to protect 715 all future messages. 716 WTP: This state transition occurs when the KeyLifetime timer 717 expires (see Section 12). 718 AC: The WTP enters this state when it receives a Key Update 719 Request (see Section 6.5). It must create new keying material 720 and include it in the Key Update Response (see Section 6.6). 721 Key Update to Run: This event occurs when the key exchange phase is 722 completed. 723 WTP: This state transition occurs when the AC receives the Key 724 Update Response. The WTP must plumb the new keys in its crypto 725 module, allowing it to communicate with the AC using the new 726 key. 727 AC: The WTP enters this state when it transmits the Key Update 728 Response message. The key is then plumbed into its crypto 729 module, allowing it to communicate with the WTP using the new 730 key. 732 3. LWAPP Transport Layers 734 The LWAPP protocol can operate at layer 2 or 3. For layer 2 support, 735 the LWAPP messages are carried in a native Ethernet frame. As such, 736 the protocol is not routable and depends upon layer 2 connectivity 737 between the WTP and the AC. Layer 3 support is provided by 738 encapsulating the LWAPP messages within UDP. 740 3.1 LWAPP Transport Header 742 All LWAPP protocol packets are encapsulated using a common header 743 format, regardless of the transport used to carry the frames. 744 However, certain flags are not applicable for a given transport, and 745 it is therefore necessary to refer to the specific transport section 746 in order to determine which flags are valid. 748 0 1 2 3 749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 |VER| RID |C|F|L| Frag ID | Length | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Status/WLANs | Payload... | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 3.1.1 VER Field 758 A 2 bit field which contains the version of LWAPP used in this 759 packet. The value for this draft is 0. 761 3.1.2 RID Field 763 A 3 bit field which contains the Radio ID number for this packet. 764 WTPs with multiple radios but a single MAC Address use this field to 765 indicate which radio is associated with the packet. 767 3.1.3 C Bit 769 The C bit indicates whether this packet carries a data message or a 770 control message. When this bit is 0, the packet carries an LWAPP 771 data message in the payload. When this bit is 1, the packet carries 772 an LWAPP control messwage as defined in section 4 for consumption by 773 the addressed destination. 775 3.1.4 F Bit 777 The F bit indicates whether this packet is a fragment. When this bit 778 is 1, the packet is a fragment and MUST be combined with the other 779 corresponding fragments to reassemble the complete information 780 exchanged between the WTP and AC. 782 3.1.5 L Bit 784 The L bit is valid only if the 'F' bit is set and indicates whether 785 the packet contains the last fragment of a fragmented exchange 786 between WTP and AC. When this bit is 1, the packet is not the last 787 fragment. When this bit is 0, the packet is the last fragment. 789 3.1.6 Fragment ID 791 An 8 bit field whose value is assigned to each group of fragments 792 making up a complete set. The value of Fragment ID is incremented 793 with each new set of fragments. The Fragment ID wraps to zero after 794 the maximum value has been used to identify a set of fragments. 795 LWAPP only supports up to 2 fragments per frame. 797 3.1.7 Length 799 The 16 bit length field contains the number of bytes in the Payload. 800 The field is encoded as an unsigned number. 802 3.1.8 Status and WLANS 804 The interpretation of this 16 bit field is binding specific. Refer 805 to the transport portion of the binding for a wireless technology for 806 the specification. 808 3.1.9 Payload 810 This field contains the header for an LWAPP Data Message or LWAPP 811 Control Message, followed by the data associated with that message. 813 3.2 Using IEEE 802.3 MAC as LWAPP transport 815 This section describes how the LWAPP protocol is provided over native 816 ethernet frames. An LWAPP packet is formed from the MAC frame header 817 followed by the LWAPP message header. 819 3.2.1 Framing 821 Source Address 823 A MAC address belonging to the interface from which this message is 824 sent. If multiple source addresses are configured on an interface, 825 then the one chosen is implementation dependent. 827 Destination Address 829 A MAC address belonging to the interface to which this message is to 830 be sent. This destination address MAY be either an individual 831 address or a multicast address, if more than one destination 832 interface is intended. 834 Ethertype 836 The Ethertype field is set to 0x88bb. 838 3.2.2 AC Discovery 840 When run over IEEE 802.3, LWAPP messages are distributed to a 841 specific MAC level broadcast domain. The AC discovery mechanism used 842 with this transport is for an WTP to transmit a Discovery Request 843 message to a broadcast destination MAC address. The ACs will receive 844 this message and reply based on their policy. 846 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC transport 848 All of the fields described in Section 3.1 are used when LWAPP uses 849 the IEEE 802.3 MAC transport. 851 3.2.4 Fragmentation/Reassembly 853 Fragmentation at the MAC layer is managed using the F,L and Frag ID 854 fields of the LWAPP message header. The LWAPP protocol only allows a 855 single packet to be fragmented into 2, which is sufficient for a 856 frame that exceeds MTU due to LWAPP encapsulation. When used with 857 layer 2 (Ethernet) transport, both fragments MUST include the LWAPP 858 header. 860 3.2.5 Multiplexing 862 LWAPP control messages and data messages are distinguished by the C 863 Bit in the LWAPP message header. 865 3.3 Using IPv4/UDP as LWAPP transport 867 This section defines how LWAPP makes use of IPV4/UDP transport 868 between the WTP and the AC. When this transport is used, the MAC 869 layer is controlled by the IPv4 stack, and there are therefore no 870 special MAC layer requirements. 872 3.3.1 Framing 874 Communication between WTP and AC is established according to the 875 standard UDP client/server model. The connection is initiated by the 876 WTP (client) to the well-known UDP port of the AC (server) used for 877 control messages. This UDP port number of the AC is 12222 for LWAPP 878 data and 12223 for LWAPP control frames. 880 3.3.2 AC Discovery 882 When LWAPP is run over routed IPv4 networks, the WTP and the AC do 883 not need to reside in the same IP subnet (broadcast domain). 884 However, in the event the peers reside on separate subnets, there 885 must exist a mechanism for the WTP to discover the AC. 887 As the WTP attempts to establish communication with the AC, it sends 888 the Discovery Request message and receives the corresponding response 889 message from the AC. The WTP must send the Discovery Request message 890 to either the limited broadcast IP address (255.255.255.255), a well 891 known multicast address or to the unicast IP address of the AC. Upon 892 receipt of the message, the AC issues a Discovery Response message to 893 the unicast IP address of the WTP, regardless of whether Discovery 894 Request was sent as a broadcast, multicast or unicast message. 896 Whether the WTP uses a limited IP broadcast, multicast or unicast IP 897 address is implementation dependent. 899 In order for a WTP to transmit a Discovery Request to a unicast 900 address, the WTP must first obtain the IP address of the AC. Any 901 static configuration of an AC's IP address on the WTP non-volatile 902 storage is implementation dependent. However, additional dynamic 903 schemes are possible, for example: 904 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 905 embedded inside a DHCP vendor specific option 43 extension. An 906 example of the actual format of the vendor specific payload is of 907 the form "LWAPP=10.1.1.1, 10.1.1.2". 908 DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to or more AC 909 addresses 911 3.3.3 LWAPP Message Header format over IPv4/UDP transport 913 All of the fields described in Section 3.1 are used when LWAPP uses 914 the IPv4/UDP transport, with the following exceptions: 916 3.3.3.1 F Bit 918 This flag field is not used with this transport, and MUST be set to 919 zero. 921 3.3.3.2 L Bit 923 This flag field is not used with this transport, and MUST be set to 924 zero. 926 3.3.3.3 Frag ID 928 This field is not used with this transport, and MUST be set to zero. 930 3.3.4 Fragmentation/Reassembly 932 When LWAPP is implemented at L3, the transport layer uses IP 933 fragmentation to fragment and reassemble LWAPP messages that are 934 longer than MTU size used by either WTP or AC. The details of IP 935 fragmentation are covered in [8]. When used with the IP transport, 936 only the first fragment would include the LWAPP header 938 [ed: IP fragmentation may raise security concerns and bring 939 additional configuration requirements for certain firewalls and NATs. 940 One alternative is to re-use the layer 2 (application layer) 941 fragmentation reassembly. Comments are welcomed.] 943 3.3.5 Multiplexing 945 LWAPP messages convey control information between WTP and AC, as well 946 as binding specific data frames or binding specific management 947 frames. As such, LWAPP messages need to be multiplexed in the 948 transport sub-layer and be delivered to the proper software entities 949 in the endpoints of the protocol. However, the 'C' bit is still used 950 to differentiate between data and control frames. 952 In case of Layer 3 connection, multiplexing is achieved by use of 953 different UDP ports for control and data packets (see Section 3.3.1. 955 As part of Join procedure, the WTP and AC may negotiate different IP 956 Addresses for data or control messages. The IP Address returned in 957 the AP Manager Control IP Address message element is used to inform 958 the WTP with the IP address to which it must sent all control frames. 959 The AP Manager Data IP Address message element MAY be present only if 960 the AC has a different IP Address which the WTP is to use to send its 961 data LWAPP frames. 963 In the event the WTP and AC are separated by a NAT, with the WTP 964 using private IP address space, it is the responsibility of the NAT 965 to manage appropriate UDP port mapping. 967 4. LWAPP Packet Definitions 969 This section contains the packet types and format. The LWAPP 970 protocol is designed to be transport agnostic by specifying packet 971 formats for both MAC frames and IP packets. An LWAPP packet consists 972 of an LWAPP Transport Layer packet header followed by an LWAPP 973 message. 975 Transport details can be found in Section 3. 977 4.1 LWAPP Data Messages 979 An LWAPP data message is a forwarded wireless frame. When forwarding 980 wireless frames, the sender simply encapsulates the wireless frame in 981 an LWAPP data packet, using the appropriate transport rules defined 982 in section Section 3. 984 In the event that the encapsulated frame would exceed the transport 985 layer's MTU, the sender is responsible for the fragmentation of the 986 frame, as specified in the transport specific section of Section 3. 988 The actual format of the encapsulated LWAPP data frame is subject to 989 the rules defined under the specific wireless technology binding. 991 4.2 LWAPP Control Messages Overview 993 The LWAPP Control protocol provides a control channel between the WTP 994 and the AC. The control channel is the series of control messages 995 between the WTP and AC, associated with a session ID and key. 996 Control messages are divided into the following distinct message 997 types: 998 Discovery: LWAPP Discovery messages are used to identify potential 999 ACs, their load and capabilities. 1000 Control Channel Management: Messages that fall within this 1001 classification are used for the discovery of ACs by the WTPs as 1002 well as the establishment and maintenance of an LWAPP control 1003 channel. 1004 WTP Configuration: The WTP Configuration messages are used by the AC 1005 to push a specific configuration to the WTPs it has a control 1006 channel with. Messages that deal with the retrieval of statistics 1007 from the WTP also fall in this category. 1008 Mobile Session Management: Mobile session management messages are 1009 used by the AC to push specific mobile policies to the WTP. 1010 Firmware Management: Messages in this category are used by the AC to 1011 push a new firmware image down to the WTP. 1013 Control Channel, WTP Configuration and Mobile Session Management MUST 1014 be implemented. Firmware Management MAY be implemented. 1016 In addition, technology specific bindings may introduce new control 1017 channel commands that depart from the above list. 1019 4.2.1 Control Message Format 1021 All LWAPP control messages are sent encapsulated within the LWAPP 1022 header (see Section 3.1). Immediately following the header, is the 1023 LWAPP control header, which has the following format: 1025 0 1 2 3 1026 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1028 | Message Type | Seq Num | Msg Element Length | 1029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1030 | Session ID | 1031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 | Msg Element [0..N] | 1033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 4.2.1.1 Message Type 1037 The Message Type field identifies the function of the LWAPP control 1038 message. The valid values for Message Type are the following: 1040 Description Value 1041 Discovery Request 1 1042 Discovery Response 2 1043 Join Request 3 1044 Join Response 4 1045 Unused 5-9 1046 Configure Request 10 1047 Configure Response 11 1048 Configuration Update Request 12 1049 Configuration Update Response 13 1050 WTP Event Request 14 1051 WTP Event Response 15 1052 Change State Event Request 16 1053 Change State Event Response 17 1054 Unused 18-21 1055 Echo Request 22 1056 Echo Response 23 1057 Image Data Request 24 1058 Image Data Response 25 1059 Reset Request 26 1060 Reset Response 27 1061 Unused 28-29 1062 Key Update Request 30 1063 Key Update Response 31 1064 Primary Discovery Request 32 1065 Primary Discovery Response 33 1066 Data Transfer Request 34 1067 Data Transfer Response 35 1068 Clear Config Indication 36 1069 WLAN Config Request 37 1070 WLAN Config Response 38 1071 Mobile Config Request 39 1072 Mobile Config Response 40 1074 4.2.1.2 Sequence Number 1076 The Sequence Number Field is an identifier value to match 1077 request/response packet exchanges. When an LWAPP packet with a 1078 request message type is received, the value of the sequence number 1079 field is copied into the corresponding response packet. 1081 When an LWAPP control frame is sent, its internal sequence number 1082 counter is monotonically incremented, ensuring that no two requests 1083 pending have the same sequence number. This field will wrap back to 1084 zero. 1086 4.2.1.3 Message Element Length 1088 The Length field indicates the number of bytes following the Session 1089 ID field. 1091 4.2.1.4 Session ID 1093 The Session ID is a 32-bit unsigned integer that is used to identify 1094 the security context for encrypted exchanges between the WTP and the 1095 AC. Note that a Session ID is a random value that MUST be unique 1096 between a given AC and any of the WTP it may be communicating with. 1098 4.2.1.5 Message Element[0..N] 1100 The message element(s) carry the information pertinent to each of the 1101 control message types. Every control message in this specification 1102 specifies which message elements are permitted. 1104 4.2.2 Message Element Format 1106 The message element is used to carry information pertinent to a 1107 control message. Every message element is identified by the Type 1108 field, whose numbering space is managed via IANA (see Section 15). 1109 The total length of the message elements is indicated in the Message 1110 Element Length field. 1112 All of the message element definitions in this document use a diagram 1113 similar to the one below in order to depict its format. Note that in 1114 order to simplify this specification, these diagrams do not include 1115 the header fields (Type and Length). However, in every message 1116 element description, the header's fields values will be defined. 1118 Note that additional message elements may be defined in separate IETF 1119 documents. 1121 The format of a message element uses the TLV format shown here: 1123 0 1 2 3 1124 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Type | Length | Value ... | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1129 Where Type (8 bit) identifies the character of the information 1130 carried in the Value field and Length (16 bits) indicates the number 1131 of bytes in the Value field. 1133 4.2.2.1 Generic Message Elements 1135 This section includes message elements that are not bound to a 1136 specific control message. 1138 4.2.2.1.1 Vendor Specific 1140 The Vendor Specific Payload is used to communicate vendor specific 1141 information between the WTP and the AC. The value contains the 1142 following format: 1144 0 1 2 3 1145 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Vendor Identifier | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Element ID | Value... | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 Type: 104 for Vendor Specific 1153 Length: >= 7 1154 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 1155 Network Management Private Enterprise Codes" [9] 1156 Element ID: A 16-bit Element Idenfier which is managed by the 1157 vendor. 1158 Value: The value associated with the vendor specific element. 1160 5. LWAPP Discovery Operations 1162 The Discovery messages are used by an WTP to determine which ACs are 1163 available to provide service, as well as the capabilities and load of 1164 the ACs. 1166 5.1 Discovery Request 1168 The Discovery Request is used by the WTP to automatically discover 1169 potential ACs available in the network. An WTP must transmit this 1170 command even if it has a statically configured AC, as it is a 1171 required step in the LWAPP state machine. 1173 Discovery Requests MUST be sent by an WTP in the Discover state after 1174 waiting for a random delay less than MaxDiscoveryInterval, after an 1175 WTP first comes up or is (re)initialized. An WTP MUST send no more 1176 than a maximum of MaxDiscoveries discoveries, waiting for a random 1177 delay less than MaxDiscoveryInterval between each successive 1178 discovery. 1180 This is to prevent an explosion of WTP Discoveries. An example of 1181 this occurring would be when many WTPs are powered on at the same 1182 time. 1184 Discovery requests MUST be sent by an WTP when no echo responses are 1185 received for NeighborDeadInterval and the WTP returns to the Idle 1186 state. Discovery requests are sent after NeighborDeadInterval, they 1187 MUST be sent after waiting for a random delay less than 1188 MaxDiscoveryInterval. An WTP MAY send up to a maximum of 1189 MaxDiscoveries discoveries, waiting for a random delay less than 1190 MaxDiscoveryInterval between each successive discovery. 1192 If a discovery response is not received after sending the maximum 1193 number of discovery requests, the WTP enters the Sulking state and 1194 MUST wait for an interval equal to SilentInterval before sending 1195 further discovery requests. 1197 The Discovery Request message may be sent as a unicast, broadcast or 1198 multicast message. 1200 Upon receiving a discovery request, the AC will respond with a 1201 Discovery Response sent to the address in the source address of the 1202 received discovery request. 1204 The following subsections define the message elements that MUST be 1205 included in this LWAPP operation. 1207 5.1.1 Discovery Type 1209 The Discovery message element is used to configure an WTP to operate 1210 in a specific mode. 1212 0 1213 0 1 2 3 4 5 6 7 1214 +-+-+-+-+-+-+-+-+ 1215 | Discovery Type| 1216 +-+-+-+-+-+-+-+-+ 1218 Type: 58 for Discovery Type 1219 Length: 1 1220 Discovery Type: An 8-bit value indicating how the AC was discovered. 1221 The following values are supported: 1222 0 - Broadcast 1223 1 - Configured 1225 5.1.2 WTP Descriptor 1227 The WTP descriptor message element is used by the WTP to communicate 1228 it's current hardware/firmware configuration. The value contains the 1229 following fields. 1231 0 1 2 3 1232 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Hardware Version | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Software Version | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Boot Version | 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | Max Radios | Radios in use | Encryption Capabilities | 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 Type: 3 for WTP Descriptor 1244 Length: 16 1245 Hardware Version: A 32-bit integer representing the WTP's hardware 1246 version number 1247 Software Version: A 32-bit integer representing the WTP's Firmware 1248 version number 1249 Boot Version: A 32-bit integer representing the WTP's boot loader's 1250 version number 1251 Max Radios: An 8-bit value representing the number of radios (where 1252 each radio is identified via the RID field) supported by the WTP 1254 Radios in use: An 8-bit value representing the number of radios 1255 present in the WTP 1256 Encryption Capabilities: This 16-bit field is used by the WTP to 1257 communicate it's capabilities to the AC. Since most WTPs support 1258 link layer encryption, the AC may make use of these services. 1259 There are binding dependent encryption capabilites. An WTP that 1260 does not have any encryption capabilities would set this field to 1261 zero (0). Refer to the specific binding for the specification. 1263 5.1.3 WTP Radio Information 1265 The WTP radios information message element is used to communicate the 1266 radio information in a specific slot. The Discovery Request MUST 1267 include one such message element per radio in the WTP. The 1268 Radio-Type field is used by the AC in order to determine which 1269 technology specific binding is to be used with the WTP. 1271 The value contains two fields, as shown. 1273 0 1 1274 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1276 | Radio ID | Radio Type | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1279 Type: 4 for WTP Radio Information 1280 Length: 2 1281 Radio ID: The Radio Identifier, typically refers to some interface 1282 index on the WTP 1283 Radio Type: The type of radio present. The following values are 1284 supported 1285 1 - 802.11bg: An 802.11bg radio. 1286 2 - 802.11a: An 802.11a radio. 1287 3 - 802.16: An 802.16 radio. 1288 4 - Ultra Wideband: An UWB radio. 1289 7 - all: Used to specify all radios in the WTP. 1291 5.2 Discovery Response 1293 The Discovery Response is a mechanism by which an AC advertises its 1294 services to requesting WTPs. 1296 Discovery Responses are sent by an AC after receiving a Discovery 1297 Request. 1299 When an WTP receives a Discovery Response, it MUST wait for an 1300 interval not less than DiscoveryInterval for receipt of additional 1301 Discovery Responses. After the DiscoveryInterval elapses, the WTP 1302 enters the Joining state and will select one of the ACs that sent a 1303 Discovery Response and send a Join Request to that AC. 1305 The following subsections define the message elements that MUST be 1306 included in this LWAPP operation. 1308 5.2.1 AC Descriptor 1310 The AC payload message element is used by the AC to communicate it's 1311 current state. The value contains the following fields. 1313 0 1 2 3 1314 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | Reserved | Hardware Version ... | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 | HW Ver | Software Version ... | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1320 | SW Ver | Stations | Limit | 1321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1322 | Limit | Radios | Max Radio | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Max Radio | 1325 +-+-+-+-+-+-+-+-+ 1327 Type: 6 for AC Descriptor 1328 Length: 17 1329 Reserved: MUST be set to zero 1330 Hardware Version: A 32-bit integer representing the AC's hardware 1331 version number 1332 Software Version: A 32-bit integer representing the AC's Firmware 1333 version number 1334 Stations: A 16-bit integer representing number of mobile stations 1335 currently associated with the AC 1336 Limit: A 16-bit integer representing the maximum number of stations 1337 supported by the AC 1338 Radios: A 16-bit integer representing the number of WTPs currently 1339 attached to the AC 1340 Max Radio: A 16-bit integer representing the maximum number of WTPs 1341 supported by the AC 1343 5.2.2 AC Name 1345 The AC name message element contains an ASCII representation of the 1346 AC's identity. The value is a variable length byte string. The 1347 string is NOT zero terminated. 1349 0 1350 0 1 2 3 4 5 6 7 1351 +-+-+-+-+-+-+-+-+ 1352 | Name ... 1353 +-+-+-+-+-+-+-+-+ 1355 Type: 31 for AC Name 1356 Length: > 0 1357 Name: A variable length ASCII string containing the AC's name 1359 5.2.3 WTP Manager Control IP Address 1361 The WTP Manager Control IP Address message element is sent by the AC 1362 to the WTP during the discovery process and is used by the AC to 1363 provide the interfaces available on the AC, and their current load. 1364 This message elemenet is useful for the WTP to perform load balancing 1365 across multiple interfaces. 1367 0 1 2 3 1368 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1370 | IP Address | 1371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1372 | WTP Count | 1373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 Type: 99 for WTP Manager Control IP Address 1376 Length: 6 1377 IP Address: The IP Address of an interface. 1378 WTP Count: The number of WTPs currently connected to the interface. 1380 5.3 Primary Discovery Request 1382 The Primary Discovery Request is sent by the WTP in order to 1383 determine whether its preferred (or primary) AC is available. 1385 Primary Discovery Request are sent by an WTP when it has a primary AC 1386 configured, and is connected to another AC. This generally occurs as 1387 a result of a failover, and is used by the WTP as a means to discover 1388 when its primary AC becomes available. As a consequence, this 1389 message is only sent by a WTP when it is in the Run state. 1391 The frequency of the Primary Discovery Requests should be no more 1392 often than the sending of the Echo Request message. 1394 Upon receiving a discovery request, the AC will respond with a 1395 Primary Discovery Response sent to the address in the source address 1396 of the received Primary Discovery Request. 1398 The following subsections define the message elements that MUST be 1399 included in this LWAPP operation. 1401 5.3.1 Discovery Type 1403 The Discovery Type message element is defined in section 1404 Section 5.1.1. 1406 5.3.2 WTP Descriptor 1408 The WTP Descriptor message element is defined in section 1409 Section 5.1.2. 1411 5.3.3 WTP Radio Information 1413 An WTP Radio Information message element must be present for every 1414 radio in the WTP. This message element is defined in section 1415 Section 5.1.3. 1417 5.4 Primary Discovery Response 1419 The Primary Discovery Response is a mechanism by which an AC 1420 advertises its availability and services to requesting WTPs that are 1421 configured to have the AC as its primary AC. 1423 Primary Discovery Responses are sent by an AC after receiving a 1424 Primary Discovery Request. 1426 When an WTP receives a Primary Discovery Response, it may opt to 1427 establish an LWAPP connection to its primary AC, based on the 1428 configuration of the WTP Fallback Status message element on the WTP. 1430 The following subsections define the message elements that MUST be 1431 included in this LWAPP operation. 1433 5.4.1 AC Descriptor 1435 The Discovery Type message element is defined in section 1436 Section 5.2.1. 1438 5.4.2 AC Name 1440 The AC Name message element is defined in section Section 5.2.2. 1442 5.4.3 WTP Manager Control IP Address 1444 An WTP Radio Information message element must be present for every 1445 radio in the WTP. This message element is defined in section 1446 Section 5.2.3. 1448 6. Control Channel Management 1450 The Control Channel Management messages are used by the WTP and AC to 1451 create and maintain a channel of communication on which various other 1452 commands may be transmitted, such as configuration, firmware update, 1453 etc. 1455 6.1 Join Request 1457 The Join Request is used by an WTP to inform an AC that it wishes to 1458 provide services through it. 1460 Join Requests are sent by an WTP in the Joining state after receiving 1461 one or more Discovery Responses. The Join Request is also used as an 1462 MTU discovery mechanism by the WTP. The WTP issues a Join Request 1463 with a Test message element, bringing the total size of the message 1464 to exceed MTU. 1466 If the transport used does not provide MTU path discovery, the 1467 initial Join Request is padded with the Test message element to 1596 1468 bytes. If a Join Response is received, the WTP can forward frames 1469 without requiring any fragmentation. If no Join Response is 1470 received, it issues a second Join Request padded with the Test 1471 payload to a total of 1500 bytes. The WTP continues to cycle from 1472 large (1596) to small (1500) packets until a Join Response has been 1473 received, or until both packets sizes have been retransmitted 3 1474 times. If the Join Response is not received after the maximum number 1475 of retransmissions, the WTP MUST abandon the AC and restart the 1476 discovery phase. 1478 When an AC receives a Join Request it will respond with a Join 1479 Response. The AC validates the certificate found in the request. If 1480 valid, the AC generates a session key which will be used to secure 1481 the control frames it exchanges with the WTP. When the AC issues the 1482 Join Response, the AC creates a context for the session with the WTP. 1484 Details on the key generation is found in Section 10. 1486 The following subsections define the message elements that MUST be 1487 included in this LWAPP operation. 1489 6.1.1 AC Address 1491 The AC address message element is used to communicate the identity of 1492 the AC. The value contains two fields, as shown. 1494 0 1 2 3 1495 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1496 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1497 | Reserved | MAC Address | 1498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1499 | MAC Address | 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1502 Type: 2 for AC Address 1503 Length: 7 1504 Reserved: MUST be set to zero 1505 Mac Address: The MAC Address of the AC 1507 6.1.2 WTP Descriptor 1509 The WTP Descriptor message element is defined in section 1510 Section 5.1.2. 1512 6.1.3 WTP Name 1514 The WTP name message element value is a variable length byte string. 1515 The string is NOT zero terminated. 1517 0 1518 0 1 2 3 4 5 6 7 1519 +-+-+-+-+-+-+-+-+ 1520 | Name ... 1521 +-+-+-+-+-+-+-+-+ 1523 Type: 5 for WTP Name 1524 Length: > 0 1525 Name: A non zero terminated string containing the WTP's name. 1527 6.1.4 Location Data 1529 The location data message element is a variable length byte string 1530 containing user defined location information (e.g. "Next to 1531 Fridge"). The string is NOT zero terminated. 1533 0 1534 0 1 2 3 4 5 6 7 1535 +-+-+-+-+-+-+-+-+ 1536 | Location ... 1537 +-+-+-+-+-+-+-+-+ 1539 Type: 35 for Location Data 1540 Length: > 0 1541 Location: A non zero terminated string containing the WTP's 1542 location. 1544 6.1.5 WTP Radio Information 1546 An WTP Radio Information message element must be present for every 1547 radio in the WTP. This message element is defined in section 1548 Section 5.1.3. 1550 6.1.6 Certificate 1552 The certificate message element value is a byte string containing a 1553 DER-encoded x.509v3 certificate. 1555 0 1556 0 1 2 3 4 5 6 7 1557 +-+-+-+-+-+-+-+-+ 1558 | Certificate... 1559 +-+-+-+-+-+-+-+-+ 1561 Type: 44 for Certificate 1562 Length: > 0 1563 Certificate: A non zero terminated string containing the device's 1564 certificate. 1566 6.1.7 Session ID 1568 The session ID message element value contains a randomly generated 1569 [4] unsigned 32-bit integer. 1571 0 1 2 3 1572 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1574 | Session ID | 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 Type: 45 for Session ID 1578 Length: 4 1579 Session ID: 32 bit random session identifier. 1581 6.1.8 Test 1583 The test message element is used as padding to perform MTU discovery, 1584 and MAY contain any value, of any length. 1586 0 1587 0 1 2 3 4 5 6 7 1588 +-+-+-+-+-+-+-+-+ 1589 | Padding ... 1590 +-+-+-+-+-+-+-+-+ 1592 Type: 18 for Test 1593 Length: > 0 1594 Padding: A variable length pad. 1596 6.2 Join Response 1598 The Join Response is sent by the AC to indicate to an WTP whether it 1599 is capable and willing to provide service to it. 1601 Join Responses are sent by the AC after receiving a Join Request. 1602 Once the Join Response has been sent, the heartbeat timer is 1603 initiated for the session to EchoInterval. Expiration of the timer 1604 will result in deletion of the AC-WTP session. The timer is 1605 refreshed upon receipt of the Echo Request. 1607 When an WTP receives a Join Response it enters the Joined state and 1608 initiates either a Configure Request or Image Data to the AC to which 1609 it is now joined. Upon entering the Joined state, the WTP begins 1610 timing an interval equal to NeighborDeadInterval. Expiration of the 1611 timer will result in the transmission of the Echo Request. 1613 The following subsections define the message elements that MUST be 1614 included in this LWAPP operation. 1616 6.2.1 Result Code 1618 The Result Code message element value is a 32-bit integer value, 1619 indicating the result of the request operation corresponding to the 1620 sequence number in the message. The Result Code is included in a 1621 successful Join Response. 1623 0 1 2 3 1624 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1626 | Result Code | 1627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 Type: 2 for Result Code 1630 Length: 4 1631 Result Code: The following values are defined: 1632 0 Success 1633 1 Failure 1635 6.2.2 Status 1637 The Status message element is sent by the AC to the WTP in a 1638 non-successful Join Response message. This message element is used 1639 to indicate the reason for the failure and should only be accompanied 1640 with a Result Code message element that indicates a failure. 1642 0 1643 0 1 2 3 4 5 6 7 1644 +-+-+-+-+-+-+-+-+ 1645 | Status | 1646 +-+-+-+-+-+-+-+-+ 1648 Type: 60 for Status 1649 Length: 1 1650 Status: The status field indicates the reason for an LWAPP failure. 1651 The following values are supported: 1652 1 - Reserved - do not use 1653 2 - Resource Depletion 1654 3 - Unknown Source 1655 4 - Incorrect Data 1657 6.2.3 Certificate 1659 The Certificate message element is defined in section Section 6.1.6. 1661 6.2.4 Session Key 1663 The Session Key message element is sent by the AC to the WTP and 1664 includes the randomly generated session key, which is used to protect 1665 the LWAPP control messages. More details are available in 1666 Section 10. The value contains the following fields. 1668 0 1 2 3 1669 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | Session ID | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Session Key | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | Session Key | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | Session Key | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Session Key | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1682 Type: 46 for Session Key 1683 Length: 20 1684 Session ID: A 32-bit value defined in the session ID above. 1685 Session Key: A signed, encrypted 128-bit randomly generated session 1686 key. See Section 10 for more information on how this field is 1687 created. 1689 6.2.5 WTP Manager Data IP Address 1691 The WTP Manager Data IP Address message element is optionally sent by 1692 the AC to the WTP during the join phase. If present, the IP Address 1693 contained in this message element is the address the WTP is to use 1694 when sending any of its LWAPP data frames. 1696 Note this message element is only valid when LWAPP uses the IP/UDP 1697 layer 3 transport 1699 0 1 2 3 1700 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | IP Address | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 Type: TBD for WTP Manager Data IP Address 1706 Length: 4 1707 IP Address: The IP Address of an interface. 1709 6.3 Echo Request 1711 The Echo Request message is a keepalive mechanism for the LWAPP 1712 control message. 1714 Echo Requests are sent periodically by an WTP in the Run state (see 1715 Figure 3) to determine the state of the connection between the WTP 1716 and the AC. The Echo Request is sent by the WTP when the Heartbeat 1717 timer expires, and it MUST start its NeighborDeadInterval timer. 1719 The Echo Request carries no message elements. 1721 When an AC receives an Echo Request it responds with an Echo 1722 Response. 1724 6.4 Echo Response 1726 The Echo Response acknowledges the Echo Request, and are only 1727 accepted while in the Run state (see Figure 3). 1729 Echo Responses are sent by an AC after receiving an Echo Request. 1730 After transmitting the Echo Response, the AC should reset its 1731 Heartbeat timer to expire in the value configured for EchoInterval. 1732 If another Echo request is not received by the AC when the timer 1733 expires, the AC SHOULD consider the AP to no longer be reachable. 1735 The Echo Response carries no message elements. 1737 When an WTP receives an Echo Response it stops the 1738 NeighborDeadInterval timer, and starts the Heartbeat timer to 1739 EchoInterval. 1741 If the NeighborDeadInterval timer expires prior to receiving an Echo 1742 Response, the WTP enters the Idle state. 1744 6.5 Key Update Request 1746 The Key Update Request updates the LWAPP session key used to secure 1747 messages between the WTP and the AC. 1749 Key Update Requests are sent by an WTP in the Run state to update a 1750 session key. The Session ID message element MUST include a new 1751 session identifier. 1753 When an AC receives a Key Update Request it generates a new key (see 1754 Section 10) and responds with a Key Update Response. 1756 The following subsections define the message elements that MUST be 1757 included in this LWAPP operation. 1759 6.5.1 Session ID 1761 The Session ID message element is defined in section Section 6.1.7. 1763 6.6 Key Update Response 1765 The Key Update Response updates the LWAPP session key used to secure 1766 messages between the WTP and the AC, and acknowledges the Key Update 1767 Request. 1769 Key Update Responses are sent by a AC after receiving a Key Update 1770 Request. The Key Update Responses is secured using public key 1771 cryptography. 1773 When an WTP receives a Key Update Response it will use the 1774 information contained in the Session Key message element to determine 1775 the keying material used to encrypt the LWAPP communications between 1776 the WTP and the AC. 1778 The following subsections define the message elements that MUST be 1779 included in this LWAPP operation. 1781 6.6.1 Session Key 1783 The Session Key message element is defined in section Section 6.2.4. 1785 6.7 Key Update Trigger 1787 The Key Update Trigger is used by the AC to request that a Key Update 1788 Request be initiated by the WTP. 1790 Key Update Trigger are sent by an AC in the Run state to inform the 1791 WTP to initiate a Key Update Request message. 1793 When a WTP receives a Key Update Trigger it generates a key Update 1794 Request. 1796 The following subsections define the message elements that MUST be 1797 included in this LWAPP operation. 1799 6.7.1 Session ID 1801 The Session ID message element is defined in section Section 6.1.7. 1803 7. WTP Configuration Management 1805 The Wireless Termination Point Configuration messages are used to 1806 exchange configuration between the AC and the WTP. 1808 7.1 Configure Request 1810 The Configure Request message is sent by an WTP to send its current 1811 configuration to its AC. 1813 Configure Requests are sent by an WTP after receiving a Join 1814 Response, while in the Configure state. 1816 The Configure Request carries binding specific message elements. 1817 Refer to the appropriate binding for the definition of this 1818 structure. 1820 When an AC receives a Configure Request it will act upon the content 1821 of the packet and respond to the WTP with a Configure Response. 1823 The Configure Request includes multiple Administrative State message 1824 Elements. There is one such message element for the WTP, and then 1825 one per radio in the WTP. 1827 The following subsections define the message elements that MUST be 1828 included in this LWAPP operation. 1830 7.1.1 Administrative State 1832 The administrative event message element is used to communicate the 1833 state of a particular radio. The value contains the following 1834 fields. 1836 0 1 1837 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | Radio ID | Admin State | 1840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1842 Type: 27 for Administrative State 1843 Length: 2 1844 Radio ID: An 8-bit value representing the radio to configure. The 1845 Radio ID field may also include the value of 0xff, which is used 1846 to identify the WTP itself. Therefore, if an AC wishes to change 1847 the administrative state of an WTP, it would include 0xff in the 1848 Radio ID field. 1850 Admin State: An 8-bit value representing the administrative state of 1851 the radio. The following values are supported: 1852 1 - Enabled 1853 2 - Disabled 1855 7.1.2 AC Name 1857 The AC Name message element is defined in section Section 5.2.2. 1859 7.1.3 AC Name with Index 1861 The AC Name with Index message element is sent by the AC to the WTP 1862 to configure preferred ACs. The number of instances where this 1863 message element would be present is equal to the number of ACs 1864 configured on the WTP. 1866 0 1 1867 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | Index | AC Name... 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1872 Type: 90 for AC Name with Index 1873 Length: 5 1874 Index: The index of the preferred server (e.g., 1=primary, 1875 2=secondary). 1876 AC Name: A variable length ASCII string containing the AC's name. 1878 7.1.4 WTP Board Data 1880 The WTP Board Data message element is sent by the WTP to the AC and 1881 contains information about the hardware present. 1883 0 1 2 3 1884 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1886 | Card ID | Card Revision | 1887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1888 | WTP Model | 1889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1890 | WTP Model | 1891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1892 | WTP Serial Number ... | 1893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1894 | WTP Options | 1895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1896 | Ethernet MAC Address | 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Ethernet MAC Address | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 Type: 50 for WTP Board Data 1902 Length: 26 1903 Card ID: A hardware identifier. 1904 Card Revision: Revision of the card. 1905 WTP Model: WTP Model Number. 1906 WTP Serial Number: WTP Serial Number. 1907 WTP Options: A vendor specific field encoding specific options 1908 enabled on the WTP. 1909 Ethernet MAC Address: MAC Address of the WTP's Ethernet interface. 1911 7.1.5 Statistics Timer 1913 The statistics timer message element value is used by the AC to 1914 inform the WTP of the frequency which it expects to receive updated 1915 statistics. 1917 0 1 1918 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1920 | Statistics Timer | 1921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 Type: 37 for Statistics Timer 1924 Length: 2 1925 Statistics Timer: A 16-bit unsigned integer indicating the time, in 1926 seconds 1928 7.1.6 WTP Static IP Address Information 1930 The WTP Static IP Address Information message element is used by an 1931 AC to configure or clear a previously configured static IP address on 1932 an WTP. 1934 0 1 2 3 1935 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | IP Address | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | Netmask | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | Gateway | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 | Static | 1944 +-+-+-+-+-+-+-+-+ 1946 Type: 82 for WTP Static IP Address Information 1947 Length: 13 1948 IP Address: The IP Address to assign to the WTP. 1949 Netmask: The IP Netmask. 1950 Gateway: The IP address of the gateway. 1951 Netmask: The IP Netmask. 1952 Static: An 8-bit boolean stating whether the WTP should use a static 1953 IP address or not. 1955 7.1.7 WTP Reboot Statistics 1957 The WTP Reboot Statistics message element is sent by the WTP to the 1958 AC to communicate information about reasons why reboots have 1959 occurred. 1961 0 1 2 3 1962 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | Crash Count | LWAPP Initiated Count | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Link Failure Count | Failure Type | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1969 Type: 67 for WTP Reboot Statistics 1970 Length: 7 1971 Crash Count: The number of reboots that have occurred due to an WTP 1972 crash. 1973 LWAPP Initiated Count: The number of reboots that have occured at 1974 the request of some LWAPP message, such as a change in 1975 configuration that required a reboot or an explicit LWAPP reset 1976 request. 1977 Link Failure Count: The number of times that an LWAPP connection 1978 with an AC has failed. 1979 Failure Type: The last WTP failure. The following values are 1980 supported: 1981 0 - Link Failure 1982 1 - LWAPP Initiated 1983 2 - WTP Crash 1985 7.2 Configure Response 1987 The Configure Response message is sent by an AC and provides an 1988 opportunity for the AC to override an WTP's requested configuration. 1990 Configure Responses are sent by an AC after receiving a Configure 1991 Request. 1993 The Configure Response carries binding specific message elements. 1995 Refer to the appropriate binding for the definition of this 1996 structure. 1998 When an WTP receives a Configure Response it acts upon the content of 1999 the packet, as appropriate. If the Configure Response message 2000 includes a Change State Event message element that causes a change in 2001 the operational state of one of the Radio, the WTP will transmit a 2002 Change State Event to the AC, as an acknowledgement of the change in 2003 state. 2005 The following subsections define the message elements that MUST be 2006 included in this LWAPP operation. 2008 7.2.1 Decryption Error Report Period 2010 The Decryption Error Report Period message element value is used by 2011 the AC to inform the WTP how frequently it should send decryption 2012 error report messages. 2014 0 1 2 2015 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2016 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2017 | Radio ID | Report Interval | 2018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 Type: 38 for Decryption Error Report Period 2021 Length: 3 2022 Radio ID: The Radio Identifier, typically refers to some interface 2023 index on the WTP 2024 Report Interval: A 16-bit unsigned integer indicating the time, in 2025 seconds 2027 7.2.2 Change State Event 2029 The WTP radios information message element is used to communicate the 2030 operational state of a radio. The value contains two fields, as 2031 shown. 2033 0 1 2034 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2036 | Radio ID | State | Cause | 2037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 Type: 26 for Change State Event 2040 Length: 3 2041 Radio ID: The Radio Identifier, typically refers to some interface 2042 index on the WTP. 2043 State: An 8-bit boolean containing the state of the radio. 2044 Cause: In the event of a radio being inoperable, the cause field 2045 would contain the reason the radio is out of service. 2047 7.2.3 LWAPP Timers 2049 The LWAPP Timers message element is used by an AC to configure LWAPP 2050 timers on an WTP. 2052 0 1 2053 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 | Discovery | Echo Request | 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2058 Type: 68 for LWAPP Timers 2059 Length: 2 2060 Discovery: The number of seconds between LWAPP Discovery packets, 2061 when the WTP is in the discovery mode. 2062 Echo Request: The number of seconds between WTP Echo Request LWAPP 2063 messages. 2065 7.2.4 AC List 2067 The AC List message element is used to configure an WTP with the 2068 latest list of ACs in a cluster. 2070 0 1 2 3 2071 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2073 | AC IP Address[] | 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 Type: 59 for AC List 2077 Length: >= 4 2078 AC IP Address: An array of 32-bit integers containing an AC's IP 2079 Address. 2081 7.2.5 WTP Fallback 2083 The WTP Fallback message element is sent by the AC to the WTP to 2084 enable or disable automatic LWAPP fallback in the event that an WTP 2085 detects its preferred AC, and is not currently connected to it. 2087 0 2088 0 1 2 3 4 5 6 7 2089 +-+-+-+-+-+-+-+-+ 2090 | Mode | 2091 +-+-+-+-+-+-+-+-+ 2093 Type: 91 for WTP Fallback 2094 Length: 1 2095 Mode: The 8-bit boolean value indicates the status of automatic 2096 LWAPP fallback on the WTP. When enabled, if the WTP detects that 2097 its primary AC is available, and it is not connected to it, it 2098 SHOULD automatically disconnect from its current AC and reconnect 2099 to its primary. If disabled, the WTP will only reconnect to its 2100 primary through manual intervention (e.g., through the Reset 2101 Request command). 2103 7.2.6 Idle Timeout 2105 The Idle Timeout message element is sent by the AC to the WTP to 2106 provide it with the idle timeout that it should enforce on its active 2107 mobile station entries. 2109 0 1 2 3 2110 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2112 | Timeout | 2113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 Type: 97 for Idle Timeout 2116 Length: 4 2117 Timeout: The current idle timeout to be enforced by the WTP. 2119 7.3 Configuration Update Request 2121 Configure Update Requests are sent by the AC to provision the WTP 2122 while in the Run state. This is used to modify the configuration of 2123 the WTP while it is operational. 2125 When an AC receives a Configuration Update Request it will respond 2126 with a Configuration Update Response, with the appropriate Result 2127 Code. 2129 The following subsections define the message elements introduced by 2130 this LWAPP operation. 2132 7.3.1 WTP Name 2134 The WTP Name message element is defined in section Section 6.1.3. 2136 7.3.2 Change State Event 2138 The Change State Event message element is defined in section 2139 Section 7.2.2. 2141 7.3.3 Administrative State 2143 The Administrative State message element is defined in section 2144 Section 7.1.1. 2146 7.3.4 Statistics Timer 2148 The Statistics Timer message element is defined in section 2149 Section 7.1.5. 2151 7.3.5 Location Data 2153 The Location Data message element is defined in section 2154 Section 6.1.4. 2156 7.3.6 Decryption Error Report Period 2158 The Decryption Error Report Period message element is defined in 2159 section Section 7.2.1. 2161 7.3.7 AC List 2163 The AC List message element is defined in section Section 7.2.4. 2165 7.3.8 Add Blacklist Entry 2167 The Add Blacklist Entry message element is used by an AC to add a 2168 blacklist entry on an WTP, ensuring that the WTP no longer provides 2169 any service to the MAC addresses provided in the message. The MAC 2170 Addresses provided in this message element are not expected to be 2171 saved in non-volative memory on the WTP. 2173 0 1 2 3 2174 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 | Num of Entries| MAC Address[] | 2177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2178 | MAC Address[] | 2179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2181 Type: 65 for Add Blacklist Entry 2182 Length: >= 7 2183 Num of Entries: The number of MAC Addresses in the array. 2184 MAC Address: An array of MAC Addresses to add to the blacklist 2185 entry. 2187 7.3.9 Delete Blacklist Entry 2189 The Delete Blacklist Entry message element is used by an AC to delete 2190 a previously added blacklist entry on an WTP, ensuring that the WTP 2191 provides service to the MAC addresses provided in the message. 2193 0 1 2 3 2194 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 | Num of Entries| MAC Address[] | 2197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2198 | MAC Address[] | 2199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2201 Type: 66 for Delete Blacklist Entry 2202 Length: >= 7 2203 Num of Entries: The number of MAC Addresses in the array. 2204 MAC Address: An array of MAC Addresses to delete from the blacklist 2205 entry. 2207 7.3.10 Add Static Blacklist Entry 2209 The Add Static Blacklist Entry message element is used by an AC to 2210 add a permanent blacklist entry on an WTP, ensuring that the WTP no 2211 longer provides any service to the MAC addresses provided in the 2212 message. The MAC Addresses provided in this message element are 2213 expected to be saved in non-volative memory on the WTP. 2215 0 1 2 3 2216 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2218 | Num of Entries| MAC Address[] | 2219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2220 | MAC Address[] | 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2223 Type: 70 for Delete Blacklist Entry 2224 Length: >= 7 2225 Num of Entries: The number of MAC Addresses in the array. 2227 MAC Address: An array of MAC Addresses to add to the permanent 2228 blacklist entry. 2230 7.3.11 Delete Static Blacklist Entry 2232 The Delete Static Blacklist Entry message element is used by an AC to 2233 delete a previously added static blacklist entry on an WTP, ensuring 2234 that the WTP provides service to the MAC addresses provided in the 2235 message. 2237 0 1 2 3 2238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2240 | Num of Entries| MAC Address[] | 2241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2242 | MAC Address[] | 2243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 Type: 71 for Delete Blacklist Entry 2246 Length: >= 7 2247 Num of Entries: The number of MAC Addresses in the array. 2248 MAC Address: An array of MAC Addresses to delete from the static 2249 blacklist entry. 2251 7.3.12 LWAPP Timers 2253 The LWAPP Timers message element is defined in section Section 7.2.3. 2255 7.3.13 AC Name with Index 2257 The AC Name with Index message element is defined in section 2258 Section 7.1.3. 2260 7.3.14 WTP Fallback 2262 The WTP Fallback message element is defined in section Section 7.2.5. 2264 7.3.15 Idle Timeout 2266 The Idle Timeout message element is defined in section Section 7.2.6. 2268 7.4 Configuration Update Response 2270 The Configuration Update Response is the acknowledgement message for 2271 the Configuration Update Request. 2273 Configuration Update Responses are sent by an WTP after receiving a 2274 Configuration Update Request. 2276 When an AC receives a Configure Update Response the result code 2277 indicates if the WTP successfully accepted the configuration. 2279 The following subsections define the message elements that must be 2280 present in this LWAPP operation. 2282 7.4.1 Result Code 2284 The Result Code message element is defined in section Section 6.2.1. 2286 7.5 Change State Event Request 2288 The Change State Event is used by the WTP to inform the AC of a 2289 change in the operational state. 2291 The Change State Event message is sent by the WTP when it receives a 2292 Configuration Response that includes a Change State Event message 2293 element. It is also sent in the event that the WTP detects an 2294 operational failure with a radio. The Change State Event may be sent 2295 in either the Configure or Run state (see Figure 3. 2297 When an AC receives a Change State Event it will respond with a 2298 Change State Event Response and make any necessary modifications to 2299 internal WTP data structures. 2301 The following subsections define the message elements that must be 2302 present in this LWAPP operation. 2304 7.5.1 Change State Event 2306 The Change State Event message element is defined in section 2307 Section 7.2.2. 2309 7.6 Change State Event Response 2311 The Change State Event Response acknowledges the Change State Event. 2313 Change State Event Response are sent by an WTP after receiving a 2314 Change State Event. 2316 The Change State Event Response carries no message elements. Its 2317 purpose is to acknowledge the receipt of the Change State Event. 2319 The WTP does not need to perform any special processing of the Change 2320 State Event Response message. 2322 7.7 Clear Config Indication 2324 The Clear Config Indication is used to reset an WTP's configuration. 2326 The Clear Config Indication is sent by an AC to request that an WTP 2327 reset its configuration to manufacturing defaults. The Clear Config 2328 Indication message is sent while in the Run LWAPP state. 2330 The Reset Request carries no message elements. 2332 When an WTP receives a Clear Config Indication it will reset its 2333 configuration to manufacturing defaults. 2335 8. Device Management Operations 2337 This section defines LWAPP operations responsible for debugging, 2338 gathering statistics, logging, and firmware management. 2340 8.1 Image Data Request 2342 The Image Data Request is used to update firmware on the WTP. This 2343 message and its companion response are used by the AC to ensure that 2344 the image being run on each WTP is appropriate. 2346 Image Data Requests are exchanged between the WTP and the AC to 2347 download a new program image to an WTP. 2349 When an WTP or AC receives an Image Data Request it will respond with 2350 a Image Data Response. 2352 The format of the Image Data and Image Download message elements are 2353 described in the following subsections. 2355 8.1.1 Image Download 2357 The image download message element is sent by the WTP to the AC and 2358 contains the image filename. The value is a variable length byte 2359 string. The string is NOT zero terminated. 2361 8.1.2 Image Data 2363 The image data message element is present when sent by the AC and 2364 contains the following fields. 2366 0 1 2 3 2367 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2369 | Opcode | Checksum | Image Data | 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2371 | Image Data ... | 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2374 Type: 33 for Image Data 2375 Length: >= 5 2376 Opcode: An 8-bit value representing the transfer opcode. The 2377 following values are supported: 2378 3 - Image data is included 2379 5 - An error occurred. Transfer is aborted 2381 Checksum: A 16-bit value containing a checksum of the image data 2382 that follows 2383 Image Data: The Image Data field contains 1024 characters, unless 2384 the payload being sent is the last one (end of file) 2386 8.2 Image Data Response 2388 The Image Data Response acknowledges the Image Data Request. 2390 An Image Data Responses is sent in response to an Image Data Request. 2391 Its purpose is to acknowledge the receipt of the Image Data Request 2392 packet. 2394 The Image Data Response carries no message elements. 2396 No action is necessary on receipt. 2398 8.3 Reset Request 2400 The Reset Request is used to cause an WTP to reboot. 2402 Reset Requests are sent by an AC to cause an WTP to reinitialize its 2403 operation. 2405 The Reset Request carries no message elements. 2407 When an WTP receives a Reset Request it will respond with a Reset 2408 Response and then reinitialize itself. 2410 8.4 Reset Response 2412 The Reset Response acknowledges the Reset Request. 2414 Reset Responses are sent by an WTP after receiving a Reset Request. 2416 The Reset Response carries no message elements. Its purpose is to 2417 acknowledge the receipt of the Reset Request. 2419 When an AC receives a Reset Response it is notified that the WTP will 2420 now reinitialize its operation. 2422 8.5 WTP Event Request 2424 WTP Event Request is used by an WTP to send an information to its AC. 2425 These types of events may be periodical, or some asynchronous event 2426 on the WTP. For instance, an WTP collects statistics and uses the 2427 WTP Event Request to transmit this information to the AC. 2429 When an AC receives a WTP Event Request it will respond with a WTP 2430 Event Request. 2432 The WTP Event Request message MUST contain one of the following 2433 message element described in the next subsections, or a message 2434 element that is defined for a specific technology. 2436 8.5.1 Decryption Error Report 2438 The Decryption Error Report message element value is used by the WTP 2439 to inform the AC of decryption errors that have occured since the 2440 last report. 2442 0 1 2 2443 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2445 | Radio ID |Num Of Entries | Mobile MAC Address | 2446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2447 | Mobile MAC Address[] | 2448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 Type: 39 for Decryption Error Report 2451 Length: >= 8 2452 Radio ID: The Radio Identifier, typically refers to some interface 2453 index on the WTP 2454 Num Of Entries: An 8-bit unsigned integer indicating the number of 2455 mobile MAC addresses. 2456 Mobile MAC Address: An array of mobile station MAC addresses that 2457 have caused decryption errors. 2459 8.5.2 Duplicate IP Address 2461 The Duplicate IP Address message element is used by an WTP to inform 2462 an AC that it has detected another host using the same IP address it 2463 is currently using. 2465 0 1 2 3 2466 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2468 | IP Address | 2469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2470 | MAC Address | 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | MAC Address | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2475 Type: 77 for Duplicate IP Address 2476 Length: 10 2477 IP Address: The IP Address currently used by the WTP. 2478 MAC Address: The MAC Address of the offending device. 2480 8.6 WTP Event Response 2482 WTP Event Response acknowledges the WTP Event Request. 2484 WTP Event Response are sent by an AC after receiving a WTP Event 2485 Request. 2487 The WTP Event Response carries no message elements. 2489 8.7 Data Transfer Request 2491 The Data Transfer Request is used to upload debug information from 2492 the WTP to the AC. 2494 Data Transfer Requests are sent by the WTP to the AC when it 2495 determines that it has important information to send to the AC. For 2496 instance, if the WTP detects that its previous reboot was caused by a 2497 system crash, it would want to send the crash file to the AC. The 2498 remote debugger function in the WTP also uses the data transfer 2499 request in order to send console output to the AC for debugging 2500 purposes. 2502 When an AC receives an Data Transfer Request it will respond with a 2503 Data Transfer Response. The AC may log the information received, as 2504 it sees fit. 2506 The data transfer request message MUST contain ONE of the following 2507 message element described in the next subsection. 2509 8.7.1 Data Transfer Mode 2511 The Data Transfer Mode message element is used by the AC to request 2512 information from the WTP for debugging purposes. 2514 0 2515 0 1 2 3 4 5 6 7 2516 +-+-+-+-+-+-+-+-+ 2517 | Data Type | 2518 +-+-+-+-+-+-+-+-+ 2520 Type: 52 for Data Transfer Mode 2521 Length: 1 2522 Data Type: An 8-bit value the type of information being requested. 2523 The following values are supported: 2524 1 - WTP Crash Data 2525 2 - WTP Memory Dump 2527 8.7.2 Data Transfer Data 2529 The Data Transfer Data message element is used by the WTP to provide 2530 information to the AC for debugging purposes. 2532 0 1 2 3 2533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2535 | Data Type | Data Length | Data .... 2536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2538 Type: 53 for Data Transfer Data 2539 Length: >= 3 2540 Data Type: An 8-bit value the type of information being sent. The 2541 following values are supported: 2542 1 - WTP Crash Data 2543 2 - WTP Memory Dump 2544 Data Length: Length of data field. 2545 Data: Debug information. 2547 8.8 Data Transfer Response 2549 The Data Transfer Response acknowledges the Data Transfer Request. 2551 An Data Transfer Response is sent in response to an Data Transfer 2552 Request. Its purpose is to acknowledge the receipt of the Data 2553 Transfer Request packet. 2555 The Data Transfer Response carries no message elements. 2557 Upon receipt of a Data Transfer Response, the WTP transmits more 2558 information, if any is available. 2560 9. Mobile Session Management 2562 Messages in this section are used by the AC to create, modify or 2563 delete mobile station session state on the WTPs. 2565 9.1 Mobile Config Request 2567 The Mobile Config Request message is used to create, modify or delete 2568 mobile session state on an WTP. The message is sent by the AC to the 2569 WTP, and may contain one or more message elements. The message 2570 elements for this LWAPP control message include information that is 2571 generally highly technology specific. Therefore, please refer to the 2572 appropriate binding section or document for the definitions of the 2573 messages elements that may be used in this control message. 2575 This section defines the format of the Delete Mobile message element, 2576 since it does not contain any technology specific information. 2578 9.1.1 Delete Mobile 2580 The Delete Mobile message element is used by the AC to inform an WTP 2581 that it should no longer provide service to a particular mobile 2582 station. The WTP must terminate service immediately upon receiving 2583 this message element. 2585 The transmission of a Delete Mobile message element could occur for 2586 various reasons, including for administrative reaons, as a result of 2587 the fact that the mobile has roamed to another WTP, etc. 2589 Once access has been terminated for a given station, any future 2590 packets received from the mobile must result in a deauthenticate 2591 message, as specified in [6]. 2593 0 1 2 3 2594 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2596 | Radio ID | MAC Address | 2597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2598 | MAC Address | 2599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 Type: 30 for Delete Mobile 2602 Length: 7 2603 Radio ID: An 8-bit value representing the radio 2604 MAC Address: The mobile station's MAC Address 2606 9.2 Mobile Config Response 2608 The Mobile Configuration Response is used to acknowledge a previously 2609 received Mobile Configuration Request, and includes a Result Code 2610 message element which indicates whether an error occured on the WTP. 2612 This message requires no special processing, and is only used to 2613 acknowledge the Mobile Configuration Request. 2615 The data transfer request message MUST contain the message elements 2616 described in the next subsection. 2618 9.2.1 Result Code 2620 The Result Code message element is defined in section Section 6.2.1. 2622 10. Session Key Generation 2624 Note: This version only defines a certificate based mechanism to 2625 secure traffic between the WTP and the AC. A shared-secret mechanism 2626 will be added in a future version. 2628 10.1 Securing WTP-AC communications 2630 While it is generally straightforward to produce network 2631 installations in which the communications medium between the WTP and 2632 AC is not accessible to the casual user (e.g. these LAN segments are 2633 isolated, no RJ45 or other access ports exist between the WTP and the 2634 AC), this will not always be the case. Furthermore, a determined 2635 attacker may resort to various more sophisticated monitoring and/or 2636 access techniques, thereby compromising the integrity of this 2637 connection. 2639 In general, a certain level of threat on the local (wired) LAN is 2640 expected and accepted in most computing environments. That is, it is 2641 expected that in order to provide users with an acceptable level of 2642 service and maintain reasonable productivity levels, a certain amount 2643 of risk must be tolerated. It is generally believed that a certain 2644 perimeter is maintained around such LANs, that an attacker must have 2645 access to the building(s) in which such LANs exist, and that they 2646 must be able to "plug in" to the LAN in order to access the network. 2648 With these things in mind, we can begin to assess the general 2649 security requirements for AC-WTP communications. While an in-depth 2650 security analysis of threats and risks to these communication is 2651 beyond the scope of this document, some discussion of the motivation 2652 for various security-related design choices is useful. The 2653 assumptions driving the security design thus far include the 2654 following: 2655 o WTP-AC communications take place over a wired connection which may 2656 be accessible to a sophisticated attacker 2657 o access to this connection is not trivial for an outsider (i.e. 2658 someone who does not "belong" in the building) to access 2659 o if authentication and/or privacy of end to end traffic for which 2660 the WTP and AC are intermediaries is required, this may be 2661 provided via IPsec [11]. 2662 o privacy and authentication for at least some WTP-AC control 2663 traffic is required (e.g. WEP keys for user sessions, passed from 2664 AC to WTP) 2665 o the AC can be trusted to generate strong cryptographic keys 2667 AC-WTP traffic can be considered to consist of two types: data 2668 traffic (e.g. to or from an end user), and control traffic which is 2669 strictly between the AC and WTP. Since data traffic may be secured 2670 using IPsec (or some other end-to-end security mechanism), we confine 2671 our solution to control traffic. The resulting security consists of 2672 two components: an authenticated key exchange, and control traffic 2673 security encapsulation. The security encapsulation is accomplished 2674 using AES CCM, described in [3]. This encapsulation provides for 2675 strong AES-based authentication and encryption. The exchange of 2676 cryptographic keys used for CCM is described below. 2678 10.2 LWAPP Frame Encryption 2680 While, the LWAPP protocol uses AES-CCM to encrypt control traffic, it 2681 is important to note that not all control frames are encrypted. The 2682 LWAPP discovery and join phase are not encrypted. The Discovery 2683 messages are sent in the clear since there does not exist a security 2684 association between the WTP and the AC during the discovery phase. 2685 The Join phase is used to negotiate symmetric session keys (see 2686 Section 6.2.4). 2688 Once the join phase has been successfully completed, the LWAPP state 2689 machine Figure 3 will move to the Configure state, at which time all 2690 LWAPP control frames are encrypted using AES-CCM. 2692 Encryption of a control message begins at the Message Element field, 2693 meaning tha the Msg Type, Seq Num, Msg Element Length and Session ID 2694 fields are left intact (see Section 4.2.1). 2696 The AES-CCM 12 byte authentication data is appended to the end of the 2697 message. The authentication data is calculated from the start of the 2698 LWAPP packet, and includes the complete LWAPP header. 2700 The AES-CCM block cipher protocol requires an initialization vector. 2701 The IV is initialized on both the WTP and the AC to the Session ID, 2702 and the IV is monotonically increased for every packet transmitted. 2703 Note that the IV is implicit, and is not transmitted in the LWAPP 2704 header, and therefore an LWAPP device MUST keep track of both 2705 bi-directional IVs. The IV is 13 bytes long, and the first byte is 2706 set to zero, while the remaining four bytes are set to the 2707 monotonically increasing 32 bit counter previously mentioned. 2709 10.3 Authenticated Key Exchange 2711 The AC and WTP accomplish mutual authentication and a cryptographic 2712 key exchange in a single round trip using the Join Request and 2713 Response pair (see Section 6.1). 2715 The following notations are used throughout this section: 2717 o Kpriv - the private key of a public-private key pair 2718 o Kpub - the public key of the pair 2719 o KeyMaterial - clear text LWAPP session key, randomly generated on 2720 the AC when it receives the Join Request 2721 o SessionID - randomly generated LWAPP session identifier, provided 2722 by the WTP in the Join Request 2723 o M - a clear-text message 2724 o C - a cipher-text message. 2725 o S - signed cipher-text message. 2726 o PKCS1(z) - the PKCS#1 encapsulation of z 2727 o E-x{Kpriv, M} - encryption of M using X's private key 2728 o E-x{Kpub, M} - encryption of M using X's public key 2729 o S-x{M} - a digital signature over M produced by X 2730 o V-x{S-x, M} - verification of X's digital signature over M 2731 o D-x{Kpriv, C} - decryption of C using X's private key 2732 o D-x{Kpub, C} - decryption of C using X's public key 2733 o Certificate-AC - AC's Certificate 2734 o Certificate-WTP - WTP's Certificate 2736 Note that the constant 'x' is used in the above notations to 2737 represent one of the parties in the LWAPP exchange. For instance, if 2738 the WTP must encrypt some text, it would use its own private key, and 2739 therefore the notation "E-wtp{Kpriv, M}" would be used. 2741 The following text describes the exchange between the WTP and the AC 2742 that creates a session key, which is used to secure LWAPP control 2743 messages. 2744 o The WTP adds the Certificate message element (see Section 6.1.6) 2745 with the contents set to Certificate-WTP in the Join Request. 2746 o The WTP adds the Session ID message element (see Section 6.1.7) 2747 with the contents set to a randomly generated session identifer 2748 (see [4]) in the Join Request. The WTP MUST save the Session ID 2749 in order to validate the Join Response. 2750 o Upon receiving the Join Request, the AC verifies Certificate-WTP, 2751 encoded in the Certificate message element. 2752 o The AC Randomly generates 4 random session keys. The four keys 2753 are (in order) a 16 byte Transmission AES key, a 16 byte Reception 2754 AES Key, a 20 byte HMAC-SHA1 Transmission Key and a 20 byte 2755 HMAC-SHA1 Reception Key. These four keys are concatenated into a 2756 single bit string, which is now referred to as KeyMaterial. The 2757 directionality of these keys is from the standpoint of the AC. 2758 o The AC encrypts the key into cipher-text (C), using E-wtp{Kpub , 2759 PKCS1(KeyMaterial)}. This encrypts the PKCS#1-encoded key 2760 material with the public key of the WTP, so that only the WTP can 2761 decrypt it and determine the session keys. 2763 o The AC compute a signature (S), using S-ac{SessionID|C} of the 2764 cipher-text; this computes the AC's digital signature over the 2765 concatenation of the 32-bit SessionID and the encrypted key 2766 material (C), and can be verified using the public key of the AC, 2767 "proving" that the AC produced this; this forms the basis of trust 2768 for the WTP with respect to the source of the session keys 2769 (KeyMaterial). 2770 o AC creates the Join Response, and includes two message elements. 2771 Certificate-AC in included in the Certificate message element. 2772 The Session Key message element is added, with the Session ID 2773 encoded and the signed cipher-text (S) included in the Session Key 2774 field. The resulting Join Response is sent to the WTP. 2775 o WTP verifies that SessionID in the Join Response's Session Key 2776 message element matches an outstanding request 2777 o WTP verifies authenticity of Certificate-AC in the Join Response's 2778 Certificate message element. 2779 o WTP computes V-ac{S, SessionID|C}, where S is the Session Key 2780 field of the Session Key message element, verifying the AC's 2781 signature over the session identifier and the encrypted key 2782 material 2783 o WTP computes PKCS1(KeyMaterial) = D-ac{Kpriv , C}, decrypting the 2784 session keys using its private key; since these were encrypted 2785 with the WTP's public key, only the WTP can successfully decrypt 2786 this. 2787 KeyMaterial is divided into the four transmission and reception 2788 AES and HMAC-SHA1 session keys. From this point on, all control 2789 protocol payloads between the WTP and AC are encrypted and 2790 authenticated. The related payloads are described in the sections 2791 above. 2793 10.4 Refreshing Cryptographic Keys 2795 Since AC-WTP associations will tend to be relatively long-lived, it 2796 is sensible to periodically refresh the encryption and authentication 2797 keys; this is referred to as "rekeying". When the key lifetime 2798 reaches 95% of the configured value, identified in the KeyLifetime 2799 timer (see Section 12), the rekeying will proceed as follows: 2800 o WTP generates a fresh random Session identier value and encodes it 2801 within the Key Update Request's Session ID message elemenet. The 2802 new session identifier is saved on the WTP in order to verify the 2803 Key Update Response. The Key Update Request is sent to the AC. 2804 o When the AC receives Key Update Request with the SessionID message 2805 element, the AC randomly generates 4 random session keys. The 2806 four keys are (in order) a 16 byte Transmission AES key, a 16 byte 2807 Reception AES Key, a 20 byte HMAC-SHA1 Transmission Key and a 20 2808 byte HMAC-SHA1 Reception Key. These four keys are concatenated 2809 into a single bit string, which is now referred to as KeyMaterial. 2810 The directionality of these keys is from the standpoint of the AC. 2812 o The AC encrypts the key into cipher-text (C), using E-wtp{Kpub , 2813 PKCS1(KeyMaterial)}. This encrypts the PKCS#1-encoded key 2814 material with the public key of the WTP, so that only the WTP can 2815 decrypt it and determine the session keys. 2816 o The AC compute a signature (S), using S-ac{SessionID|C} of the 2817 cipher-text; this computes the AC's digital signature over the 2818 concatenation of the 32-bit SessionID and the encrypted key 2819 material (C), and can be verified using the public key of the AC, 2820 "proving" that the AC produced this; this forms the basis of trust 2821 for the WTP with respect to the source of the session keys 2822 (KeyMaterial). 2823 o AC then sends a Key Update Response message to the WTP using the 2824 old session key. Once the message has been sent, the new session 2825 key is plumbed into the AC's crypto engine. 2826 o WTP verifies that SessionID in the Key Update Response's Session 2827 Key message element matches an outstanding request 2828 o WTP computes V-ac{S, SessionID|C}, where S is the Session Key 2829 field of the Session Key message element, verifying the AC's 2830 signature over the session identifier and the encrypted key 2831 material 2832 o WTP computes PKCS1(KeyMaterial) = D-ac{Kpriv , C}, decrypting the 2833 session keys using its private key; since these were encrypted 2834 with the WTP's public key, only the WTP can successfully decrypt 2835 this. 2836 o KeyMaterial is divided into the four transmission and reception 2837 AES and HMAC-SHA1 session keys. From this point on, all control 2838 protocol payloads between the WTP and AC are encrypted and 2839 authenticated using the new session keys. The related payloads 2840 are described in the sections above. 2842 If WTP does not receive the Key Update Response by the time the 2843 ResponseTimeout timer expires (see Section 12), the WTP MUST delete 2844 the new and old session information, and reset the state machine to 2845 the Idle state. 2847 11. IEEE 802.11 Binding 2849 11.1 Transport specific bindings 2851 All LWAPP transports have the following IEEE 802.11 specific 2852 bindings: 2854 11.1.1 Status and WLANS field 2856 The interpretation of this 16 bit field depends on the direction of 2857 transmission of the packet. Refer to the figure in Section 2858 Section 3.1. 2860 Status 2862 When an LWAPP packet is transmitted from an WTP to an AC, this field 2863 is called the status field and indicates radio resource information 2864 associated with the frame. When the message is an LWAPP control 2865 message this field is transmitted as zero. 2867 The status field is divided into the signal strength and signal to 2868 noise ratio with which an IEEE 802.11 frame was received, encoded in 2869 the following manner: 2871 0 1 2872 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2874 | RSSI | SNR | 2875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2877 RSSI 2879 RSSI is a signed, 8-bit value. It is the received signal strength 2880 indication, in dBm. 2882 SNR 2884 SNR is a signed, 8-bit value. It is the signal to noise ratio of the 2885 received IEEE 802.11 frame, in dB. 2887 WLANS field 2889 When an LWAPP data message is transmitted from an AC to an WTP, this 2890 16 bit field indicates on which WLANs the encapsulated IEEE 802.11 2891 frame is to be transmitted. For unicast packets, this field is not 2892 used by the WTP. For broadcast or multicast packets, the WTP might 2893 require this information if it provides encryption services. 2895 Given that a single broadcast or multicast packet might need to be 2896 sent to multiple wireless LANs (presumably each with a different 2897 broadcast key), this field is defined as a bit field. A bit set 2898 indicates a WLAN ID (see Section Section 11.4.1.1) which will be sent 2899 the data. The WLANS field is encoded in the following manner: 2901 0 1 2902 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2904 | WLAN ID(s) | 2905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2907 11.2 Data Message bindings 2909 There are no LWAPP Data Message bindings for IEEE 802.11. 2911 11.3 Control Message bindings 2913 The IEEE 802.11 binding has the following Control Message 2914 definitions. 2916 11.3.1 Mobile Config Request 2918 This section contains the 802.11 specific message elements that are 2919 used with the Mobile Config Request. 2921 11.3.1.1 Add Mobile 2923 The Add Mobile Request is used by the AC to inform an WTP that it 2924 should forward traffic from a particular mobile station. The add 2925 mobile request may also include security parameters that must be 2926 enforced by the WTP for the particular mobile. 2928 When the AC sends an Add Mobile Request, it includes any security 2929 parameters that may be required. An AC that wishes to update a 2930 mobile's policy on an WTP may be done by simply sending a new Add 2931 Mobile message element. 2933 When an WTP receives an Add Mobile message element, it must first 2934 override any existing state it may have for the mobile station in 2935 question. The latest Add Mobile overrides any previously received 2936 messages. If the Add Mobile message element's EAP Only bit is set, 2937 the WTP MUST drop all 802.11 packets that do not contain EAP packets. 2938 Note that when EAP Only is set, the Encryption Policy field MAY have 2939 additional values, and therefore it is possible to inform an WTP to 2940 only accept encrypted EAP packets. Once the mobile station has 2941 successfully completed EAP authentication, the AC must send a new Add 2942 Mobile message element to push the session key down to the WTP as 2943 well as to remove the EAP Only restriction. 2945 If the QoS field is set, the WTP MUST observe and provide policing of 2946 the 802.11e priority tag to ensure that it does not exceed the value 2947 provided by the AC. 2949 0 1 2 3 2950 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2952 | Radio ID | Association ID | MAC Address | 2953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2954 | MAC Address | 2955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2956 | MAC Address |E| Encryption Policy | 2957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2958 |Encrypt Policy | Session Key... | 2959 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 | Pairwise TSC... | 2961 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2962 | Pairwise RSC... | 2963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2964 | Capabilities | WLAN ID | WME Mode | 2965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2966 | 802.11e Mode | Qos | Supported Rates | 2967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2968 | Supported Rates | 2969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2971 Type: 29 for Add Mobile 2972 Length: 36 2973 Radio ID: An 8-bit value representing the radio 2974 Association ID: A 16-bit value specifying the 802.11 Association 2975 Identifier 2976 MAC Address: The mobile station's MAC Address 2977 E: The one bit field is set by the AR to inform the WTP that is MUST 2978 NOT accept any 802.11 data frames, other than 802.1X frames. This 2979 is the equivalent of the WTP's 802.1X port for the mobile station 2980 to be in the closed state. When set, the WTP MUST drop any 2981 non-802.1X packets it receives from the mobile station. 2982 Encryption Policy: The policy field informs the WTP how to handle 2983 packets from/to the mobile station. The following values are 2984 supported: 2985 0 - Encrypt WEP 104: All packets to/from the mobile station must 2986 be encrypted using standard 104 bit WEP. 2988 1 - Clear Text: All packets to/from the mobile station do not 2989 require any additional crypto processing by the WTP. 2990 2 - Encrypt WEP 40: All packets to/from the mobile station must 2991 be encrypted using standard 40 bit WEP. 2992 3 - Encrypt WEP 128: All packets to/from the mobile station must 2993 be encrypted using standard 128 bit WEP. 2994 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 2995 must be encrypted using 128 bit AES CCMP [7] 2996 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 2997 be encrypted using TKIP and authenticated using Michael [12] 2998 Session Key: A 32 octet session key the WTP is to use when 2999 encrypting traffic to or decrypting traffic from the mobile 3000 station. The type of key is determined based on the Encryption 3001 Policy field. 3002 Pairwise TSC: The TSC to use for unicast packets transmitted to the 3003 mobile. 3004 Pairwise RSC: The RSC to use for unicast packets received from the 3005 mobile. 3006 Capabilities: A 16-bit field containing the 802.11 capabilities to 3007 use with the mobile. 3008 WLAN ID: An 8-bit value specifying the WLAN Identifier 3009 WME Mode: A 8-bit boolean used to identify whether the station is 3010 WME capable. 3011 802.11e Mode: A 8-bit boolean used to identify whether the station 3012 is 802.11e capable. 3013 QoS: An 8-bit value specifying the QoS policy to enforce for the 3014 station. The following values are supported: PRC: TO CHECK 3015 0 - Silver (Best Effort) 3016 1 - Gold (Video) 3017 2 - Platinum (Voice) 3018 3 - Bronze (Background) 3019 Supported Rates: The supported rates to be used with the mobile 3020 station. 3022 11.3.1.2 IEEE 802.11 Mobile Session Key 3024 The Mobile Session Key Payload message element is sent when the AC 3025 determines that encryption of a mobile station must be performed in 3026 the WTP. This message element MUST NOT be present without the Add 3027 Mobile (see Section 11.3.1.1) message element, and MUST NOT be sent 3028 if the WTP had not specifically advertised support for the requested 3029 encryption scheme (see ???). 3031 0 1 2 3 3032 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3034 | MAC Address | 3035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3036 | MAC Address | Encryption Policy | 3037 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3038 | Encryption Policy | Session Key... | 3039 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3041 Type: 105 for IEEE 802.11 Mobile Session Key 3042 Length: >= 11 3043 MAC Address: The mobile station's MAC Address 3044 Encryption Policy: The policy field informs the WTP how to handle 3045 packets from/to the mobile station. The following values are 3046 supported: 3047 0 - Encrypt WEP 104: All packets to/from the mobile station must 3048 be encrypted using standard 104 bit WEP. 3049 1 - Clear Text: All packets to/from the mobile station do not 3050 require any additional crypto processing by the WTP. 3051 2 - Encrypt WEP 40: All packets to/from the mobile station must 3052 be encrypted using standard 40 bit WEP. 3053 3 - Encrypt WEP 128: All packets to/from the mobile station must 3054 be encrypted using standard 128 bit WEP. 3055 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3056 must be encrypted using 128 bit AES CCMP [7] 3057 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3058 be encrypted using TKIP and authenticated using Michael [12] 3059 Session Key: The session key the WTP is to use when encrypting 3060 traffic to/from the mobile station. 3062 11.3.1.3 QoS Profile 3064 The QoS Profile Payload message element contains the maximum 802.11e 3065 priority tag that may be used by the station. Any packets received 3066 that exceeds the value encoded in this message element must either be 3067 dropped or tagged using the maximum value permitted by to the user. 3068 The priority tag must be between zero (0) and seven (7). 3070 0 1 2 3 3071 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3073 | MAC Address | 3074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3075 | MAC Address | 802.1P Precedence Tag | 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3078 Type: TBD for IEEE 802.11 QOS Profile 3079 Length: 12 3080 MAC Address: The mobile station's MAC Address 3081 802.1P Precedence Tag: The maximum 802.1P precedence value that the 3082 WTP will allow in the TID field in the extended 802.11e QOS Data 3083 header. 3085 11.3.1.4 IEEE 802.11 Update Mobile QoS 3087 The Update Mobile QoS message element is used to change the Quality 3088 of Service policy on the WTP for a given mobile station. 3090 0 1 2 3 3091 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 | Radio ID | Association ID | MAC Address | 3094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3095 | MAC Address | 3096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3097 | MAC Address | QoS Profile | Vlan Identifier | 3098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3099 | DSCP Tag | 802.1P Tag | 3100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3102 Type: 106 for IEEE 802.11 Update Mobile QoS 3103 Length: 14 3104 Radio ID: The Radio Identifier, typically refers to some interface 3105 index on the WTP 3106 Association ID: The 802.11 Association Identifier. 3107 MAC Address: The mobile station's MAC Address. 3108 QoS Profile: An 8-bit value specifying the QoS policy to enforce for 3109 the station. The following values are supported: 3110 0 - Silver (Best Effort) 3111 1 - Gold (Video) 3112 2 - Platinum (Voice) 3113 3 - Bronze (Background) 3114 VLAN Identifier: PRC. 3115 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 3116 802.1P Tag: The 802.1P precedence value to use if packets are to be 3117 802.1P tagged. 3119 11.3.2 WTP Event Request 3121 This section contains the 802.11 specific message elements that are 3122 used with the WTP Event Request message. 3124 11.3.2.1 IEEE 802.11 Statistics 3126 The statistics message element is sent by the WTP to transmit it's 3127 current statistics. The value contains the following fields. 3129 0 1 2 3 3130 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3132 | Radio ID | Tx Fragment Count | 3133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3134 |Tx Fragment Cnt| Multicast Tx Count | 3135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3136 | Mcast Tx Cnt | Failed Count | 3137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3138 | Failed Count | Retry Count | 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | Retry Count | Multiple Retry Count | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 |Multi Retry Cnt| Frame Duplicate Count | 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 | Frame Dup Cnt | RTS Success Count | 3145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3146 |RTS Success Cnt| RTS Failure Count | 3147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3148 |RTS Failure Cnt| ACK Failure Count | 3149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 |ACK Failure Cnt| Rx Fragment Count | 3151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 |Rx Fragment Cnt| Multicast RX Count | 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3154 | Mcast Rx Cnt | FCS Error Count | 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | FCS Error Cnt| Tx Frame Count | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | Tx Frame Cnt | Decryption Errors | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 |Decryption Errs| 3161 +-+-+-+-+-+-+-+-+ 3163 Type: 38 for Statistics 3164 Length: 57 3165 Radio ID: An 8-bit value representing the radio. 3166 Tx Fragment Count: A 32-bit value representing the number of 3167 fragmented frames transmitted. 3168 Multicast Tx Count: A 32-bit value representing the number of 3169 multicast frames transmitted. 3171 Failed Count: A 32-bit value representing the transmit excessive 3172 retries. 3173 Retry Count: A 32-bit value representing the number of transmit 3174 retries. 3175 Multiple Retry Count: A 32-bit value representing the number of 3176 transmits that required more than one retry. 3177 Frame Duplicate Count: A 32-bit value representing the duplicate 3178 frames received. 3179 RTS Success Count: A 32-bit value representing the number of 3180 successfully transmitted Ready To Send (RTS). 3181 RTS Failure Count: A 32-bit value representing the failed 3182 transmitted RTS. 3183 ACK Failure Count: A 32-bit value representing the number of failed 3184 acknowledgements. 3185 Rx Fragment Count: A 32-bit value representing the number of 3186 fragmented frames received. 3187 Multicast RX Count: A 32-bit value representing the number of 3188 multicast frames received. 3189 FCS Error Count: A 32-bit value representing the number of FCS 3190 failures. 3191 Decryption Errors: A 32-bit value representing the number of 3192 Decryption errors that occured on the WTP. Note that this field 3193 is only valid in cases where the WTP provides 3194 encryption/decryption services. 3196 11.4 802.11 Control Messages 3198 This section will define LWAPP Control Messages that are specific to 3199 the IEEE 802.11 binding. 3201 11.4.1 IEEE 802.11 WLAN Config Request 3203 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 3204 WTP in order to change services provided by the WTP. This control 3205 message is used to either create, update or delete a WLAN on the WTP. 3207 The IEEE 802.11 WLAN Configuration Request is sent as a result of 3208 either some manual admistrative process (e.g., deleting a WLAN), or 3209 automatically to create a WLAN on an WTP. When sent automatically to 3210 create a WLAN, this control message is sent after the LWAPP 3211 Configuration Request message has been received by the WTP. 3213 Upon receiving this control message, the WTP will modify the 3214 necessary services, and transmit an IEEE 802.11 WLAN Configuration 3215 Response. 3217 An WTP MAY provide service for more than one WLAN, therefore every 3218 WLAN is identified through a numerical index. For instance, an WTP 3219 that is capable of supporting up to 16 SSIDs, could accept up to 16 3220 IEEE 802.11 WLAN Configuration Request messages that include the Add 3221 WLAN message element. 3223 Since the index is the primary identifier for a WLAN, an AC SHOULD 3224 attempt to ensure that the same WLAN is identified through the same 3225 index number on all of its WTPs. An AC that does not follow this 3226 approach MUST find some other means of maintaining a WLAN Identifier 3227 to SSID mapping table. 3229 The following subsections define the message elements that are value 3230 for this LWAPP operation. Only one message MUST be present. 3232 11.4.1.1 IEEE 802.11 Add WLAN 3234 The Add WLAN message element is used by the AC to define a wireless 3235 LAN on the WTP. The value contains the following format: 3237 0 1 2 3 3238 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3240 | Radio ID | WLAN Capability | WLAN ID | 3241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3242 | Encryption Policy | 3243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 | Key ... | 3245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3246 | Key Index | Shared Key | WPA Data Len |WPA IE Data ...| 3247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3248 | RSN Data Len |RSN IE Data ...| Reserved .... | 3249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3250 | WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...| 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 | QoS | Auth Type |Broadcast SSID | Reserved... | 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 | SSID ... | 3255 +-+-+-+-+-+-+-+-+ 3257 Type: 7 for IEEE 802.11 Add WLAN 3258 Length: >= 298 3259 Radio ID: An 8-bit value representing the radio. 3260 WLAN Capability: A 16-bit value containing the capabilities to be 3261 advertised by the WTP within the Probe and Beacon messages. 3262 WLAN ID: A 16-bit value specifying the WLAN Identifier. 3263 Encryption Policy: A 32-bit value specifying the encryption scheme 3264 to apply to traffic to and from the mobile station. 3266 The following values are supported: 3267 0 - Encrypt WEP 104: All packets to/from the mobile station must 3268 be encrypted using standard 104 bit WEP. 3269 1 - Clear Text: All packets to/from the mobile station do not 3270 require any additional crypto processing by the WTP. 3271 2 - Encrypt WEP 40: All packets to/from the mobile station must 3272 be encrypted using standard 40 bit WEP. 3273 3 - Encrypt WEP 128: All packets to/from the mobile station must 3274 be encrypted using standard 128 bit WEP. 3275 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3276 must be encrypted using 128 bit AES CCMP [7] 3277 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3278 be encrypted using TKIP and authenticated using Michael [12] 3279 6 - Encrypt CKIP: All packets to/from the mobile station must be 3280 encrypted using Cisco TKIP. 3281 Key: A 32 byte Session Key to use with the encryption policy. 3282 Key-Index: The Key Index associated with the key. 3283 Shared Key: A 1 byte boolean that specifies whether the key included 3284 in the Key field is a shared WEP key. 3285 WPA Data Len: Length of the WPA IE. 3286 WPA IE: A 32 byte field containing the WPA Information Element. 3287 RSN Data Len: Length of the RSN IE. 3288 RSN IE: A 64 byte field containing the RSN Information Element. 3289 Reserved: A 49 byte reserved field, which MUST be set to zero (0). 3290 WME Data Len: Length of the WME IE. 3291 WME IE: A 32 byte field containing the WME Information Element. 3292 DOT11E Data Len: Length of the 802.11e IE. 3293 DOT11E IE: A 32 byte field containing the 802.11e Information 3294 Element. 3295 QOS: An 8-bit value specifying the QoS policy to enforce for the 3296 station. 3297 The following values are supported: 3298 0 - Silver (Best Effort) 3299 1 - Gold (Video) 3300 2 - Platinum (Voice) 3301 3 - Bronze (Background) 3302 Auth Type: An 8-bit value specifying the station's authentication 3303 type. 3304 The following values are supported: 3305 0 - Open System 3306 1 - WEP Shared Key 3307 2 - WPA/WPA2 802.1X 3308 3 - WPA/WPA2 PSK 3309 Broadcast SSID: A boolean indicating whether the SSID is to be 3310 broadcast by the WTP. 3312 Reserved: A 40 byte reserved field. 3313 SSID: The SSID attribute is the service set identifier that will be 3314 advertised by the WTP for this WLAN. 3316 11.4.1.2 IEEE 802.11 Delete WLAN 3318 The delete WLAN message element is used to inform the WTP that a 3319 previously created WLAN is to be deleted. The value contains the 3320 following fields: 3322 0 1 2 3323 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3325 | Radio ID | WLAN ID | 3326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 Type: 28 for IEEE 802.11 Delete WLAN 3329 Length: 3 3330 Radio ID: An 8-bit value representing the radio 3331 WLAN ID: A 16-bit value specifying the WLAN Identifier 3333 11.4.1.3 IEEE 802.11 Update WLAN 3335 The Update WLAN message element is used by the AC to define a 3336 wireless LAN on the WTP. The value contains the following format: 3338 0 1 2 3 3339 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3341 | Radio ID | WLAN ID |Encrypt Policy | 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Encryption Policy | Key... | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | Key ... | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Key Index | Shared Key | WLAN Capability | 3348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 Type: 34 for IEEE 802.11 Update WLAN 3351 Length: 43 3352 Radio ID: An 8-bit value representing the radio. 3353 WLAN ID: A 16-bit value specifying the WLAN Identifier. 3354 Encryption Policy: A 32-bit value specifying the encryption scheme 3355 to apply to traffic to and from the mobile station. 3356 The following values are supported: 3358 0 - Encrypt WEP 104: All packets to/from the mobile station must 3359 be encrypted using standard 104 bit WEP. 3360 1 - Clear Text: All packets to/from the mobile station do not 3361 require any additional crypto processing by the WTP. 3362 2 - Encrypt WEP 40: All packets to/from the mobile station must 3363 be encrypted using standard 40 bit WEP. 3364 3 - Encrypt WEP 128: All packets to/from the mobile station must 3365 be encrypted using standard 128 bit WEP. 3366 4 - Encrypt AES-CCMP 128: All packets to/from the mobile station 3367 must be encrypted using 128 bit AES CCMP [7] 3368 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 3369 be encrypted using TKIP and authenticated using Michael [12] 3370 6 - Encrypt CKIP: All packets to/from the mobile station must be 3371 encrypted using Cisco TKIP. 3372 Key: A 32 byte Session Key to use with the encryption policy. 3373 Key-Index: The Key Index associated with the key. 3374 Shared Key: A 1 byte boolean that specifies whether the key included 3375 in the Key field is a shared WEP key. 3376 WLAN Capability: A 16-bit value containing the capabilities to be 3377 advertised by the WTP within the Probe and Beacon messages. 3379 11.4.2 IEEE 802.11 WLAN Config Response 3381 The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the 3382 AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN 3383 Configuration Request. 3385 This LWAPP control message does not include any message elements. 3387 11.4.3 IEEE 802.11 WTP Event 3389 The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order 3390 to report asynchronous events to the AC. There is no reply message 3391 expected from the AC, except that the message is acknowledged via the 3392 reliable transport. 3394 When the AC receives the IEEE 802.11 WTP Event, it will take whatever 3395 action is necessary, depending upon the message elements present in 3396 the message. 3398 The IEEE 802.11 WTP Event message MUST contain one of the following 3399 message element described in the next subsections. 3401 11.4.3.1 IEEE 802.11 MIC Countermeasures 3403 The MIC Countermeasures message element is sent by the WTP to the AC 3404 to indicate the occurrence of a MIC failure. 3406 0 1 2 3 3407 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3409 | Radio ID | WLAN ID | MAC Address | 3410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3411 | MAC Address | 3412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3414 Type: 61 for IEEE 802.11 MIC Countermeasures 3415 Length: 8 3416 Radio ID: The Radio Identifier, typically refers to some interface 3417 index on the WTP. 3418 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 3419 on which the MIC failure occurred. 3420 MAC Address: The MAC Address of the mobile station that caused the 3421 MIC failure. 3423 11.4.3.2 IEEE 802.11 WTP Radio Fail Alarm Indication 3425 The WTP Radio Fail Alarm Indication message element is sent by the 3426 WTP to the AC when it detects a radio failure. 3428 0 1 2 3 3429 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3431 | Radio ID | Type | Status | Pad | 3432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 Type: 95 for WTP Radio Fail Alarm Indication 3435 Length: 4 3436 Radio ID: The Radio Identifier, typically refers to some interface 3437 index on the WTP 3438 Type: The type of radio failure detected. The following values are 3439 supported: 3440 1 - Receiver 3441 2 - Transmitter 3442 Status: An 8-bit boolean indicating whether the radio failure is 3443 being reported or cleared. 3444 Pad: Reserved field MUST be set to zero (0). 3446 11.5 Message Element Bindings 3448 The IEEE 802.11 Message Element binding has the following 3449 definitions: 3451 Conf Conf Conf Add 3452 Req Resp Upd Mobile 3454 IEEE 802.11 WTP WLAN Radio Configuration X X X 3455 IEEE 802.11 Rate Set X X 3456 IEEE 802.11 Multi-domain Capability X X X 3457 IEEE 802.11 MAC Operation X X X 3458 IEEE 802.11 Tx Power X X X 3459 IEEE 802.11 Tx Power Level X 3460 IEEE 802.11 Direct Sequence Control X X X 3461 IEEE 802.11 OFDM Control X X X 3462 IEEE 802.11 Supported Rates X X 3463 IEEE 802.11 Antenna X X X 3464 IEEE 802.11 CFP Status X X 3465 IEEE 802.11 Broadcast Probe Mode X X 3466 IEEE 802.11 WTP Mode and Type X? X 3467 IEEE 802.11 WTP Quality of Service X X 3468 IEEE 802.11 MIC Error Report From Mobile X 3469 IEEE 802.11 Update Mobile QoS X 3470 IEEE 802.11 Mobile Session Key X 3471 VOIP STUFF 3473 11.5.1 IEEE 802.11 WTP WLAN Radio Configuration 3475 The WTP WLAN radio configuration is used by the AC to configure a 3476 Radio on the WTP. The message element value contains the following 3477 Fields: 3479 0 1 2 3 3480 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3482 | Radio ID | Reserved | Occupancy Limit | 3483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3484 | CFP Per | CFP Maximum Duration | BSS ID | 3485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3486 | BSS ID | 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3488 | BSS ID | Beacon Period | DTIM Per | 3489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 | Country String | 3491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3493 Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration 3494 Length: 20 3495 Radio ID: An 8-bit value representing the radio to configure. 3496 Reserved: MUST be set to zero 3497 Occupancy Limit: This attribute indicates the maximum amount of 3498 time, in TU, that a point coordinator MAY control the usage of the 3499 wireless medium without relinquishing control for long enough to 3500 allow at least one instance of DCF access to the medium. The 3501 default value of this attribute SHOULD be 100, and the maximum 3502 value SHOULD be 1000. 3503 CFP Period: The attribute describes the number of DTIM intervals 3504 between the start of CFPs. 3505 CFP Maximum Duration: The attribute describes the maximum duration 3506 of the CFP in TU that MAY be generated by the PCF. 3507 BSSID: The WLAN Radio's base MAC Address. For WTPs that support 3508 more than a single WLAN, the value of the WLAN Identifier is added 3509 to the last octet of the BSSID. Therefore, a WTP that supports 16 3510 WLANs MUST have 16 MAC Addresses reserved for it, and the last 3511 nibble is used to represent the WLAN ID. 3512 Beacon Period: This attribute specifies the number of TU that a 3513 station uses for scheduling Beacon transmissions. This value is 3514 transmitted in Beacon and Probe Response frames. 3515 DTIM Period: This attribute specifies the number of beacon intervals 3516 that elapses between transmission of Beacons frames containing a 3517 TIM element whose DTIM Count field is 0. This value is 3518 transmitted in the DTIM Period field of Beacon frames. 3519 Country Code: This attribute identifies the country in which the 3520 station is operating. The first two octets of this string is the 3521 two character country code as described in document ISO/IEC 3166- 3522 1. The third octet MUST be one of the following: 3523 1. an ASCII space character, if the regulations under which the 3524 station is operating encompass all environments in the 3525 country, 3526 2. an ASCII 'O' character, if the regulations under which the 3527 station is operating are for an outdoor environment only, or 3528 3. an ASCII 'I' character, if the regulations under which the 3529 station is operating are for an indoor environment only 3531 11.5.2 IEEE 802.11 Rate Set 3533 The rate set message element value is sent by the AC and contains the 3534 supported operational rates. It contains the following fields. 3536 0 1 2 3 3537 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3539 | Radio ID | Rate Set | 3540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3542 Type: 16 for IEEE 802.11 Rate Set 3543 Length: 4 3544 Radio ID: An 8-bit value representing the radio to configure. 3545 Rate Set: The AC generates the Rate Set that the WTP is to include 3546 in it's Beacon and Probe messages. 3548 11.5.3 IEEE 802.11 Multi-domain Capability 3550 The multi-domain capability message element is used by the AC to 3551 inform the WTP of regulatory limits. The value contains the 3552 following fields. 3554 0 1 2 3 3555 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3557 | Radio ID | Reserved | First Channel # | 3558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3559 | Number of Channels | Max Tx Power Level | 3560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3562 Type: 10 for IEEE 802.11 Multi-Domain Capability 3563 Length: 8 3564 Radio ID: An 8-bit value representing the radio to configure. 3565 Reserved: MUST be set to zero 3566 First Channnel #: This attribute indicates the value of the lowest 3567 channel number in the subband for the associated domain country 3568 string. 3569 Number of Channels: This attribute indicates the value of the total 3570 number of channels allowed in the subband for the associated 3571 domain country string. 3572 Max Tx Power Level: This attribute indicates the maximum transmit 3573 power, in dBm, allowed in the subband for the associated domain 3574 country string. 3576 11.5.4 IEEE 802.11 MAC Operation 3578 The MAC operation message element is sent by the AC to set the 802.11 3579 MAC parameters on the WTP. The value contains the following fields. 3581 0 1 2 3 3582 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3584 | Radio ID | Reserved | RTS Threshold | 3585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3586 | Short Retry | Long Retry | Fragmentation Threshold | 3587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3588 | Tx MSDU Lifetime | 3589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3590 | Rx MSDU Lifetime | 3591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3593 Type: 11 for IEEE 802.11 MAC Operation 3594 Length: 16 3595 Radio ID: An 8-bit value representing the radio to configure. 3596 Reserved: MUST be set to zero 3597 RTS Threshold: This attribute indicates the number of octets in an 3598 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 3599 RTS/CTS handshake MUST be performed at the beginning of any frame 3600 exchange sequence where the MPDU is of type Data or Management, 3601 the MPDU has an individual address in the Address1 field, and the 3602 length of the MPDU is greater than this threshold. Setting this 3603 attribute to be larger than the maximum MSDU size MUST have the 3604 effect of turning off the RTS/CTS handshake for frames of Data or 3605 Management type transmitted by this STA. Setting this attribute 3606 to zero MUST have the effect of turning on the RTS/CTS handshake 3607 for all frames of Data or Management type transmitted by this STA. 3608 The default value of this attribute MUST be 2347. 3609 Short Retry: This attribute indicates the maximum number of 3610 transmission attempts of a frame, the length of which is less than 3611 or equal to RTSThreshold, that MUST be made before a failure 3612 condition is indicated. The default value of this attribute MUST 3613 be 7. 3614 Long Retry: This attribute indicates the maximum number of 3615 transmission attempts of a frame, the length of which is greater 3616 than dot11RTSThreshold, that MUST be made before a failure 3617 condition is indicated. The default value of this attribute MUST 3618 be 4. 3619 Fragmentation Threshold: This attribute specifies the current 3620 maximum size, in octets, of the MPDU that MAY be delivered to the 3621 PHY. An MSDU MUST be broken into fragments if its size exceeds 3622 the value of this attribute after adding MAC headers and trailers. 3623 An MSDU or MMPDU MUST be fragmented when the resulting frame has 3624 an individual address in the Address1 field, and the length of the 3625 frame is larger than this threshold. The default value for this 3626 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 3627 attached PHY and MUST never exceed the lesser of 2346 or the 3628 aMPDUMaxLength of the attached PHY. The value of this attribute 3629 MUST never be less than 256. 3630 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 3631 after the initial transmission of an MSDU, after which further 3632 attempts to transmit the MSDU MUST be terminated. The default 3633 value of this attribute MUST be 512. 3634 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 3635 after the initial reception of a fragmented MMPDU or MSDU, after 3636 which further attempts to reassemble the MMPDU or MSDU MUST be 3637 terminated. The default value MUST be 512. 3639 11.5.5 IEEE 802.11 Tx Power 3641 The Tx power message element value is bi-directional. When sent by 3642 the WTP, it contains the current power level of the radio in 3643 question. When sent by the AC, it contains the power level the WTP 3644 MUST adhere to. 3646 0 1 2 3 3647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3649 | Radio ID | Reserved | Current Tx Power | 3650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3652 Type: 12 for IEEE 802.11 Tx Power 3653 Length: 4 3654 Radio ID: An 8-bit value representing the radio to configure. 3655 Reserved: MUST be set to zero 3656 Current Tx Power: This attribute contains the transmit output power 3657 in mW. 3659 11.5.6 IEEE 802.11 Tx Power Level 3661 The Tx power level message element is sent by the WTP and contains 3662 the different power levels supported. The value contains the 3663 following fields. 3665 0 1 2 3 3666 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3668 | Radio ID | Num Levels | Power Level [n] | 3669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3671 Type: 13 for IEEE 802.11 Tx Power Level 3672 Length: >= 4 3673 Radio ID: An 8-bit value representing the radio to configure. 3674 Num Levels: The number of power level attributes. 3675 Power Level: Each power level fields contains a supported power 3676 level, in mW. 3678 11.5.7 IEEE 802.11 Direct Sequence Control 3680 The direct sequence control message element is a bi-directional 3681 element. When sent by the WTP, it contains the current state. When 3682 sent by the AC, the WTP MUST adhere to the values. This element is 3683 only used for 802.11b radios. The value has the following fields. 3685 0 1 2 3 3686 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3688 | Radio ID | Reserved | Current Chan | Current CCA | 3689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3690 | Energy Detect Threshold | 3691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3693 Type: 14 for IEEE 802.11 Direct Sequence Control 3694 Length: 8 3695 Radio ID: An 8-bit value representing the radio to configure. 3696 Reserved: MUST be set to zero 3697 Current Channel: This attribute contains the current operating 3698 frequency channel of the DSSS PHY. 3699 Current CCA: The current CCA method in operation. Valid values are: 3700 1 - energy detect only (edonly) 3701 2 - carrier sense only (csonly) 3702 4 - carrier sense and energy detect (edandcs) 3703 8 - carrier sense with timer (cswithtimer) 3704 16 - high rate carrier sense and energy detect (hrcsanded) 3705 Energy Detect Threshold: The current Energy Detect Threshold being 3706 used by the DSSS PHY. 3708 11.5.8 IEEE 802.11 OFDM Control 3710 The OFDM control message element is a bi-directional element. When 3711 sent by the WTP, it contains the current state. When sent by the AC, 3712 the WTP MUST adhere to the values. This element is only used for 3713 802.11a radios. The value contains the following fields: 3715 0 1 2 3 3716 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 | Radio ID | Reserved | Current Chan | Band Support | 3719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3720 | TI Threshold | 3721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3723 Type: 15 for IEEE 802.11 OFDM Control 3724 Length: 8 3725 Radio ID: An 8-bit value representing the radio to configure. 3726 Reserved: MUST be set to zero 3727 Current Channel: This attribute contains the current operating 3728 frequency channel of the OFDM PHY. 3729 Band Supported: The capability of the OFDM PHY implementation to 3730 operate in the three U-NII bands. Coded as an integer value of a 3731 three bit field as follows: 3733 capable of operating in the lower (5.15-5.25 GHz) U-NII band 3734 capable of operating in the middle (5.25-5.35 GHz) U-NII band 3735 capable of operating in the upper (5.725-5.825 GHz) U-NII band 3736 For example, for an implementation capable of operating in the 3737 lower and mid bands this attribute would take the value 3738 TI Threshold: The Threshold being used to detect a busy medium 3739 (frequency). CCA MUST report a busy medium upon detecting the 3740 RSSI above this threshold. 3742 11.5.9 IEEE 802.11 Antenna 3744 The antenna message element is communicated by the WTP to the AC to 3745 provide information on the antennas available. The AC MAY use this 3746 element to reconfigure the WTP's antennas. The value contains the 3747 following fields: 3749 0 1 2 3 3750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3752 | Radio ID | Diversity | Combiner | Antenna Cnt | 3753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3754 | Antenna Selection [0..N] | 3755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3757 Type: 41 for IEEE 802.11 Antenna 3758 Length: >= 8 3759 Radio ID: An 8-bit value representing the radio to configure. 3760 Diversity: An 8-bit value specifying whether the antenna is to 3761 provide receive diversity. The following values are supported: 3762 0 - Disabled 3763 1 - Enabled (may only be true if the antenna can be used as a 3764 receive antenna) 3765 Combiner: An 8-bit value specifying the combiner selection. The 3766 following values are supported: 3767 1 - Sectorized (Left) 3768 2 - Sectorized (Right) 3769 3 - Omni 3770 4 - Mimo 3771 Antenna Count: An 8-bit value specifying the number of Antenna 3772 Selection fields. 3773 Antenna Selection: One 8-bit antenna configuration value per antenna 3774 in the WTP. The following values are supported: 3775 1 - Internal Antenna 3776 2 - External Antenna 3778 11.5.10 IEEE 802.11 Supported Rates 3780 The supported rates message element is sent by the WTP to indicate 3781 the rates that it supports. The value contains the following fields. 3783 0 1 2 3 3784 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3786 | Radio ID | Supported Rates | 3787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3789 Type: 16 for IEEE 802.11 Supported Rates 3790 Length: 4 3791 Radio ID: An 8-bit value representing the radio. 3792 Supported Rates: The WTP includes the Supported Rates that it's 3793 hardware supports. The format is identical to the Rate Set 3794 message element. 3796 11.5.11 IEEE 802.11 CFP Status 3798 The CFP Status message element is sent to provide the CF Polling 3799 configuration. 3801 0 1 3802 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3804 | Radio ID | Status | 3805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3807 Type: 48 for IEEE 802.11 CFP Status 3808 Length: 2 3809 Radio ID: The Radio Identifier, typically refers to some interface 3810 index on the WTP 3811 Status: An 8-bit boolean containing the status of the CF Polling 3812 feature. 3814 11.5.12 IEEE 802.11 WTP Mode and Type 3816 The WTP Mode and Type message element is used to configure an WTP to 3817 operate in a specific mode. 3819 0 1 3820 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3822 | Mode | Type | 3823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3825 Type: 54 for IEEE 802.11 WTP Mode and Type 3826 Length: 2 3827 Mode: An 8-bit value the type of information being sent. The 3828 following values are supported: 3829 0 - Normal Mode 3830 1 - Monitoring Mode 3831 2 - REAP Mode 3832 3 - Rogue Detector Mode 3833 4 - Sniffer Mode 3834 Type: The type field is not currently used. 3836 11.5.13 IEEE 802.11 Broadcast Probe Mode 3838 The Broadcast Probe Mode message element indicates whether an WTP 3839 will respond to NULL SSID probe requests. Since broadcast NULL 3840 probes are not sent to a specific BSSID, the WTP cannot know which 3841 SSID the sending station is querying. Therefore, this behavior must 3842 be global to the WTP. 3844 0 3845 0 1 2 3 4 5 6 7 3846 +-+-+-+-+-+-+-+-+ 3847 | Status | 3848 +-+-+-+-+-+-+-+-+ 3850 Type: 51 for IEEE 802.11 Broadcast Probe Mode 3851 Length: 1 3852 Status: An 8-bit boolean indicating the status of whether an WTP 3853 shall response to a NULL SSID probe request. 3855 11.5.14 IEEE 802.11 WTP Quality of Service 3857 The WTP Quality of Service message element value is sent by the AC to 3858 the WTP to communicate quality of service configuration information. 3860 0 1 3861 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 3862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3863 | Radio ID | Tag Packets | 3864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3866 Type: 57 for IEEE 802.11 WTP Quality of Service 3867 Length: 12 3868 Radio ID: The Radio Identifier, typically refers to some interface 3869 index on the WTP 3870 Tag Packets: An 8-bit unsigned boolean indicating whether LWAPP 3871 packets should be tagged with for QoS purposes. The following 3872 values are currently supported: 3874 0 - Untagged 3875 1 - 802.1P 3876 2 - DSCP 3877 Immediately following the above header is the following data 3878 structure. This data structure will be repeated five times; once 3879 for every QoS profile. The order of the QoS profiles are Uranium, 3880 Platinum, Gold, Silver and Bronze. 3882 0 1 2 3 3883 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3885 | Queue Depth | CWMin | CWMax | 3886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3887 | CWMax | AIFS | CBR | 3888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3889 | Dot1P Tag | DSCP Tag | 3890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3892 Queue Depth: The number of packets that can be on the specific QoS 3893 transmit queue at any given time. 3894 CWMin: The Contention Window minimum value for the QoS transmit 3895 queue. 3896 CWMax: The Contention Window maximum value for the QoS transmit 3897 queue. 3898 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 3899 transmit queue. 3900 CBR: The CBR value to observe for the QoS transmit queue. 3901 Dot1P Tag: The 802.1P precedence value to use if packets are to be 3902 802.1P tagged. 3903 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 3905 11.5.15 IEEE 802.11 MIC Error Report From Mobile 3907 The MIC Error Report From Mobile message element is sent by an AC to 3908 an WTP when it receives a MIC failure notification, via the Error bit 3909 in the EAPOL-Key frame. 3911 0 1 2 3 3912 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3914 | Client MAC Address | 3915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3916 | Client MAC Address | BSSID | 3917 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3918 | BSSID | 3919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3920 | Radio ID | WLAN ID | 3921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3923 Type: 79 for IEEE 802.11 MIC Error Report From Mobile 3924 Length: 14 3925 Client MAC Address: The Client MAC Address of the station reporting 3926 the MIC failure. 3927 BSSID: The BSSID on which the MIC failure is being reported. 3928 Radio ID: The Radio Identifier, typically refers to some interface 3929 index on the WTP 3930 WLAN ID: The WLAN ID on which the MIC failure is being reported. 3932 11.6 IEEE 802.11 Message Element Values 3934 This section lists IEEE 802.11 specific values for any generic LWAPP 3935 message elements which include fields whose values are technology 3936 specific. 3938 IEEE 802.11 uses the following values: 3939 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 3940 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 3941 [12]. 3943 12. LWAPP Protocol Timers 3945 An WTP or AC that implements LWAPP discovery MUST implement the 3946 following timers. 3948 12.1 MaxDiscoveryInterval 3950 The maximum time allowed between sending discovery requests from the 3951 interface, in seconds. Must be no less than 2 seconds and no greater 3952 than 180 seconds. 3954 Default: 20 seconds. 3956 12.2 SilentInterval 3958 The minimum time, in seconds, an WTP MUST wait after failing to 3959 receive any responses to its discovery requests, before it MAY again 3960 send discovery requests. 3962 Default: 30 3964 12.3 NeighborDeadInterval 3966 The minimum time, in seconds, an WTP MUST wait without having 3967 received Echo Responses to its Echo Requests, before the destination 3968 for the Echo Request may be considered dead. Must be no less than 3969 2*EchoInterval seconds and no greater than 240 seconds. 3971 Default: 60 3973 12.4 EchoInterval 3975 The minimum time, in seconds, between sending echo requests to the AC 3976 with which the WTP has joined. 3978 Default: 30 3980 12.5 DiscoveryInterval 3982 The minimum time, in seconds, that an WTP MUST wait after receiving a 3983 Discovery Response, before sending a join request. 3985 Default: 5 3987 12.6 RetransmitInterval 3989 The minimum time, in seconds, which a non-acknowledged LWAPP packet 3990 will be retransmitted. 3992 Default: 3 3994 12.7 ResponseTimeout 3996 The minimum time, in seconds, which an LWAPP Request message must be 3997 responded to. 3999 Default: 1 4001 12.8 KeyLifetime 4003 The maximum time, in seconds, which an LWAPP session key is valid. 4005 Default: 86400 4007 13. LWAPP Protocol Variables 4009 An WTP or AC that implements LWAPP discovery MUST allow for the 4010 following variables to be configured by system management; default 4011 values are specified so as to make it unnecessary to configure any of 4012 these variables in many cases. 4014 13.1 MaxDiscoveries 4016 The maximum number of discovery requests that will be sent after an 4017 WTP boots. 4019 Default: 10 4021 13.2 DiscoveryCount 4023 The number of discoveries transmitted by a WTP to a single AC. This 4024 is a monotonically increasing counter. 4026 13.3 RetransmitCount 4028 The number of retransmissions for a given LWAPP packet. This is a 4029 monotonically increasing counter. 4031 13.4 MaxRetransmit 4033 The maximum number of retransmissions for a given LWAPP packet before 4034 the link layer considers the peer dead. 4036 Default: 5 4038 14. Security Considerations 4040 LWAPP uses public key cryptography to ensure trust between the WTP 4041 and the AC. During the Join phase, the AC generates a session key, 4042 which is used to secure future control messages. The WTP does not 4043 participate in the key generation, but public key cryptography is 4044 used to authenticate the resulting key material. A secured delivery 4045 mechanism to place the certificate in the devices is required. In 4046 order to maximize session key security, the WTP and AC periodically 4047 update the session keys, which are encrypted using public key 4048 cryptography. This ensures that a potentially previously compromised 4049 key does not affect the security of communication with new key 4050 material. 4052 [TODO: talk about why keying material is not reused] 4054 One question that periodically arises is why the Join Request is not 4055 signed. It was felt that requiring a signature in this messages was 4056 not required for the following reasons: 4057 1. The Join Request is replayable, so requiring a signature doesn't 4058 provide much protection unless the switches keep track of all 4059 previous Join Requests from a given WTP. One alternative would 4060 have been to add a timestamp, but this introduces clock 4061 synchronization issues. Further, authentication occurs in a later 4062 exchange anyway (see point 2 below). 4063 2. The WTP is authenticated by virtue of the fact that it can 4064 decrypt and then use the session keys (encrypted with its own 4065 public key), so it *is* ultimately authenticated. 4066 3. A signed Join Request provides a potential Denial of Service 4067 attack on the AC, which would have to authenticate each 4068 (potentially malicious) message. 4070 15. IANA Considerations 4072 This document requires no action by IANA. 4074 16. IPR Statement 4076 The IETF has been notified of intellectual property rights claimed in 4077 regard to some or all of the specification contained in this 4078 document. For more information consult the online list of claimed 4079 rights. 4081 Please refer to http://www.ietf.org/ietf/IPR for more information. 4083 17. References 4085 17.1 Normative References 4087 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 4088 Levels", BCP 14, RFC 2119, March 1997. 4090 [2] National Institute of Standards and Technology, "Advanced 4091 Encryption Standard (AES)", FIPS PUB 197, November 2001, 4092 . 4094 [3] Whiting, D., Housley, R. and N. Ferguson, "Counter with CBC-MAC 4095 (CCM)", RFC 3610, September 2003. 4097 [4] Eastlake, D., Crocker, S. and J. Schiller, "Randomness 4098 Recommendations for Security", RFC 1750, December 1994. 4100 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 4101 RFC 3753, June 2004. 4103 [6] "Information technology - Telecommunications and information 4104 exchange between systems - Local and metropolitan area networks 4105 - Specific requirements - Part 11: Wireless LAN Medium Access 4106 Control (MAC) and Physical Layer (PHY) specifications", 4107 IEEE Standard 802.11, 1999, 4108 . 4110 [7] "Information technology - Telecommunications and information 4111 exchange between systems - Local and metropolitan area networks 4112 - Specific requirements - Part 11: Wireless LAN Medium Access 4113 Control (MAC) and Physical Layer (PHY) specifications Amendment 4114 6: Medium Access Control (MAC) Security Enhancements", 4115 IEEE Standard 802.11i, July 2004, 4116 4117 . 4119 [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, July 4120 1982. 4122 17.2 Informational References 4124 [9] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an 4125 On-line Database", RFC 3232, January 2002. 4127 [10] Bradner, S., "The Internet Standards Process -- Revision 3", 4128 BCP 9, RFC 2026, October 1996. 4130 [11] Kent, S. and R. Atkinson, "Security Architecture for the 4131 Internet Protocol", RFC 2401, November 1998. 4133 [12] "WiFi Protected Access (WPA) rev 1.6", April 2003. 4135 Authors' Addresses 4137 Pat R. Calhoun 4138 Airespace 4139 110 Nortech Parkway 4140 San Jose, CA 95134 4142 Phone: +1 408-635-2000 4143 Email: pcalhoun@airespace.com 4145 Bob O'Hara 4146 Airespace 4147 110 Nortech Parkway 4148 San Jose, CA 95134 4150 Phone: +1 408-635-2025 4151 Email: bob@airespace.com 4153 Scott Kelly 4154 Facetime Communications 4155 1159 Triton Dr 4156 Foster City, CA 94404 4158 Phone: +1 650 572-5846 4159 Email: scott@hyperthought.com 4161 Rohit Suri 4162 Airespace 4163 110 Nortech Parkway 4164 San Jose, CA 95134 4166 Phone: +1 408-635-2026 4167 Email: rsuri@airespace.com 4168 Michael Glenn Williams 4169 Nokia, Inc. 4170 313 Fairchild Drive 4171 Mountain View, CA 94043 4173 Phone: +1 650-714-7758 4174 Email: Michael.G.Williams@Nokia.com 4176 Sue Hares 4177 Nexthop Technologies, Inc. 4178 825 Victors Way, Suite 100 4179 Ann Arbor, MI 48108 4181 Phone: +1 734 222 1610 4182 Email: shares@nexthop.com 4184 Intellectual Property Statement 4186 The IETF takes no position regarding the validity or scope of any 4187 Intellectual Property Rights or other rights that might be claimed to 4188 pertain to the implementation or use of the technology described in 4189 this document or the extent to which any license under such rights 4190 might or might not be available; nor does it represent that it has 4191 made any independent effort to identify any such rights. Information 4192 on the procedures with respect to rights in RFC documents can be 4193 found in BCP 78 and BCP 79. 4195 Copies of IPR disclosures made to the IETF Secretariat and any 4196 assurances of licenses to be made available, or the result of an 4197 attempt made to obtain a general license or permission for the use of 4198 such proprietary rights by implementers or users of this 4199 specification can be obtained from the IETF on-line IPR repository at 4200 http://www.ietf.org/ipr. 4202 The IETF invites any interested party to bring to its attention any 4203 copyrights, patents or patent applications, or other proprietary 4204 rights that may cover technology that may be required to implement 4205 this standard. Please address the information to the IETF at 4206 ietf-ipr@ietf.org. 4208 Disclaimer of Validity 4210 This document and the information contained herein are provided on an 4211 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4212 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4213 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4214 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4215 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4216 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4218 Copyright Statement 4220 Copyright (C) The Internet Society (2005). This document is subject 4221 to the rights, licenses and restrictions contained in BCP 78, and 4222 except as set forth therein, the authors retain all their rights. 4224 Acknowledgment 4226 Funding for the RFC Editor function is currently provided by the 4227 Internet Society.