idnits 2.17.1 draft-ohara-capwap-lwapp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 10 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 54 has weird spacing: '...rol and manag...' == Line 2572 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 (May 8, 2004) is 7265 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: '1' is defined on line 1878, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1888, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Unknown state RFC: RFC 815 (ref. '3') ** Obsolete normative reference: RFC 1750 (ref. '5') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3232 (ref. '6') -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' ** Obsolete normative reference: RFC 2401 (ref. '12') (Obsoleted by RFC 4301) Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 8 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: November 6, 2004 S. Kelly 5 R. Suri 6 Airespace 7 M. Williams 8 Nokia, Inc. 9 M. Vakulenko 10 Legra Systems, Inc. 11 May 8, 2004 13 Light Weight Access Point Protocol (LWAPP) 14 draft-ohara-capwap-lwapp-00 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 6, 2004. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). All Rights Reserved. 43 Abstract 45 Wireless Access Points are not strictly Layer 2 bridges. Such 46 devices may be much simpler, barely more than radios. They may also 47 perform some additional or higher layer functions such as those 48 performed by switches and routers. For example, in IEEE 802.11 49 networks, Access Points can function as Network Access Servers. This 50 is one reason Access Points may have IP addresses and function as IP 51 devices. 53 This document describes the Light Weight Access Point Protocol which 54 supports control and management of wireless Access Points. Bindings 55 for each wireless system specify the protocol as applied to that 56 technology. An IEEE 802.11 binding is provided in this draft. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 1.1 Conventions used in this document . . . . . . . . . . . . 6 62 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 63 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 3.1 Wireless Binding Definition . . . . . . . . . . . . . . . 9 65 3.2 LWAPP State Machine Definition . . . . . . . . . . . . . . 9 66 4. LWAPP Packet Definitions . . . . . . . . . . . . . . . . . . . 10 67 4.1 LWAPP Data Messages . . . . . . . . . . . . . . . . . . . 10 68 4.2 LWAPP Control Messages Overview . . . . . . . . . . . . . 10 69 4.2.1 Control Message Format . . . . . . . . . . . . . . . . 10 70 4.3 Control Channel Management . . . . . . . . . . . . . . . . 12 71 4.3.1 Discovery Requests . . . . . . . . . . . . . . . . . . 12 72 4.3.2 Discovery Reply . . . . . . . . . . . . . . . . . . . 13 73 4.3.3 Join Request . . . . . . . . . . . . . . . . . . . . . 14 74 4.3.4 Join Reply . . . . . . . . . . . . . . . . . . . . . . 15 75 4.3.5 Echo Request . . . . . . . . . . . . . . . . . . . . . 15 76 4.3.6 Echo Response . . . . . . . . . . . . . . . . . . . . 16 77 4.3.7 Key Update Request . . . . . . . . . . . . . . . . . . 16 78 4.3.8 Key Update Response . . . . . . . . . . . . . . . . . 17 79 4.3.9 Key Update Trigger . . . . . . . . . . . . . . . . . . 17 80 4.4 AR Configuration . . . . . . . . . . . . . . . . . . . . . 18 81 4.4.1 Configure Request . . . . . . . . . . . . . . . . . . 18 82 4.4.2 Configure Response . . . . . . . . . . . . . . . . . . 18 83 4.4.3 Configuration Update Request . . . . . . . . . . . . . 19 84 4.4.4 Configuration Update Response . . . . . . . . . . . . 20 85 4.4.5 Statistics Report . . . . . . . . . . . . . . . . . . 20 86 4.4.6 Statistics Response . . . . . . . . . . . . . . . . . 21 87 4.4.7 Reset Request . . . . . . . . . . . . . . . . . . . . 21 88 4.4.8 Reset Response . . . . . . . . . . . . . . . . . . . . 21 89 4.5 Mobile Session Management . . . . . . . . . . . . . . . . 22 90 4.5.1 Add Mobile Request . . . . . . . . . . . . . . . . . . 22 91 4.5.2 Add Mobile Response . . . . . . . . . . . . . . . . . 23 92 4.5.3 Delete Mobile Request . . . . . . . . . . . . . . . . 23 93 4.5.4 Delete Mobile Response . . . . . . . . . . . . . . . . 24 94 4.6 Firmware Management . . . . . . . . . . . . . . . . . . . 24 95 4.6.1 Image Data Request . . . . . . . . . . . . . . . . . . 24 96 4.6.2 Image Data Response . . . . . . . . . . . . . . . . . 25 97 5. LWAPP Message Elements . . . . . . . . . . . . . . . . . . . . 26 98 5.1 Result Code . . . . . . . . . . . . . . . . . . . . . . . 27 99 5.2 AR Address . . . . . . . . . . . . . . . . . . . . . . . . 27 100 5.3 AP Descriptor . . . . . . . . . . . . . . . . . . . . . . 27 101 5.4 AP Name . . . . . . . . . . . . . . . . . . . . . . . . . 28 102 5.5 AR Descriptor . . . . . . . . . . . . . . . . . . . . . . 28 103 5.6 Binding AP WLAN Radio Configuration . . . . . . . . . . . 29 104 5.7 Binding Rate Set . . . . . . . . . . . . . . . . . . . . . 29 105 5.8 Binding Multi-domain Capability . . . . . . . . . . . . . 29 106 5.9 Binding MAC Operation . . . . . . . . . . . . . . . . . . 29 107 5.10 Binding Tx Power Level . . . . . . . . . . . . . . . . . . 29 108 5.11 Binding Direct Sequence Control . . . . . . . . . . . . . 30 109 5.12 Binding OFDM Control . . . . . . . . . . . . . . . . . . . 30 110 5.13 Binding Supported Rates . . . . . . . . . . . . . . . . . 30 111 5.14 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 5.15 Administrative State . . . . . . . . . . . . . . . . . . . 30 113 5.16 Delete WLAN . . . . . . . . . . . . . . . . . . . . . . . 30 114 5.17 AR Name . . . . . . . . . . . . . . . . . . . . . . . . . 31 115 5.18 Image Download . . . . . . . . . . . . . . . . . . . . . . 31 116 5.19 Image Data . . . . . . . . . . . . . . . . . . . . . . . . 31 117 5.20 Location Data . . . . . . . . . . . . . . . . . . . . . . 31 118 5.21 Statistics Timer . . . . . . . . . . . . . . . . . . . . . 32 119 5.22 Binding Statistics . . . . . . . . . . . . . . . . . . . . 32 120 5.23 Binding Antenna . . . . . . . . . . . . . . . . . . . . . 32 121 5.24 Certificate . . . . . . . . . . . . . . . . . . . . . . . 32 122 5.25 Session ID . . . . . . . . . . . . . . . . . . . . . . . . 32 123 5.26 Session Key Payload . . . . . . . . . . . . . . . . . . . 32 124 5.27 Binding WLAN Create . . . . . . . . . . . . . . . . . . . 33 125 5.28 Vendor Specific Payload . . . . . . . . . . . . . . . . . 33 126 5.29 Binding Tx Power . . . . . . . . . . . . . . . . . . . . . 33 127 5.30 Add Mobile . . . . . . . . . . . . . . . . . . . . . . . . 34 128 5.31 Delete Mobile . . . . . . . . . . . . . . . . . . . . . . 34 129 5.32 Binding Mobile Session Key . . . . . . . . . . . . . . . . 35 130 6. LWAPP Configuration Variables . . . . . . . . . . . . . . . . 36 131 6.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . . 36 132 6.2 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . . 36 133 6.3 SilentInterval . . . . . . . . . . . . . . . . . . . . . . 36 134 6.4 NeighborDeadInterval . . . . . . . . . . . . . . . . . . . 36 135 6.5 EchoInterval . . . . . . . . . . . . . . . . . . . . . . . 36 136 6.6 DiscoveryInterval . . . . . . . . . . . . . . . . . . . . 37 137 7. LWAPP Transport Layers . . . . . . . . . . . . . . . . . . . . 38 138 7.1 Using IEEE 802.3 MAC as LWAPP transport . . . . . . . . . 38 139 7.1.1 Framing . . . . . . . . . . . . . . . . . . . . . . . 38 140 7.1.2 AR Discovery . . . . . . . . . . . . . . . . . . . . . 38 141 7.1.3 Fragmentation/Reassembly . . . . . . . . . . . . . . . 38 142 7.1.4 Multiplexing . . . . . . . . . . . . . . . . . . . . . 39 143 7.1.5 LWAPP Message Header format over IEEE 802.3 MAC 144 transport . . . . . . . . . . . . . . . . . . . . . . 39 145 7.2 Using IPv4/UDP as LWAPP transport . . . . . . . . . . . . 40 146 7.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . . 40 147 7.2.2 AR Discovery . . . . . . . . . . . . . . . . . . . . . 40 148 7.2.3 Fragmentation/Reassembly . . . . . . . . . . . . . . . 41 149 7.2.4 Multiplexing . . . . . . . . . . . . . . . . . . . . . 41 150 7.2.5 LWAPP Message Header format over IPv4/UDP transport . 42 151 8. Light Weight Access Protocol Constants . . . . . . . . . . . . 43 152 9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 153 10. IPR Statement . . . . . . . . . . . . . . . . . . . . . . . 45 154 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 155 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 156 A. Session Key Generation . . . . . . . . . . . . . . . . . . . . 48 157 A.1 Securing AP-AR communications . . . . . . . . . . . . . . 48 158 A.2 Authenticated Key Exchange . . . . . . . . . . . . . . . . 49 159 A.3 Refreshing Cryptographic Keys . . . . . . . . . . . . . . 50 160 B. Wireless Bindings . . . . . . . . . . . . . . . . . . . . . . 52 161 B.1 IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . 52 162 B.1.1 Transport specific bindings . . . . . . . . . . . . . 52 163 B.1.2 Data Message bindings . . . . . . . . . . . . . . . . 53 164 B.1.3 Control Message bindings . . . . . . . . . . . . . . . 53 165 B.1.4 Message Element Bindings . . . . . . . . . . . . . . . 55 166 Intellectual Property and Copyright Statements . . . . . . . . 66 168 1. Introduction 170 Unlike wired network elements, Access Points (AP) require a set of 171 management and control functions related to their primary task of 172 connecting the wireless and wired mediums. Today, protocols for 173 managing APs are either Layer 2 specific or non-existent (if the APs 174 are self-contained). The emergence of simple 802.11 APs that are 175 managed by a router or switch (also known as an Access Router, or AR) 176 suggests that having a standardized, interoperable protocol could 177 radically simplify the deployment and management of wireless 178 networks. In many cases the overall control and management functions 179 themselves are generic and could apply to any wireless Layer 2 180 protocol. Being independent of specific wireless Layer 2 181 technologies, such a protocol could better support interoperability 182 between Layer 2 devices and enable smoother intertechnology 183 handovers. 185 The details of how these functions would be implemented are dependent 186 on the particular Layer 2 wireless technology. Such a protocol would 187 need provisions for binding to specific technologies. 189 LWAPP assumes a network configuration that consists of multiple APs 190 communicating either via layer 2 (MAC) or layer 3 (IP) to an AR. The 191 AP can be considered as remote RF interfaces, being controlled by the 192 AR. The AR forwards all L2 frames it wants to transmit to an AP via 193 the LWAPP protocol. Packets from mobile nodes are forwarded by the 194 AP to the AR, also via this protocol. Figure 1illustrates this 195 arrangement as applied to an IEEE 802.11 binding. 197 +-+ 802.11frames +-+ 198 | |--------------------------------| | 199 | | +-+ | | 200 | |--------------| |---------------| | 201 | | 802.11 PHY/ | | LWAPP | | 202 | | MAC sublayer | | | | 203 +-+ +-+ +-+ 204 STA AP AR 206 Figure 1: LWAPP Architecture 208 Security is another aspect of Access Point management that is not 209 well served by existing solutions. Provisioning APs with security 210 credentials, and managing which APs are authorized to provide service 211 are today handled by proprietary solutions. Allowing these functions 212 to be performed from a centralized router or switch in an 213 interoperable fashion increases managability and allows network 214 operators to more tightly control their wireless network 215 infrastructure. 217 This document describes the Light Weight Access Point Protocol 218 (LWAPP), allowing an AR to manage a collection of APs. The protocol 219 is defined to be independent of Layer 2 technology, but an 802.11 220 binding is provided for use in growing 802.11 wireless LAN networks. 222 Goals 224 The following are goals for this protocol: 225 1. Centralization of the bridging, forwarding, authentication, 226 encryption and policy enforcement functions for a wireless 227 network. This will permit reduced cost and higher efficiency when 228 applying the capabilities of network processing silicon to the 229 wireless network, as it has already been applied to wired LANs. 230 2. Permit shifting of the higher level protocol processing burden 231 away from the AP. This leaves the computing resource of the AP to 232 the timing critical applications of wireless control and access. 233 This makes the most efficient use of the computing power available 234 in APs that are the subject of severe cost pressure. 235 3. Providing a generic encapsulation and transport mechanism, the 236 protocol may be applied to other access point protocols in the 237 future by adding the binding. 239 The LWAPP protocol concerns itself solely on the interface between 240 the AP and the AR. Inter-AR, or mobile to AR communication is 241 strictly outside the scope of this document. 243 1.1 Conventions used in this document 245 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 246 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 247 document are to be interpreted as described in RFC 2119 [7]. 249 2. Protocol Overview 251 LWAPP is a generic protocol defining how Access Points communicate 252 with Access Routers. Access Points and Access Routers may 253 communicate either by means of Layer 2 protocols or by means of a 254 routed IP network. 256 LWAPP messages and procedures defined in this document apply to both 257 types of transports unless specified otherwise. Transport 258 independence is achieved by defining formats for both MAC level and 259 IP level transport (see Section 7). Also defined are framing, 260 fragmentation/reassembly, and multiplexing services to LWAPP for each 261 transport type. 263 The Light Weight Access Protocol (LWAPP) begins with a discovery 264 phase. The APs send a Discovery Request frame, causing any Access 265 Router (AR) [8], receiving that frame to respond with a Discovery 266 Reply. From the Discovery Replies received, an AP will select an AR 267 with which to associate, using the Join Request and Join Reply. The 268 Join Request also provides an MTU discovery mechanism, to determine 269 whether there is support for the transport of large frames between 270 the AP and it's AR. If support for large frames is not present, the 271 LWAPP frames will be fragmented to the maximum length discovered to 272 be supported by the layer 2 network. 274 Once the AP and the AR have joined, a configuration exchange is 275 accomplished that will cause both devices to agree on version 276 information. During this exchange the AP may receive provisioning 277 settings. For the 802.11 binding, this information would typically 278 include a name (802.11 Service Set Identifier, SSID), and security 279 parameters, the data rates to be advertised as well as the radio 280 channel (channels, if the AP is capable of operating more than one 281 802.11 MAC and PHY simultaneously) to be used. Finally, the APs are 282 enabled for operation. 284 When the AP and AR have completed the version and provision exchange 285 and the AP is enabled, the LWAPP encapsulates the 802.11 frames sent 286 between them. LWAPP will fragment its packets, if the size of the 287 encapsulated 802.11 Data or Management frames causes the resultant 288 LWAPP packet to exceed the MTU supported between the AP and AR. 289 Fragmented LWAPP packets are reassembled to reconstitute the original 290 encapsulated payload. 292 In addition to the functions thus far described, LWAPP also provides 293 for the delivery of commands from the AR to the AP for the management 294 of devices that are communicating with the AP. This may include the 295 creation of local data structures in the AP for the managed devices 296 and the collection of statistical information about the communication 297 between the AP and the 802.11 devices. LWAPP provides the ability 298 for the AR to obtain any statistical information collected by the AP. 300 LWAPP also provides for a keep alive feature that preserves the 301 communication channel between the AP and AR. If the AR fails to 302 appear alive, the AP will try to discover a new AR to communicate 303 through. 305 3. Definitions 307 This Document uses terminology defined in [8] 309 3.1 Wireless Binding Definition 311 This draft standard specifies a protocol independent of a specific 312 wireless access point radio technology. Elements of the protocol are 313 designed to accommodate specific needs of each wireless technology in 314 a standard way. Implementation of this standard for a particular 315 wireless technology must follow the binding requirements defined for 316 that technology. 318 3.2 LWAPP State Machine Definition 320 The following state diagram represents the lifecycle of an AP-AR 321 session: 323 +------+(--------------------------------\ 324 | Idle | | 325 +------+ | 326 / +---------+--)+------------+ | 327 / | Run | | Key Update | | 328 v +---------+(--+------------+ | 329 +-----------+ ^ | | | 330 | Discovery | | v \----------->+-------+ 331 +-----------+ +-----------+ | Reset | 332 | ^ \ /--)| Configure | +-------+ 333 v | \ / +-----------+ ^ 334 +---------+ v / | 335 | Sulking | +------+ +------------+ | 336 +---------+ | Join |------------)| Image Data |--/ 337 +------+ +------------+ 339 Figure 2: LWAPP State Machine 341 Each of the states above correspond to an LWAPP control message type, 342 defined later in this document. 344 4. LWAPP Packet Definitions 346 This section contains the packet types and format. The LWAPP 347 protocol is designed to be transport agnostic by specifying packet 348 formats for both MAC frames and IP packets. An LWAPP packet consists 349 of an LWAPP Transport Layer packet header followed by an LWAPP 350 message. 352 Transport details can be found in Section 7. 354 4.1 LWAPP Data Messages 356 An LWAPP data message is a forwarded wireless frame. When forwarding 357 wireless frames, LWAPP is light weight and encapsulates the frames 358 only in the transport layer header. 360 4.2 LWAPP Control Messages Overview 362 The LWAPP Control protocol provides a control channel between the AP 363 and the AR. The control channel is the series of control messages 364 between the AP and AR, associated with a session ID and key. Control 365 is divided into the following distinct message types. Control 366 Channel, AR Configuration and Mobile Session Management MUST be 367 implemented. Firmware Management MAY be implemented. 368 Control Channel Management: Messages that fall within this 369 classification are used for the discovery of ARs by the APs as 370 well as the establishment and maintenance of an LWAPP control 371 channel. 372 AR Configuration: The AR Configuration messages are used by the AR to 373 push a specific configuration to the APs it has a control channel 374 with. Messages that deal with the retrieval of statistics from 375 the AP also fall in this category. 376 Mobile Session Management: Mobile session management messages are 377 used by the AR to push specific mobile policies to the AP. 378 Firmware Management: Messages in this category are used by the AR to 379 push a new firmware image down to the AP. 381 4.2.1 Control Message Format 383 All LWAPP control messages are sent encapsulated within the LWAPP 384 header (see for example Section 7.1.5 and Section 7.2.5) with the 385 following header values: 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Msg Type | Seq Num | Msg Element Length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Session ID | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Msg Element [0..N] | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 397 4.2.1.1 Message Type 399 The Message Type field identifies the function of the LWAPP control 400 message. The valid values for Message Type are the following: 402 Description Value 403 Discovery Request 1 404 Discovery Reply 2 405 Join Request 3 406 Join Reply 4 407 Configure Request 5 408 Configure Response 6 409 Configuration Update Request 7 410 Configuration Update Response 8 411 Statistics Report 9 412 Statistics Report Response 10 413 Reserved 11-16 414 Echo Request 17 415 Echo Response 18 416 Image Data Request 19 417 Image Data Response 20 418 Reset Request 21 419 Reset Response 22 420 Key Update Request 23 421 Key Update Response 24 422 Reserved 25-26 423 Key Update Trigger 27 425 4.2.1.2 Sequence Number 427 The Sequence Number Field is an identifier value to match request/ 428 response packet exchanges. When an LWAPP packet with a request 429 message type is received, the value of the sequence number field is 430 copied into the corresponding response packet. 432 4.2.1.3 Message Element Length 434 The Length field indicates the number of bytes following the Session 435 ID field. 437 4.2.1.4 Session ID 439 The Session ID is a 32-bit unsigned integer that is used to identify 440 the security context for encrypted exchanges between the AP and the 441 AR. 443 4.2.1.5 Message Element[0..N] 445 The message element(s) carry the information pertinent to each of the 446 control message types. The total length of the message elements is 447 indicated in the Message Element Length field. 449 The format of a message element uses the TLV format shown here: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type | Length | Value ... | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 Where Type (8 bit) identifies the character of the information 458 carried in the Value field and Length (16 bits) indicates the number 459 of bytes in the Value field. 461 The LWAPP message elements are defined in Section 5 463 4.3 Control Channel Management 465 The Control Channel Management messages are used by the AP and AR to 466 create and maintain a channel of communication on which various other 467 commands may be transmitted, such as configuration, firmware update, 468 etc. 470 4.3.1 Discovery Requests 472 The Discovery Request is used by the AP to automatically discovery 473 potential ARs available in the network. An AP must transmit this 474 command even if it has a statically configured AR, as it is a 475 required step in the LWAPP state machine. 477 4.3.1.1 Sending Discovery Requests 479 Discovery Requests MUST be sent by an AP in the Discover state after 480 waiting for a random delay less than MaxDiscoveryInterval, after an 481 AP first comes up or is (re)initialized. An AP MUST send no more 482 than a maximum of MaxDiscoveries discoveries, waiting for a random 483 delay less than MaxDiscoveryInterval between each successive 484 discovery. 486 This is to prevent an explosion of AP Discoveries. An example of 487 this occurring would be when many APs are powered on at the same 488 time. 490 Discovery requests MUST be sent by an AP when no echo responses are 491 received for NeighborDeadInterval and the AP returns to the discover 492 state. Discovery requests are sent after NeighborDeadInterval, they 493 MUST be sent after waiting for a random delay less than 494 MaxDiscoveryInterval. An AP MAY send up to a maximum of 495 MaxDiscoveries discoveries, waiting for a random delay less than 496 MaxDiscoveryInterval between each successive discovery. 498 If a discovery response is not received after sending the maximum 499 number of discovery requests, the AP enters the Sulking state and 500 MUST wait for an interval equal to SilentInterval before sending 501 further discovery requests. 503 The Discovery Request message may be sent as a unicast, broadcast or 504 multicast message. 506 TODO: Specify exponential backoff of discovery requests. 508 4.3.1.2 Format of a Discovery Request 510 The Discovery Request carries the following message elements: 512 AP 513 Radio Payload (one for each radio in the AP) 515 4.3.1.3 Receiving Discovery Requests 517 Upon receiving a discovery request, the AR will respond with a 518 Discovery Reply sent to the address in the source address of the 519 received discovery request. 521 4.3.2 Discovery Reply 523 The Discovery Reply is a mechanism by which an AR advertises its 524 services to requesting APs. 526 4.3.2.1 Sending Discovery Replies 528 Discovery Replies are sent by an AR after receiving a Discovery 529 Request. 531 4.3.2.2 Format of a Discovery Reply 533 The Discovery Reply carries the following message elements: 535 AR 536 AR Name 538 4.3.2.3 Receiving Discovery Replies 540 When an AP receives a Discovery Reply, it MUST wait for an interval 541 not less than DiscoveryInterval for receipt of additional discovery 542 replies. After the DiscoveryInterval elapses, the AP enters the 543 Joining state and will select one of the ARs that sent a discovery 544 reply and send a Join Request to that AR. 546 4.3.3 Join Request 548 The Join Request is used by an AP to inform an AR that it wishes to 549 provide services through it. 551 4.3.3.1 Sending Join Requests 553 Join Requests are sent by an AP in the Joining state after receiving 554 one or more Discovery Replies. The Join Request is also used as an 555 MTU discovery mechanism by the AP. The AP issues a Join Request with 556 a Test message element, bringing the total size of the message to 557 exceed MTU. 559 The initial Join Request is padded with the Test message element to 560 1596 bytes. If a Join Reply is received, the AP can forward frames 561 without requiring any fragmentation. If no Join Reply is received, 562 it issues a second Join Request padded with the Test payload to a 563 total of 1500 bytes. The AP continues to cycle from large (1596) to 564 small (1500) packets until a Join Reply has been received, or until 565 both packets sizes have been retransmitted 3 times. If the Join 566 Reply is not received after the maximum number of retransmissions, 567 the AP MUST abandon the AR and restart the discovery phase. 569 4.3.3.2 Format of a Join Request 571 The Join Request carries the following message elements: 573 AR Address 574 AP Descriptor 575 AP Name Payload 576 Location Data 577 Radio Payload (one for each radio) 578 Certificate 579 Session ID 580 Test 582 4.3.3.3 Receiving Join Requests 584 When an AR receives a Join Request it will respond with a Join Reply. 585 The AR validates the certificate found in the request. If valid, the 586 AR generates a session key which will be used to secure the control 587 frames it exchanges with the AP. When the AR issues the Join Reply, 588 the AR creates a context for the session with the AP. 590 Details on the key generation is found in appendix A. 592 4.3.4 Join Reply 594 The Join Reply is sent by the AR to indicate to an AP whether it is 595 capable and willing to provide service to it. 597 4.3.4.1 Sending Join Replies 599 Join Replies are sent by the AR after receiving a Join Request. Once 600 the Join Reply has been sent, the heartbeat timer is initiated for 601 the session. Expiration of the timer will result in delete of the 602 AR-AP session. The timer is refreshed upon receipt of the Echo 603 Request. 605 4.3.4.2 Format of a Join Reply 607 The Join Reply carries the following message elements: 609 Result Code 610 Certificate 611 Session Key 613 4.3.4.3 Receiving Join Replies 615 When an AP receives a Join Reply it enters the Joined state and 616 initiates the Configure Request to the AR to which it is now joined. 617 Upon entering the Joined state, the AP begins timing an interval 618 equal to NeighborDeadInterval. Expiration of the timer will result 619 in the transmission of the Echo Request. 621 4.3.5 Echo Request 623 The Echo Request message is a keepalive mechanism for the LWAPP 624 control message. 626 4.3.5.1 Sending Echo Requests 628 Echo Requests are sent by an AP in the Join or Run state to determine 629 the state of the connection between the AP and the AR. 631 4.3.5.2 Format of a Echo Request 633 The Echo Request carries no message elements. 635 4.3.5.3 Receiving Echo Requests 637 When an AR receives an Echo Request it responds with a Echo Response. 639 4.3.6 Echo Response 641 The Echo Response acknowledges the Echo Request. 643 4.3.6.1 Sending Echo Responses 645 Echo Responses are sent by an AR after receiving an Echo Request. 647 4.3.6.2 Format of a Echo Response 649 The Echo Response carries no message elements. 651 4.3.6.3 Receiving Echo Responses 653 When an AP receives an Echo Response it resets the timer that is 654 timing the NeighborDeadInterval. If the NeighborDeadInterval timer 655 expires prior to receiving an Echo Response, the AP enters the 656 Discovery state. 658 4.3.7 Key Update Request 660 The Key Update Request updates the LWAPP session key used to secure 661 messages between the AP and the AR. 663 4.3.7.1 Sending Key Update Requests 665 Key Update Requests are sent by an AP in the Run state to update a 666 session key. The Session ID message element MUST include a new 667 session identifier. 669 4.3.7.2 Format of a Key Update Request 671 The Key Update Request carries the following message elements: 673 Session ID 675 4.3.7.3 Receiving Key Update Requests 677 When an AR receives a Key Update Request it generates a new key (see 678 appendix A) and responds with a Key Update Response. 680 4.3.8 Key Update Response 682 The Key Update Response updates the LWAPP session key used to secure 683 messages between the AP and the AR, and acknowledges the Key Update 684 Request. 686 4.3.8.1 Sending Key Update Responses 688 Key Update Responses are sent by a AR after receiving a Key Update 689 Request. The Key Update Responses is secured using public key 690 cryptography. 692 4.3.8.2 Format of a Key Update Response 694 The Key Update Response carries the following message elements: 696 Session Key 698 4.3.8.3 Receiving Key Update Responses 700 When an AP receives a Key Update Response it will use the information 701 contained in the Session Key message element to determine the keying 702 material used to encrypt the LWAPP communications between the AP and 703 the AR. 705 4.3.9 Key Update Trigger 707 The Key Update Trigger is used by the AR to request that a Key Update 708 Request be initiated by the AP. 710 4.3.9.1 Sending Key Update Trigger 712 Key Update Requests are sent by an AR in the Run state to inform the 713 AP to initiate a Key Update Request message. 715 4.3.9.2 Format of a Key Update Trigger 717 The Key Update Request carries the following message elements: 719 Session ID 721 4.3.9.3 Receiving Key Update Trigger 723 When a AP receives a Key Update Trigger it generates a key Update 724 Request. 726 4.4 AR Configuration 728 The AR Configuration messages serve two purposes. They are used to 729 exchange configuration between AR and AP. Thy are also used by the 730 AR to retrieve statistics from the AP. 732 4.4.1 Configure Request 734 The Configure Request message is sent by an AP to send its current 735 configuration to its AR. 737 4.4.1.1 Sending Configure Requests 739 Configure Requests are sent by an AP after receiving a Join Reply. 741 4.4.1.2 Format of a Configure Request 743 The Configure Request carries binding specific message elements. 744 Refer to the appropriate binding for the definition of this 745 structure. 747 4.4.1.3 Receiving Configure Requests 749 When an AR receives a Configure Request it will act upon the content 750 of the packet and respond to the AP with a Configure Response. 752 4.4.2 Configure Response 754 The Configure Response message is sent by an AR and provides an 755 opportunity for the AR to override an AP's requested configuration. 757 4.4.2.1 Sending Configure Responses 759 Configure Responses are sent by an AR after receiving a Configure 760 Request. 762 4.4.2.2 Format of a Configure Response 764 The Configure Response carries binding specific message elements. 765 Refer to the appropriate binding for the definition of this 766 structure. 768 4.4.2.3 Receiving Configure Responses 770 When an AP receives a Configure Response it acts upon the content of 771 the packet, as appropriate. 773 4.4.3 Configuration Update Request 775 The Configuration Update Request is a message initiated by the AR to 776 update the configuration of an AP while in the Run state. 778 4.4.3.1 Sending Configuration Update Requests 780 Configure Update Requests are sent by the AR to provision the AP 781 while in the Run state. This is used to modify the configuration of 782 the AP while it is operational. 784 4.4.3.2 Format of a Configure Update Request 786 The Configure Command Request carries any of the following message 787 elements: 789 AP Name 4 790 Reserved 6 791 Rate Set 8 792 Multi-domain capability 9 793 MAC Operation 10 794 Reserved 11 795 Tx Power Level 12 796 Direct Sequence Control 13 797 OFDM Control 14 798 Supported Rates 15 799 Reserved 25 800 Administrative State 26 801 Delete WLAN 27 802 Reserved 28-29 803 Reserved 33 804 Location Data 34 805 Reserved 35 806 Statistics Timer 36 807 Session 44 808 WLAN Payload 50 809 Vendor Specific 51 810 Tx Power 52 811 Add Mobile 53 812 Delete Mobile 54 813 Mobile Session key 55 815 When an AR receives a Configuration Update Request it will respond 816 with a Configuration Update Reply, with the appropriate Result Code. 818 4.4.3.3 Receiving Configuration Update Requests 820 When an AR receives a Configuration Update Request it will respond 821 with a Configuration Update Reply, with the appropriate Result Code. 823 4.4.4 Configuration Update Response 825 The Configuration Update Response is the acknowledgement message for 826 the Configuration Update Request. 828 4.4.4.1 Sending Configuration Update Responses 830 Configuration Update Responses are sent by an AP after receiving a 831 Configuration Update Request. 833 4.4.4.2 Format of a Configuration Update Response 835 The Configuration Update Response carries the following message 836 elements: 838 Result Code 1 840 4.4.4.3 Receiving Configure Update Responses 842 When an AR receives a Configure Update Response the result code 843 indicates if the AP successfully accepted the configuration. 845 4.4.5 Statistics Report 847 Statistics Reports are used for statistics collection at the AR. 849 4.4.5.1 Sending Statistics Reports 851 Statistics Reports are sent by an AP periodically, based on the 852 configuration, to transfer statistics to the AR. 854 4.4.5.2 Format of a Statistics Report 856 The Statistics Report carries the following message elements: 858 Statistics 860 When an AR receives a Statistics Report it will respond with a 861 Statistics Response. 863 4.4.5.3 Receiving Statistics Report 865 When an AR receives a Statistics Report it will respond with a 866 Statistics Response. 868 4.4.6 Statistics Response 870 Statistics Response acknowledges the Statistics Report. 872 4.4.6.1 Sending Statistics Responses 874 Statistics Responses are sent by an AR after receiving a Statistics 875 Report. 877 4.4.6.2 Format of a Statistics Response 879 The Statistics Response carries no message elements. 881 4.4.6.3 Receiving Statistics Responses 883 The Statistics Response is simply an acknowledgement of the 884 Statistics Report. 886 4.4.7 Reset Request 888 The Reset Request is used to cause an AP to reboot. 890 4.4.7.1 Sending Reset Requests 892 Reset Requests are sent by an AR to cause an AP to reinitialize its 893 operation. 895 4.4.7.2 Format of a Reset Request 897 The Reset Request carries no message elements. 899 4.4.7.3 Receiving Reset Requests 901 When an AP receives a Reset Request it will respond with a Reset 902 Response and then reinitialize itself. 904 4.4.8 Reset Response 906 The Reset Response acknowledges the Reset Request. 908 4.4.8.1 Sending Reset Responses 910 Reset Responses are sent by an AP after receiving a Reset Request. 912 4.4.8.2 Format of a Reset Response 914 The Reset Response carries no message elements. Its purpose is to 915 acknowledge the receipt of the Reset Request. 917 4.4.8.3 Receiving Reset Responses 919 When an AR receives a Reset Response it is notified that the AP will 920 now reinitialize its operation. 922 4.5 Mobile Session Management 924 Messages in this section are used by the AR to create session state 925 on the APs. 927 4.5.1 Add Mobile Request 929 The Add Mobile Request is used by the AR to inform an AP that it 930 should forward traffic from a particular mobile station. The add 931 mobile request may also include security parameters that must be 932 enforced by the AP for the particular mobile. 934 4.5.1.1 Sending Add Mobile Requests 936 When the AR sends an Add Mobile Request, it includes any security 937 parameters that may be required. An AR that wishes to update a 938 mobile's policy on an AP may be done by simply sending a new Add 939 Mobile Request message. 941 4.5.1.2 Format of a Add Mobile Request 943 When sent by the AP, the Add Mobile Request contains the following 944 message elements: 946 Add Mobile 947 Mobile Session Key 949 4.5.1.3 Receiving Add Mobile Requests 951 When an AP receives an Add Mobile Request, it must first override any 952 existing state it may have for the mobile station in question. The 953 latest Add Mobile Request overrides any previously received messages. 954 If the Add Mobile message element's Not Authenticated bit is set, the 955 AP MUST only allow EAP packets to be forwarded to the AR, and must 956 drop any other messages. The AP will be notified via an Add Mobile 957 when it may accept other messages via a new Add Mobile Request from 958 the AR. 960 If the Mobile Session Key message element was present, the AP MUST 961 add the key to its session key table to ensure that all future 962 packets to the mobile are encrypted using the new key. 964 There are additional binding specific behaviours for this message. 965 See the appropriate binding for additional specifications. 967 4.5.2 Add Mobile Response 969 The Add Mobile Response is used to acknowledge a previously received 970 Add Mobile Request, and includes a Result Code message element which 971 indicates whether an error occured on the AP. 973 4.5.2.1 Sending Add Mobile Response 975 Add Mobile Response is sent by the AP as a response to the Add Mobile 976 Request. 978 4.5.2.2 Format of a Add Mobile Response 980 The Add Mobile Response includes the following message element: 982 Result Code 984 4.5.2.3 Receiving Add Mobile Response 986 This message requires no special processing, and is only used to 987 acknowledge the Add Mobile Request. 989 4.5.3 Delete Mobile Request 991 The Delete Mobile Request is used by the AR to inform the AP to 992 terminate service to a particular mobile station. 994 4.5.3.1 Sending Delete Mobile Requests 996 The AR sends the Delete Mobile Request when it determines that 997 service to the mobile must be terminated. This could occur for 998 various reasons, including for administrative reaons, as a result of 999 the fact that the mobile has roamed to another AP, etc. 1001 4.5.3.2 Format of a Delete Mobile Request 1003 The Delete Mobile Request message must include the following message 1004 element: 1006 Delete Mobile 1008 4.5.3.3 Receiving Delete Mobile Requests 1010 When an AP receives the Delete Mobile Request, it must immediately 1011 terminate service to the mobile station. 1013 There are additional binding specific behaviours for this message. 1014 See the appropriate binding for additional specifications. 1016 4.5.4 Delete Mobile Response 1018 The Delete Mobile Response is used to acknowledge a Delete Mobile 1019 Request. 1021 4.5.4.1 Sending Delete Mobile Response 1023 This message requires no special processing, and is only used to 1024 acknowledge the Delete Mobile Request. 1026 4.5.4.2 Format of a Delete Mobile Response 1028 The Delete Mobile Response message includes the following message 1029 element: 1031 Result Code 1033 4.5.4.3 Receiving Delete Mobile Response 1035 No special processing is required for this packet by the AR. 1037 4.6 Firmware Management 1039 The Firmware Management messages are used by the AR to ensure that 1040 the image being run on each AP is appropriate. 1042 4.6.1 Image Data Request 1044 The Image Data Request is used to update firmware on the AP. 1046 4.6.1.1 Sending Image Data Requests 1048 Image Data Requests are exchanged between the AP and the AR to 1049 download a new program image to an AP. 1051 4.6.1.2 Format of a Image Data Request 1053 When sent by the AP, the Image Data Request contains the following 1054 message elements: 1056 Image Download 1058 When sent by the AR, the Image Data Request contains the following 1059 message elements: 1061 Image Data 1063 4.6.1.3 Receiving Image Data Requests 1065 When an AP or AR receives an Image Data Request it will respond with 1066 a Image Data Response. 1068 4.6.2 Image Data Response 1070 The Image Data Response acknowledges the Image Data Request. 1072 4.6.2.1 Sending Image Data Response 1074 An Image Data Responses is sent in response to an Image Data Request. 1075 Its purpose is to acknowledge the receipt of the Image Data Request 1076 packet. 1078 4.6.2.2 Format of an Image Data Response 1080 The Image Data Response carries no message elements. 1082 4.6.2.3 Receiving Image Data Responses 1084 No action is necessary on receipt. 1086 5. LWAPP Message Elements 1088 As previously specified, the LWAPP messages MAY include one or more 1089 message elements. The message element types are defined in this 1090 section. 1092 The specified values for the Type field are the following: 1094 Description Type 1095 Result Code 1 1096 AR Address 2 1097 AP Descriptor 3 1098 AP Name 4 1099 AR Descriptor 5 1100 Reserved 6 1101 Binding AP WLAN Radio Configuration 7 1102 Binding Rate Set 8 1103 Binding Multi-domain capability 9 1104 Binding MAC Operation 10 1105 Reserved 11 1106 Binding Tx Power Level 12 1107 Binding Direct Sequence Control 13 1108 Binding OFDM Control 14 1109 Supported Rates 15 1110 Reserved 16 1111 Test 17 1112 Reserved 18-25 1113 Administrative State 26 1114 Delete WLAN 27 1115 Reserved 28-29 1116 AR Name 30 1117 Image Download 31 1118 Image Data 32 1119 Reserved 33 1120 Location Data 34 1121 Reserved 35 1122 Statistics Timer 36 1123 Binding Statistics 37 1124 Binding Antenna xx 1125 Reserved 38-42 1126 Certificate 43 1127 Session 44 1128 Session key 45 1129 Reserved 46-49 1130 Binding WLAN Create 50 1131 Vendor Specific 51 1132 Binding Tx Power 52 1133 Add Mobile 53 1134 Delete Mobile 54 1135 Mobile Session key 55 1137 5.1 Result Code 1139 The result code message element value is a 32-bit integer value, 1140 indicating the result of the request operation corresponding to the 1141 sequence number in the message. 1143 0 1 2 3 1144 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 1145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1146 | Result Code | 1147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 Result Code: The following values are defined: 1150 0 Success 1151 1 Failure 1153 5.2 AR Address 1155 The AR address message element is used to communicate the identity of 1156 the AR. The value contains two fields, as shown. 1158 0 1 2 3 1159 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 1160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1161 | Reserved | MAC Address | 1162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1163 | MAC Address | 1164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1166 Reserved: MUST be set to zero 1167 Mac Address: The MAC Address of the AR 1169 5.3 AP Descriptor 1171 The AP descriptor message element is used by the AP to communicate 1172 it's current hardware/firmware configuration. The value contains the 1173 following fields. 1175 0 1 2 3 1176 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 1177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1178 | Hardware Version | 1179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1180 | Software Version | 1181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1182 | Boot Version | 1183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1184 | Max Radios | Radios in use | Encryption Capabilities | 1185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 Hardware Version: A 32-bit integer representing the AP's hardware 1188 version number 1189 Software Version: A 32-bit integer representing the AP's Firmware 1190 version number 1191 Boot Version: A 32-bit integer representing the AP's boot loader's 1192 version number 1193 Max Radios: An 8-bit value representing the number of radios (where 1194 each radio is identified via the RID field) supported by the AP 1195 Radios in use: An 8-bit value representing the number of radios 1196 present in the AP 1197 Encryption Capabilities: This 16-bit field is used by the AP to 1198 communicate it's capabilities to the AR. Since most APs support 1199 link layer encryption, the AR may make use of these services. 1200 There are binding dependent encryption capabilites. Refer to the 1201 specific binding for the specification. This bitfield also 1202 defines the following binding-independent values: 1203 4 - Encrypt AES-CCM 128: All packets to/from the mobile station 1204 must be encrypted using 128 bit AES CCM [11]. 1205 5 - Encrypt TKIP-MIC: All packets to/from the mobile station must 1206 be encrypted using TKIP and authenticated using Michael [9]. 1208 5.4 AP Name 1210 The AP name message element value is a variable length byte string. 1211 The string is NOT zero terminated. 1213 5.5 AR Descriptor 1215 The AR payload message element is used by the AR to communicate it's 1216 current state. The value contains the following fields. 1218 0 1 2 3 1219 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 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 | Reserved | Hardware Version ... | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 | HW Ver | Software Version ... | 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 | SW Ver | Stations | Limit | 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1227 | Limit | Radios | Max Radio | 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Max Radio | 1230 +-+-+-+-+-+-+-+-+ 1232 Hardware Version: A 32-bit integer representing the AP's hardware 1233 version number 1234 Software Version: A 32-bit integer representing the AP's Firmware 1235 version number 1236 Stations: A 16-bit integer representing number of mobile stations 1237 currently associated with the AR 1238 Limit: A 16-bit integer representing the maximum number of stations 1239 supported by the AR 1240 Radios: A 16-bit integer representing the number of APs currently 1241 attached to the AR 1242 Max Radio: A 16-bit integer representing the maximum number of APs 1243 supported by the AR 1245 5.6 Binding AP WLAN Radio Configuration 1247 The AP WLAN radio configuration is used by the AR to configure a 1248 Radio on the AP. The message element definition is binding specific. 1249 Refer to the appropriate binding for the specification. 1251 5.7 Binding Rate Set 1253 The rate set message element value is sent by the AR and contains the 1254 supported operational rates. The message element definition is 1255 binding specific. Refer to the appropriate binding for the 1256 specification. 1258 5.8 Binding Multi-domain Capability 1260 The multi-domain capability message element is used by the AR to 1261 inform the AP of regulatory limits. The message element definition 1262 is binding specific. Refer to the appropriate binding for the 1263 specification. 1265 5.9 Binding MAC Operation 1267 The MAC operation message element is sent by the AR to set the 802.11 1268 MAC parameters on the AP. The message element definition is binding 1269 specific. Refer to the appropriate binding for the specification. 1271 5.10 Binding Tx Power Level 1273 The Tx power level message element is sent by the AP and contains the 1274 different power levels supported. The message element definition is 1275 binding specific. Refer to the appropriate binding for the 1276 specification. 1278 5.11 Binding Direct Sequence Control 1280 The direct sequence control message element is a bi-directional 1281 element. When sent by the AP, it contains the current state. When 1282 sent by the AR, the AP MUST adhere to the values. The message 1283 element definition is binding specific. Refer to the appropriate 1284 binding for the specification. 1286 5.12 Binding OFDM Control 1288 The OFDM control message element is a bi-directional element. When 1289 sent by the AP, it contains the current state. When sent by the AR, 1290 the AP MUST adhere to the values. The message element definition is 1291 binding specific. Refer to the appropriate binding for the 1292 specification. 1294 5.13 Binding Supported Rates 1296 The supported rates message element is sent by the AP to indicate the 1297 rates that it supports. The message element definition is binding 1298 specific. Refer to the appropriate binding for the specification. 1300 5.14 Test 1302 The test message element is used as padding to perform MTU discovery, 1303 and MAY contain any value, of any length. 1305 5.15 Administrative State 1307 The administrative event message element is used to communicate the 1308 state of a particular radio. The value contains the following 1309 fields. 1311 0 1 1312 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Radio ID | Admin State | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 Radio ID: An 8-bit value representing the radio to configure 1318 Admin State: An 8-bit value representing the administrative state of 1319 the radio. The following values are supported: 1320 0 - Enabled 1321 1 - Disabled 1323 5.16 Delete WLAN 1325 The delete WLAN message element is used to inform the AP that a 1326 previously created WLAN is to be deleted. The value contains the 1327 following fields: 1329 0 1 2 1330 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Radio ID | WLAN ID | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 Radio ID: An 8-bit value representing the radio 1336 WLAN ID: A 16-bit value specifying the WLAN Identifier 1338 5.17 AR Name 1340 The AR name message element contains an ASCII representation of the 1341 AR's identity. The value is a variable length byte string. The 1342 string is NOT zero terminated. 1344 5.18 Image Download 1346 The image download message element is sent by the AP to the AR and 1347 contains the image filename. The value is a variable length byte 1348 string. The string is NOT zero terminated. 1350 5.19 Image Data 1352 The image data message element value contains the following fields. 1354 0 1 2 3 1355 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 1356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1357 | Opcode | Checksum | Image Data | 1358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1359 | Image Data ... | 1360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1362 Opcode: An 8-bit value representing the transfer opcode. The 1363 following values are supported: 1364 3 - Image data is included 1365 5 - An error occurred. Transfer is aborted 1366 Checksum: A 16-bit value containing a checksum of the image data 1367 that follows 1368 Image Data: A variable length firmward data 1370 5.20 Location Data 1372 The location data message element is a variable length byte string 1373 containing user defined location information (e.g. "Next to 1374 Fridge"). The string is NOT zero terminated. 1376 5.21 Statistics Timer 1378 The statistics timer message element value is used by the AR to 1379 inform the AP of the frequency which it expects to receive updated 1380 statistics. 1382 0 1 1383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Statistics Timer | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 Statistics Timer: A 16-bit unsigned integer indicating the time, in 1389 seconds 1391 5.22 Binding Statistics 1393 The statistics message element is sent by the AP to transmit it's 1394 current statistics. The message element definition is binding 1395 specific. Refer to the appropriate binding for the specification. 1397 5.23 Binding Antenna 1399 The antenna message element is communicated by the AP to the AR to 1400 provide information on the antennas available. The AR MAY use this 1401 element to reconfigure the AP's antennas. The message element 1402 definition is binding specific. Refer to the appropriate binding for 1403 the specification. 1405 5.24 Certificate 1407 The certificate message element value is a byte string containing a 1408 DER-encoded x.509v3 certificate. 1410 5.25 Session ID 1412 The session ID message element value contains a randomly generated 1413 [5] unsigned 32-bit integer. 1415 5.26 Session Key Payload 1417 The Session Key Payload message element is sent by the AR to the AP 1418 and includes the randomly generated session key, which is used to 1419 protect the LWAPP control messages. More details are available in 1420 Appendix A. The value contains the following fields. 1422 0 1 2 3 1423 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 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | Session ID | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Session Key | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | Session Key | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | Session Key | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | Session Key | 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1436 Session ID: A 32-bit value defined in the session ID above. 1437 Session Key: A 128-bit value randomly generated session key [5] 1439 5.27 Binding WLAN Create 1441 The WLAN Create message element is used by the AR to define a 1442 wireless LAN on the AP. The message element definition is binding 1443 specific. Refer to the appropriate binding for the specification. 1445 5.28 Vendor Specific Payload 1447 The Vendor Specific Payload is used to communicate vendor specific 1448 information between the AP and the AR. The value contains the 1449 following format: 1451 0 1 2 3 1452 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 1453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 | Vendor Identifier | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 | Element ID | Value... | 1457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1459 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 1460 Network Management Private Enterprise Codes" [6] 1461 Element ID: A 16-bit Element Idenfier which is managed by the 1462 vendor. 1463 Element ID: Value The value associated with the vendor specific 1464 element. 1466 5.29 Binding Tx Power 1468 The Tx power message element value is bi-directional. When sent by 1469 the AP, it contains the current power level of the radio in question. 1471 When sent by the AR, it contains the power level the AP MUST adhere 1472 to. The message element definition is binding specific. Refer to 1473 the appropriate binding for the specification. 1475 5.30 Add Mobile 1477 The Add Mobile message element is used by the AR to inform the AP 1478 that it should allow traffic from/to a particular mobile station. 1480 0 1 2 3 1481 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 1482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1483 | Radio ID | Association ID | MAC Address | 1484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1485 | MAC Address | 1486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1487 | MAC Address | Preamble Mode | WLAN ID |Supported Rates| 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Supported Rates | 1490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 | Not Auth'ted | 1492 +-+-+-+-+-+-+-+-+ 1494 Radio ID: An 8-bit value representing the radio 1495 Association ID: A 16-bit value specifying the 802.11 Association 1496 Identifier 1497 MAC Address: The mobile station's MAC Address 1498 Preamble Mode: This field is set by the AR to inform the AP whether 1499 short or long preamble should be used with the mobile station. 1500 The following values are supported: 1501 0 - Long Preamble: Long preamble is to be used by the AP when 1502 communicating with the mobile station. 1503 1 - Short Preamble: Short preamble is to be used by the AP when 1504 communicating with the mobile station. 1505 WLAN ID: A 16-bit value specifying the WLAN Identifier 1506 Supported Rates: The supported rates to be used with the mobile 1507 station. 1508 Not Authenticated: The AR sets this field to one (1) during the 1509 authentication phase to inform the AP the mobile needs to be 1510 authenticated first and should only accept EAP packets. 1512 5.31 Delete Mobile 1514 The Delete Mobile message element is used by the AR to inform an AP 1515 that it should no longer provide service to a particular mobile 1516 station. 1518 0 1 2 3 1519 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 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Radio ID | MAC Address | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | MAC Address | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 Radio ID: An 8-bit value representing the radio 1527 MAC Address: The mobile station's MAC Address 1529 5.32 Binding Mobile Session Key 1531 The Mobile Session Key Payload message element is sent when the AR 1532 determines that encryption between a mobile station and the AP ir 1533 required. This message element MUST NOT be present without the Add 1534 Mobile (see Section 5.30)message element, and MUST NOT be sent if the 1535 AP had not specifically advertised support for the requested 1536 encryption scheme (see Section 5.3). The message element definition 1537 is binding specific. Refer to the appropriate binding for the 1538 specification. 1540 6. LWAPP Configuration Variables 1542 An AP or AR that implements LWAPP discovery MUST allow for the 1543 following variables to be configured by system management; default 1544 values are specified so as to make it unnecessary to configure any of 1545 these variables in many cases. 1547 6.1 MaxDiscoveryInterval 1549 The maximum time allowed between sending discovery requests from the 1550 interface, in seconds. Must be no less than 2 seconds and no greater 1551 than 180 seconds. 1553 Default: 20 seconds. 1555 6.2 MaxDiscoveries 1557 The maximum number of discovery requests that will be sent after an 1558 AP boots. 1560 Default: 10 1562 6.3 SilentInterval 1564 The minimum time, in seconds, an AP MUST wait after failing to 1565 receive any responses to its discovery requests, before it MAY again 1566 send discovery requests. 1568 Default: 30 1570 6.4 NeighborDeadInterval 1572 The minimum time, in seconds, an AP MUST wait without having received 1573 echo replies to its echo responses, before the destination for the 1574 echo replies may be considered dead. Must be no less than 1575 2*EchoInterval seconds and no greater than 240 seconds. 1577 Default: 60 1579 6.5 EchoInterval 1581 The minimum time, in seconds, between sending echo requests to the AR 1582 with which the AP has joined. 1584 Default: 30 1586 6.6 DiscoveryInterval 1588 The minimum time, in seconds, that an AP MUST wait after receiving a 1589 discovery reply, before sending a join request. 1591 Default: 5 1593 7. LWAPP Transport Layers 1595 The LWAPP protocol can operate at layer 2 or 3. For layer 2 support, 1596 the LWAPP messages are carried in a native Ethernet frame. As such, 1597 the protocol is not routable and depends upon layer 2 connectivity 1598 between the AP and the AR. Layer 3 support is provided by 1599 encapsulating the LWAPP messages within UDP. 1601 7.1 Using IEEE 802.3 MAC as LWAPP transport 1603 This section describes how the LWAPP protocol is provided over native 1604 ethernet frames. An LWAPP packet is formed from the MAC frame header 1605 followed by the LWAPP message header. 1607 7.1.1 Framing 1609 Source Address 1611 A MAC address belonging to the interface from which this message is 1612 sent. If multiple source addresses are configured on an interface, 1613 then the one chosen is implementation dependent. 1615 Destination Address 1617 A MAC address belonging to the interface to which this message is to 1618 be sent. This destination address MAY be either an individual 1619 address or a multicast address, if more than one destination 1620 interface is intended. 1622 Ethertype 1624 The Ethertype field is set to 0x88bb. 1626 7.1.2 AR Discovery 1628 When run over IEEE 802.3, LWAPP messages are distributed to a 1629 specific MAC level broadcast domain. The AR discovery mechanism used 1630 with this transport is for an AP to transmit a Discovery Request 1631 message to a broadcast destination MAC address. The ARs will receive 1632 this message and reply based on their policy. 1634 7.1.3 Fragmentation/Reassembly 1636 Fragmentation at the MAC layer is managed using the C,F,L and Frag ID 1637 fields of the LWAPP message header. 1639 7.1.4 Multiplexing 1641 LWAPP control messages and data messages are distinguished by the C 1642 Bit in the LWAPP message header. 1644 7.1.5 LWAPP Message Header format over IEEE 802.3 MAC transport 1646 The LWAPP message header for data and command messages in the 802.3 1647 MAC transport follows immediately after the MAC header: 1649 0 1 2 3 1650 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 1651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1652 |VER| RID |C|F|L| Frag ID | Length | 1653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 | Status/WLANs | Payload... | 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1657 7.1.5.1 VER Field (2 bits) 1659 Defines the version of LWAPP used in this packet. The value for this 1660 draft is 0. 1662 7.1.5.2 RID Field (3 bits) 1664 The RID field gives the Radio ID number for this packet. APs with 1665 multiple radios but a single MAC use this to indicate which radio is 1666 associated with the packet. 1668 7.1.5.3 C Bit 1670 The C bit indicates whether this packet carries a data message or a 1671 control message. When this bit is 0, the packet carries an LWAPP 1672 data message in the payload. When this bit is 1, the packet carries 1673 an LWAPp control messwage as defined in section 4 for consumption by 1674 the addressed destination. 1676 7.1.5.4 F Bit 1678 The F bit indicates whether this packet is a fragment. When this bit 1679 is 1, the packet is a fragment and MUST be combined with the other 1680 corresponding fragments to reassemble the complete information 1681 exchanged between the AP and AR. 1683 7.1.5.5 L Bit 1685 The L bit is valid only if the 'F' bit is set and indicates whether 1686 the packet contains the last fragment of a fragmented exchange 1687 between AP and AR. When this bit is 1, the packet is not the last 1688 fragment. When this bit is 0, the packet is the last fragment. 1690 7.1.5.6 Fragment ID (8 bits) 1692 The Fragment ID is a value assigned to each group of fragments making 1693 up a complete set. The value of Fragment ID is incremented with each 1694 new set of fragments. The Fragment ID wraps to zero after the 1695 maximum value has been used to identify a set of fragments. LWAPP 1696 only supports up to 2 fragments. 1698 7.1.5.7 Length (16 bits) 1700 The length field is the unsigned number of bytes in the Payload. 1702 7.1.5.8 Status and WLANS (16 bits) 1704 The interpretation of this field is binding specific. Refer to the 1705 transport portion of the binding for a wireless technology for the 1706 specification. 1708 7.1.5.9 Payload 1710 This field contains the header for an LWAPP Data Message or LWAPP 1711 Control Message, followed by the data associated with that message. 1713 7.2 Using IPv4/UDP as LWAPP transport 1715 This section defines how LWAPP makes use of IPV4/UDP transport 1716 between the AP and the AR. In case of this transport, the MAC layer 1717 is as standard for an IPv4 packet. 1719 7.2.1 Framing 1721 Communication between AP and AR is established according to the 1722 standard UDP client/server model. The connection is initiated by the 1723 AP (client) to the well-known UDP port of the AR (server) used for 1724 control messages. This UDP port number of the AR is TBD. 1726 7.2.2 AR Discovery 1728 When LWAPP is run over routed IPv4 networks, the AP and the AR do not 1729 need to reside in the same IP subnet (broadcast domain). However, in 1730 the event the peers reside on separate subnets, there must exist a 1731 mechanism for the AP to discover the AR. 1733 As the AP attempts to establish communication with the AR, it sends 1734 the Discovery Request message and receives the corresponding reply 1735 message from the AR. The AP must send the Discovery Request message 1736 to either the limited broadcast IP address (255.255.255.255) or to 1737 the unicast IP address of the AR. Upon receipt of the message, the 1738 AR issues a Discovery Reply message to the IP address of the AP, 1739 regardless of whether Discovery Request was sent as a broadcast or 1740 unicast message. 1742 Whether the AP uses a limited IP broadcast or unicast IP address is 1743 implementation dependent. 1745 In order for the AP to use a unicast address, it must first obtain 1746 the IP address of the AR. The configuration of the AR's address in 1747 the AP is implementation dependent. 1749 Informative note: Some possibilities are to make use of a vendor 1750 specific DHCP option, DNS name resolution, or even static 1751 provisioning of the AR's IP address in non-volatile storage. 1753 7.2.3 Fragmentation/Reassembly 1755 When LWAPP is implemented at L3, the transport layer uses IP 1756 fragmentation to fragment and reassemble LWAPP messages that are 1757 longer than MTU size used by either AP or AR. The details of IP 1758 fragmentation are covered in [3]. 1760 [ed: IP fragmentation may raise security concerns and bring 1761 additional configuration requirements for certain firewalls and NATs. 1762 One alternative is to re-use the layer 2 (application layer) 1763 fragmentation reassembly. Comments are welcomed.] 1765 7.2.4 Multiplexing 1767 LWAPP messages convey control information between AP and AR, as well 1768 as binding specific data frames or binding specific management 1769 frames. As such, LWAPP messages need to be multiplexed in the 1770 transport sub-layer and be delivered to the proper software entities 1771 in the endpoints of the protocol. 1773 In case of Layer 3 connection, multiplexing is achieved by use of 1774 different UDP ports for control and data packets. 1776 As part of Join procedure, the AP and AR may negotiate different UDP 1777 ports, as well as, different IP addresses for data or session 1778 management messages. [ed: details on how to communicate this 1779 information in the protocol is still missing]. 1781 In the event the AP and AR are separated by a NAT, with the AP using 1782 private IP address space, it is the responsibility of the NAT to 1783 manage appropriate UDP port mapping. 1785 7.2.5 LWAPP Message Header format over IPv4/UDP transport 1787 The LWAPP message header for data and command messages using the 1788 IPv4/UDP transport follows immediately after the UDP header: 1790 0 1 2 3 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 |VER| RID | Reserved | Length | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Status/WLANS | Payload... | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1798 7.2.5.1 VER (2 bits) 1800 Defines the version of LWAPP used in this packet. The value for this 1801 draft is 0. 1803 7.2.5.2 RID (3 bits) 1805 The RID field gives the Radio ID number for this packet. APs with 1806 multiple radios but a single IPv4 address use this to indicate which 1807 radio is associated with the packet. 1809 7.2.5.3 Reserved (11 bits) 1811 The reserved field MUST be set to zero. 1813 7.2.5.4 Length (16 bits) 1815 The length field is the unsigned number of bytes in the Payload. 1817 7.2.5.5 Status and WLANS (16 bits) 1819 The interpretation of this field is binding specific. Refer to the 1820 transport portion of the binding for a wireless technology for the 1821 specification. 1823 7.2.5.6 Payload 1825 This field contains the LWAPP Data Message or LWAPP Control Message. 1827 8. Light Weight Access Protocol Constants 1829 MAX_RESPONSE_DELAY 2 seconds 1831 MAX_SOLICITATION_DELAY 1 second 1833 SOLICITATION_INTERVAL 3 seconds 1835 MAX_SOLICITATIONS 3 transmissions 1837 9. Security Considerations 1839 LWAPP uses public key cryptography to ensure trust between the AP and 1840 the AR. During the Join phase, the AR generates a session key, which 1841 is used to secure future control messages. The AP does not 1842 participate in the key generation, but public key cryptography is 1843 used to authenticate the resulting key material. A secured delivery 1844 mechanism to place the certificate in the devices is required. In 1845 order to maximize session key security, the AP and AR periodically 1846 update the session keys, which are encrypted using public key 1847 cryptography. This ensures that a potentially previously compromised 1848 key does not affect the security of communication with new key 1849 material. 1851 One question that periodically arises is why the Join Request is not 1852 signed. It was felt that requiring a signature in this messages was 1853 not required for the following reasons: 1854 1. The Join Request is replayable, so requiring a signature doesn't 1855 provide much protection unless the switches keep track of all 1856 previous Join Requests from a given AP. One alternative would 1857 have been to add a timestamp, but this introduces clock 1858 synchronization issues. Further, authentication occurs in a later 1859 exchange anyway (see point 2 below). 1860 2. The AP is authenticated by virtue of the fact that it can decrypt 1861 and then use the session keys (encrypted with its own public key), 1862 so it *is* ultimately authenticated. 1863 3. A signed Join Request provides a potential Denial of Service 1864 attack on the AR, which would have to authenticate each 1865 (potentially malicious) message. 1867 10. IPR Statement 1869 The IETF has been notified of intellectual property rights claimed in 1870 regard to some or all of the specification contained in this 1871 document. For more information consult the online list of claimed 1872 rights. 1874 Please refer to http://www.ietf.org/ietf/IPR for more information. 1876 11 References 1878 [1] "Advanced Encryption Standard (AES)", November 2001, . 1881 [2] "Counter with CBC-MAC (CCM)", January 2003, 1882 1883 . 1885 [3] "IP DATAGRAM REASSEMBLY ALGORITHMS", July 1992, 1886 . 1888 [4] "Key words for use in RFCs to Indicate Requirement Levels", 1889 March 1997, . 1891 [5] "Randomness Recommendations for Security", December 1994, 1892 . 1894 [6] "Assigned Numbers: RFC 1700 is Replaced by an On-line 1895 Database", January 2002, . 1897 [7] "The Internet Standards Process Revision 3", October 1996, 1898 . 1900 [8] "Mobility Related Terminology", April 2003, 1901 1902 . 1904 [9] "WiFi Protected Access (WPA) rev 1.6", April 2003. 1906 [10] "IEEE Std 802.11: Wireless LAN Medium Access Control (MAC) and 1907 Physical Layer (PHY) Specifications", 1999. 1909 [11] "IEEE Std 802.11i/3.0: Specification for Enhanced Security", 1910 November 2003. 1912 [12] "Security Architecture for IP, IETF RFC 2401", November 1998, 1913 . 1915 Authors' Addresses 1917 Pat R. Calhoun 1918 Airespace 1919 110 Nortech Parkway 1920 San Jose, CA 95134 1922 Phone: +1 408-635-2000 1923 EMail: pcalhoun@airespace.com 1925 Bob O'Hara 1926 Airespace 1927 110 Nortech Parkway 1928 San Jose, CA 95134 1930 Phone: +1 408-635-2025 1931 EMail: bob@airespace.com 1933 Scott Kelly 1934 Airespace 1935 110 Nortech Parkway 1936 San Jose, CA 95134 1938 Phone: +1 408-635-2022 1939 EMail: skelly@airespace.com 1941 Rohit Suri 1942 Airespace 1943 110 Nortech Parkway 1944 San Jose, CA 95134 1946 Phone: +1 408-635-2026 1947 EMail: rsuri@airespace.com 1949 Michael Glenn Williams 1950 Nokia, Inc. 1951 313 Fairchild Drive 1952 Mountain View, CA 94043 1954 Phone: +1 650-714-7758 1955 EMail: Michael.G.Williams@Nokia.com 1956 Michael Vakulenko 1957 Legra Systems, Inc. 1958 3 Burlington Woods Drive 1959 Burlington, MA 01803 1961 Phone: +1 781-272-8400 1962 EMail: michaelv@legra.com 1964 Appendix A. Session Key Generation 1966 Note: This version only defines a certificate based mechanism to 1967 secure traffic between the AP and the AR. A shared-secret mechanism 1968 will be added in a future version. 1970 A.1 Securing AP-AR communications 1972 While it is generally straightforward to produce network 1973 installations in which the communications medium between the AP and 1974 AR is not accessible to the casual user (e.g. these LAN segments are 1975 isolated, no RJ45 or other access ports exist between the AP and the 1976 AR), this will not always be the case. Furthermore, a determined 1977 attacker may resort to various more sophisticated monitoring and/or 1978 access techniques, thereby compromising the integrity of this 1979 connection. 1981 In general, a certain level of threat on the local (wired) LAN is 1982 expected and accepted in most computing environments. That is, it is 1983 expected that in order to provide users with an acceptable level of 1984 service and maintain reasonable productivity levels, a certain amount 1985 of risk must be tolerated. It is generally believed that a certain 1986 perimeter is maintained around such LANs, that an attacker must have 1987 access to the building(s) in which such LANs exist, and that they 1988 must be able to "plug in" to the LAN in order to access the network. 1990 With these things in mind, we can begin to assess the general 1991 security requirements for AR-AP communications. While an in-depth 1992 security analysis of threats and risks to these communication is 1993 beyond the scope of this document, some discussion of the motivation 1994 for various security-related design choices is useful. The 1995 assumptions driving the security design thus far include the 1996 following: 1997 o AP-AR communications take place over a wired connection which may 1998 be accessible to a sophisticated attacker 1999 o access to this connection is not trivial for an outsider (i.e. 2000 someone who does not "belong" in the building) to access 2001 o if authentication and/or privacy of end to end traffic for which 2002 the AP and AR are intermediaries is required, this may be provided 2003 via IPsec [12]. 2004 o privacy and authentication for at least some AP-AR control traffic 2005 is required (e.g. WEP keys for user sessions, passed from AR to 2006 AP) 2007 o the AR can be trusted to generate strong cryptographic keys 2009 AR-AP traffic can be considered to consist of two types: data traffic 2010 (e.g. to or from an end user), and control traffic which is strictly 2011 between the AR and AP. Since data traffic may be secured using IPsec 2012 (or some other end-to-end security mechanism), we confine our 2013 solution to control traffic. The resulting security consists of two 2014 components: an authenticated key exchange, and control traffic 2015 security encapsulation. The security encapsulation is accomplished 2016 using CCM, described in [2]. This encapsulation provides for strong 2017 AES-based authentication and encryption. The exchange of 2018 cryptographic keys used for CCM is described below. 2020 A.2 Authenticated Key Exchange 2022 The AR and AP accomplish mutual authentication and a cryptographic 2023 key exchange in a single round trip using the JOIN request/response 2024 pair. To accomplish this, the AP includes its identity certificate 2025 (see Section 5.24) and a randomly-generated session ID (see Section 2026 5.25) which functions as a cryptographic nonce in the JOIN request. 2027 The AR verifies the AP's certificate, and replies with its own 2028 identity certificate, and a signed concatenation of the session ID 2029 and and encrypted cryptographic session key. This exchange is 2030 detailed below, using the following notation: 2031 o Kpriv - the private key of a public-private key pair. 2032 o Kpub - the public key of the pair 2033 o M - a clear-text message 2034 o C - a cipher-text message. 2035 o PKCS1(z) - the PKCS#1 encapsulation of z 2036 o E-x{Kpriv, M} - encryption of M using X's private key 2037 o E-x{Kpub, M} - encryption of M using X's public key 2038 o S-x{M} - a digital signature over M produced by X 2039 o V-x{S-x, M} - verification of X's digital signature over M 2040 o D-x{Kpriv, C} - decryption of C using X's private key 2041 o D-x{Kpub, C} - decryption of C using X's public key 2042 o Certificate-AR - AR's Certificate 2043 o Certificate-AP - AP's Certificate 2045 When the AR receives the SessionID value along with the AP's 2046 certificate, it constructs the reply payload as follows: 2047 o Randomly generate enough key material to produce an encryption key 2048 and an authentication hash key (xx bytes in length). [TBD: 2049 detailed key material generation instructions] 2050 o Compute C1 = E-ap{ Kpub , PKCS1(KeyMaterial)}; this encrypts the 2051 PKCS#1-encoded key material with the public key of the AP, so that 2052 only the AP can decrypt it and determine the session keys. 2053 o Compute S1 = S-ar{SessionID|C1}; this computes the AR's digital 2054 signature over the concatenation of the nonce and the encrypted 2055 key material, and can be verified using the public key of the AR, 2056 "proving" that the AR produced this; this forms the basis of trust 2057 for the AP with respect to the source of the session keys. 2059 o AR sends (Certificate-AR, C1, S1, SessionID) to AP 2060 o AP verifies that SessionID matches an outstanding request 2061 o AP verifies authenticity of Certificate-AR 2062 o AP computes V-ar{S1, SessionID|C1}, verifying the AR's signature 2063 over the session identifier and the encrypted key material 2064 o AP computes PKCS1(KeyMaterial) = D-ar{ Kpriv , C1}, decrypting the 2065 session keys using its private key; since these were encrypted 2066 with the AP's public key, only the AP can successfully decrypt 2067 this. 2068 KeyMaterial is divided into the encryption key and the HMAC key 2069 [TBD: say how] From this point on, all control protocol payloads 2070 between the AP and AR are encrypted and authenticated. The 2071 related payloads are described in the sections above. 2073 A.3 Refreshing Cryptographic Keys 2075 Since AR-AP associations will tend to be relatively long-lived, it is 2076 sensible to periodically refresh the encryption and authentication 2077 keys; this is referred to as "rekeying". When the key lifetime 2078 reaches 95% of the configured value, the rekeying will proceed as 2079 follows: 2080 o AP generates a fresh SessionID value, and constructs a TLV payload 2081 of type SESSION which contains new SessionID and sends it in 2082 KEY-UPDATE message to AR. 2083 o When the AR receives KEY-UPDATE request with SessionID it 2084 constructs the reply payload as follows: 2085 i) Randomly generate enough key material to produce an encryption 2086 key and an authentication hash key (xx bytes in length). 2087 [TBD:detailed key material generation instructions] 2088 ii) Compute C1 = E-ap{ Kpub , PKCS1(KeyMaterial)}; this encrypts 2089 the PKCS#1-encoded key material with the public key of the AP, 2090 so that only the AP can decrypt it and determine the session 2091 keys. 2092 iii) Compute S1 = S-ar{SessionID|C1}; this computes the AR's 2093 digital signature over the concatenation of the sessionId and 2094 the encrypted key material, and can be verified using the 2095 public key of the AR, "proving" that the AR produced this; this 2096 forms the basis of trust for the AP with respect to the source 2097 of the session keys. 2098 iv) AR then sends a KEY-UPDATE-RSP message to the AP using the new 2099 session values. 2100 o AP must maintain session state for the original SessionID and keys 2101 until it receives the KEY-UPDATE-RSP, at which time it clears the 2102 old session. 2103 o If AP does not receive the KEY-UPDATE-RSP within a reasonable 2104 period of time (1 minute?), it will resend the original request 2105 and reset its response timer. If no response occurs by the time 2106 the original session expires, the AP will delete the new and old 2107 session information, and initiate the DISCOVER process anew. 2109 Appendix B. Wireless Bindings 2111 Each wireless technology supported by LWAPP has an associated 2112 binding. LWAPP is designed to support multiple wireless technologies 2113 using this method of specification. The binding is divided into 2114 three portions: transport specific, ref. Section 7; LWAPP data 2115 message, ref. Section 4; LWAPP control message, ref. Section 4. 2117 B.1 IEEE 802.11 Binding 2119 B.1.1 Transport specific bindings 2121 All LWAPP transports have the following IEEE 802.11 specific 2122 bindings: 2124 B.1.1.1 Status and WLANS field (16 bits) 2126 The interpretation of this field depends on the direction of 2127 transmission of the packet. Refer to the figure in Section 7.1.5. 2129 Status 2131 When an LWAPP packet is transmitted from an AP to an AR, this field 2132 is called the status field and indicates radio resource information 2133 associated with the frame. When the message is an LWAPP control 2134 message this field is transmitted as zero. 2136 The status field is divided into the signal strength and signal to 2137 noise ratio with which an IEEE 802.11 frame was received, encoded in 2138 the following manner: 2140 0 1 2141 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2143 | RSSI | SNR | 2144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 RSSI (8 bits) 2148 RSSI is a signed, 8-bit value. It is the received signal strength 2149 indication, in dBm. 2151 SNR (8 bits) 2153 SNR is a signed, 8-bit value. It is the signal to noise ratio of the 2154 received IEEE 802.11 frame, in dB. 2156 WLANS field (16 bits) 2158 When an LWAPP data message is transmitted from an AR to an AP, this 2159 field indicates on which WLANs the encapsulated IEEE 802.11 frame is 2160 to be transmitted. For unicast packets, this field is not used by 2161 the AP. For broadcast or multicast packets, the AP might require 2162 this information if it provides encryption services. 2164 Given that a single broadcast or multicast packet might need to be 2165 sent to multiple wireless LANs (presumably each with a different 2166 broadcast key), this field is defined as a bit field. A bit set 2167 indicates a WLAN ID (see Section 5.27) which will be sent the data. 2168 The WLANS field is encoded in the following manner: 2170 0 1 2171 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2173 | WLAN ID(s) | 2174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2176 B.1.2 Data Message bindings 2178 There are no LWAPP Data Message bindings for IEEE 802.11. 2180 B.1.3 Control Message bindings 2182 The IEEE 802.11 binding has the following Control Message 2183 definitions. Control Message Bindings are arranged according to the 2184 four Control Message types: 2185 Control Channel Message Bindings 2186 AR Configuration Message Bindings 2187 Mobile Session Management Bindings 2188 Firmware Management Bindings 2190 Refer to Section 5 and to this binding for the generic and binding 2191 specific message element type definitions. 2193 B.1.3.1 Control Channel Message Bindings 2195 There are no Control Channel Message bindings within the Control 2196 Message Bindings for IEEE 802.11. 2198 B.1.3.2 AR Configuration Message Bindings 2200 Configure Request Message 2201 The Configure Request carries the following message elements: 2202 Administrative State (for the AP) 2203 AR Name 2204 Administrative State (for each radio) 2205 AP WLAN Radio Configuration (for each radio) 2206 Multi-domain Capability (for each radio) 2207 MAC Operation (for each radio) 2208 PHY TX Power (for each radio) 2209 PHY TX Power Level (for each Radio) 2210 PHY DSSS Payload or PHY OFDM Payload (for each radio) 2211 Antenna (for each radio) 2212 Supported Rates (for each radio) 2214 Configure Response Message 2216 The Configure Response carries the following message elements: 2217 Result Code 2218 AP WLAN Radio Configuration (for each radio) 2219 Operational Rate Set (for each radio) 2220 Multi-domain Capability (for each radio) 2221 MAC Operation (for each radio) 2222 PHY Tx Power (for each Radio) 2223 PHY DSSS or PHY OFDM Payload (for each radio) 2224 Antenna (for each radio) 2226 B.1.3.3 Mobile Session Management Bindings 2228 Add Mobile Request 2230 When the AR sends an Add Mobile Request, it includes any security 2231 parameters that may be required. Further, if the AR's policy is that 2232 802.1X (or WPA) is required, it must set the 802.1X only bit in the 2233 Add Mobile message element. An AR that wishes to update a mobile's 2234 policy on an AP may be done by sending a new Add Mobile Request 2235 message. 2237 If 802.1X (or WPA) was established with the mobile station, the AR 2238 will need to push the session key the AP must use for encrypting all 2239 traffic to the mobile, which is included in the Mobile Session Key 2240 message element. 2242 Delete Mobile Request 2244 Any future packets received from the Mobile must result in a 2245 deauthenticate message, as specified in [10]. 2247 B.1.3.4 Firmware Management Bindings 2249 There are no Firmware Management Message bindings within the Control 2250 Message Bindings for IEEE 802.11. 2252 B.1.4 Message Element Bindings 2254 The IEEE 802.11 Message Element binding has the following 2255 definitions: 2257 B.1.4.1 Binding AP WLAN Radio Configuration 2259 The AP WLAN radio configuration is used by the AR to configure a 2260 Radio on the AP. The message element value contains the following 2261 Fields: 2263 0 1 2 3 2264 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 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | Radio ID | Reserved | Occupancy Limit | 2267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2268 | CFP Per | CFP Maximum Duration | BSS ID | 2269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 | BSS ID | 2271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2272 | BSS ID | Beacon Period | DTIM Per | 2273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2274 | Country String | 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2277 Radio ID: An 8-bit value representing the radio to configure 2279 Reserved: MUST be set to zero 2281 Occupancy Limit: This attribute indicates the maximum amount of 2282 time, in TU, that a point coordinator MAY control the usage of the 2283 wireless medium without relinquishing control for long enough to 2284 allow at least one instance of DCF access to the medium. The default 2285 value of this attribute SHOULD be 100, and the maximum value SHOULD 2286 be 1000 2288 CFP Period: The attribute describes the number of DTIM intervals 2289 between the start of CFPs 2291 CFP Maximum Duration: The attribute describes the maximum duration 2292 of the CFP in TU that MAY be generated by the PCF 2293 BSSID: The WLAN Radio's MAC Address 2295 Beacon Period: This attribute specifies the number of TU that a 2296 station uses for scheduling Beacon transmissions. This value is 2297 transmitted in Beacon and Probe Response frames 2299 DTIM Period: This attribute specifies the number of beacon intervals 2300 that elapses between transmission of Beacons frames containing a TIM 2301 element whose DTIM Count field is 0. This value is transmitted in 2302 the DTIM Period field of Beacon frames 2304 Country Code: This attribute identifies the country in which the 2305 station is operating. The first two octets of this string is the two 2306 character country code as described in document ISO/IEC 3166- 1. The 2307 third octet MUST be one of the following: 2308 an ASCII space character, if the regulations under which the 2309 station is operating encompass all environments in the country, 2310 an ASCII 'O' character, if the regulations under which the station 2311 is operating are for an outdoor environment only, or 2312 an ASCII 'I' character, if the regulations under which the station 2313 is operating are for an indoor environment only 2315 B.1.4.2 Binding Rate Set 2317 The rate set message element value is sent by the AR and contains the 2318 supported operational rates. It contains the following fields. 2320 0 1 2 3 2321 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 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | Radio ID | Rate Set | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 Radio ID: An 8-bit value representing the radio to configure 2328 Rate Set: The AR generates the Rate Set that the AP is to include in 2329 it's Beacon and Probe messages 2331 B.1.4.3 Binding Multi-domain Capability 2333 The multi-domain capability message element is used by the AR to 2334 inform the AP of regulatory limits. The value contains the following 2335 fields. 2337 0 1 2 3 2338 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 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 | Radio ID | Reserved | First Channel # | 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2342 | Number of Channels | Max Tx Power Level | 2343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2345 Radio ID: An 8-bit value representing the radio to configure 2347 Reserved: MUST be set to zero 2349 First Channnel #: This attribute indicates the value of the lowest 2350 channel number in the subband for the associated domain country 2351 string. 2353 Number of Channels: This attribute indicates the value of the total 2354 number of channels allowed in the subband for the associated domain 2355 country string. 2357 Max Tx Power Level: This attribute indicates the maximum transmit 2358 power, in dBm, allowed in the subband for the associated domain 2359 country string. 2361 B.1.4.4 Binding MAC Operation 2363 The MAC operation message element is sent by the AR to set the 802.11 2364 MAC parameters on the AP. The value 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 | Radio ID | Reserved | RTS Threshold | 2370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2371 | Short Retry | Long Retry | Fragmentation Threshold | 2372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2373 | Tx MSDU Lifetime | 2374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 | Rx MSDU Lifetime | 2376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2378 Radio ID: An 8-bit value representing the radio to configure 2380 Reserved: MUST be set to zero 2382 RTS Threshold: This attribute indicates the number of octets in an 2383 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 2384 RTS/CTS handshake MUST be performed at the beginning of any frame 2385 exchange sequence where the MPDU is of type Data or Management, the 2386 MPDU has an individual address in the Address1 field, and the length 2387 of the MPDU is greater than this threshold. Setting this attribute 2388 to be larger than the maximum MSDU size MUST have the effect of 2389 turning off the RTS/CTS handshake for frames of Data or Management 2390 type transmitted by this STA. Setting this attribute to zero MUST 2391 have the effect of turning on the RTS/CTS handshake for all frames of 2392 Data or Management type transmitted by this STA. The default value 2393 of this attribute MUST be 2347. 2395 Short Retry: This attribute indicates the maximum number of 2396 transmission attempts of a frame, the length of which is less than or 2397 equal to RTSThreshold, that MUST be made before a failure condition 2398 is indicated. The default value of this attribute MUST be 7. 2400 Long Retry: This attribute indicates the maximum number of 2401 transmission attempts of a frame, the length of which is greater than 2402 dot11RTSThreshold, that MUST be made before a failure condition is 2403 indicated. The default value of this attribute MUST be 4. 2405 Fragmentation Threshold: This attribute specifies the current 2406 maximum size, in octets, of the MPDU that MAY be delivered to the 2407 PHY. An MSDU MUST be broken into fragments if its size exceeds the 2408 value of this attribute after adding MAC headers and trailers. An 2409 MSDU or MMPDU MUST be fragmented when the resulting frame has an 2410 individual address in the Address1 field, and the length of the frame 2411 is larger than this threshold. The default value for this attribute 2412 MUST be the lesser of 2346 or the aMPDUMaxLength of the attached PHY 2413 and MUST never exceed the lesser of 2346 or the aMPDUMaxLength of the 2414 attached PHY. The value of this attribute MUST never be less than 2415 256. 2417 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 2418 after the initial transmission of an MSDU, after which further 2419 attempts to transmit the MSDU MUST be terminated. The default value 2420 of this attribute MUST be 512. 2422 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 2423 after the initial reception of a fragmented MMPDU or MSDU, after 2424 which further attempts to reassemble the MMPDU or MSDU MUST be 2425 terminated. The default value MUST be 512. 2427 B.1.4.5 Binding Tx Power Level 2429 The Tx power level message element is sent by the AP and contains the 2430 different power levels supported. The value contains the following 2431 fields. 2433 0 1 2 3 2434 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 2435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2436 | Radio ID | Num Levels | Power Level [n] | 2437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2439 Radio ID: An 8-bit value representing the radio to configure 2441 Num Levels: The number of power level attributes 2443 Power Level: Each power level fields contains a supported power 2444 level, in mW. 2446 B.1.4.6 Binding Direct Sequence Control 2448 The direct sequence control message element is a bi-directional 2449 element. When sent by the AP, it contains the current state. When 2450 sent by the AR, the AP MUST adhere to the values. This element is 2451 only used for 802.11b radios. The value has the following fields. 2453 0 1 2 3 2454 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 2455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2456 | Radio ID | Reserved | Current Chan | Current CCA | 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | Energy Detect Threshold | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2461 Radio ID: An 8-bit value representing the radio to configure 2463 Reserved: MUST be set to zero 2465 Current Channel: This attribute contains the current operating 2466 frequency channel of the DSSS PHY. 2468 Current CCA: The current CCA method in operation. Valid values are: 2469 1 - energy detect only (edonly) 2470 2 - carrier sense only (csonly) 2471 4 - carrier sense and energy detect (edandcs) 2472 8 - carrier sense with timer (cswithtimer) 2473 16 - high rate carrier sense and energy detect (hrcsanded) 2475 Energy Detect Threshold: The current Energy Detect Threshold being 2476 used by the DSSS PHY 2478 B.1.4.7 Binding OFDM Control 2480 The OFDM control message element is a bi-directional element. When 2481 sent by the AP, it contains the current state. When sent by the AR, 2482 the AP MUST adhere to the values. This element is only used for 2483 802.11a radios. The value contains the following fields: 2485 0 1 2 3 2486 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 2487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2488 | Radio ID | Reserved | Current Chan | Band Support | 2489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2490 | TI Threshold | 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2493 Radio ID: An 8-bit value representing the radio to configure 2495 Reserved: MUST be set to zero 2497 Current Channel: This attribute contains the current operating 2498 frequency channel of the OFDM PHY. 2500 Band Supported: The capability of the OFDM PHY implementation to 2501 operate in the three U-NII bands. Coded as an integer value of a 2502 three bit field as follows: 2503 capable of operating in the lower (5.15-5.25 GHz) U-NII band 2504 capable of operating in the middle (5.25-5.35 GHz) U-NII band 2505 capable of operating in the upper (5.725-5.825 GHz) U-NII band 2507 For example, for an implementation capable of operating in the lower 2508 and mid bands this attribute would take the value 2510 TI Threshold: The Threshold being used to detect a busy medium 2511 (frequency). CCA MUST report a busy medium upon detecting the RSSI 2512 above this threshold 2514 B.1.4.8 Binding Supported Rates 2516 The supported rates message element is sent by the AP to indicate the 2517 rates that it supports. The value contains the following fields. 2519 0 1 2 3 2520 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 2521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2522 | Radio ID | Supported Rates | 2523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2525 Radio ID: An 8-bit value representing the radio 2527 Supported Rates: The AP includes the Supported Rates that it's 2528 hardware supports. The format is identical to the Rate Set message 2529 element. 2531 B.1.4.9 Binding Statistics 2533 The statistics message element is sent by the AP to transmit it's 2534 current statistics. The value contains the following fields. 2536 0 1 2 3 2537 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 2538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2539 | Radio ID | Tx Fragment Count | 2540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2541 |Tx Fragment Cnt| Multicast Tx Count | 2542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2543 | Mcast Tx Cnt | Failed Count | 2544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2545 | Failed Count | Retry Count | 2546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2547 | Retry Count | Multiple Retry Count | 2548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2549 |Multi Retry Cnt| Frame Duplicate Count | 2550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2551 | Frame Dup Cnt | RTS Success Count | 2552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2553 |RTS Success Cnt| RTS Failure Count | 2554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2555 |RTS Failure Cnt| ACK Failure Count | 2556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2557 |ACK Failure Cnt| Rx Fragment Count | 2558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2559 |Rx Fragment Cnt| Multicast RX Count | 2560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2561 | Mcast Rx Cnt | FCS Error Count | 2562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2563 | FCS Error Cnt| Tx Frame Count | 2564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2565 | Tx Frame Cnt | Reserved | 2566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2567 | Reserved | 2568 +-+-+-+-+-+-+-+-+ 2570 Radio ID: An 8-bit value representing the radio 2571 Tx Fragment Count: A 32-bit value representing the number of 2572 fragmented frames transmitted. 2574 Multicast Tx Count: A 32-bit value representing the number of 2575 multicast frames transmitted. 2577 Failed Count: A 32-bit value representing the transmit excessive 2578 retries. 2580 Retry Count: A 32-bit value representing the number of transmit 2581 retries. 2583 Multiple Retry Count: A 32-bit value representing the number of 2584 transmits that required more than one retry. 2586 Frame Duplicate Count: A 32-bit value representing the duplicate 2587 frames received. 2589 RTS Success Count: A 32-bit value representing the number of 2590 successful Ready To Send (RTS). 2592 RTS Failure Count: A 32-bit value representing the failed RTS. 2594 ACK Failure Count: A 32-bit value representing the number of failed 2595 acknowledgements. 2597 Rx Fragment Count: A 32-bit value representing the number of 2598 fragmented frames received. 2600 Multicast RX Count: A 32-bit value representing the number of 2601 multicast frames received. 2603 FCS Error Count: A 32-bit value representing the number of FCS 2604 failures. 2606 Reserved: MUST be set to zero 2608 B.1.4.10 Binding Antenna 2610 The antenna message element is communicated by the AP to the AR to 2611 provide information on the antennas available. The AR MAY use this 2612 element to reconfigure the AP's antennas. The value contains the 2613 following fields: 2615 0 1 2 3 2616 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 2617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2618 | Radio ID | Diversity | Reserved | Antenna Cnt | 2619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2620 | Antenna Selection [0..N] | 2621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2623 Radio ID: An 8-bit value representing the radio 2625 Diversity: An 8-bit value specifying whether the antenna is to 2626 provide receive diversity. The following values are supported: 2627 Disabled 2628 Enabled (may only be true if the antenna can be used as a receive 2629 antenna) 2631 Reserved: MUST be set to zero 2633 Antenna Count: An 8-bit value specifying the number of Antenna 2634 Selection fields. 2636 The following values are supported: 2637 Sectorized (Left) 2638 Sectorized (Right) 2639 Omni 2641 B.1.4.11 Binding WLAN Payload 2643 The WLAN payload message element is used by the AR to define a 2644 wireless LAN on the AP. The value contains the following format: 2646 0 1 2 3 2647 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 2648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2649 | Radio ID | WLAN Capability | WLAN ID | 2650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2651 | WLAN ID | SSID ... | 2652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2654 Radio ID: An 8-bit value representing the radio 2656 WLAN Capability: A 16-bit value containing the capabilities to be 2657 advertised by the AP within the Probe and Beacon messages. 2659 WLAN ID: A 16-bit value specifying the WLAN Identifier 2661 SSID: The SSID attribute is a variable length byte string containing 2662 the SSID to be advertised by the AP. The string is NOT zero 2663 terminated. 2665 B.1.4.12 Binding Tx Power 2667 The Tx power message element value is bi-directional. When sent by 2668 the AP, it contains the current power level of the radio in question. 2669 When sent by the AR, it contains the power level the AP MUST adhere 2670 to. 2672 0 1 2 3 2673 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 2674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2675 | Radio ID | Reserved | Current Tx Power | 2676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2678 Radio ID: An 8-bit value representing the radio to configure 2680 Reserved: MUST be set to zero 2682 Current Tx Power: This attribute contains the transmit output power 2683 in mW 2685 B.1.4.13 Binding Mobile Session Key 2687 The Mobile Session Key Payload message element is sent when the AR 2688 determines that encryption of a mobile station must be performed in 2689 the AP. This message element MUST NOT be present without the Add 2690 Mobile (see Section 5.30) message element, and MUST NOT be sent if 2691 the AP had not specifically advertised support for the requested 2692 encryption scheme (see Section 5.3). 2694 0 1 2 3 2695 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 2696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2697 | MAC Address | 2698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2699 | MAC Address | Encryption Policy | 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | Encryption Policy | Session Key... | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2704 MAC Address: The mobile station's MAC Address 2706 Encryption Policy: The policy field informs the AP how to handle 2707 packets from/to the mobile station. The following values are 2708 supported: 2709 Encrypt WEP 104: All packets to/from the mobile station must be 2710 encrypted using standard 104 bit WEP. 2712 Clear Text: All packets to/from the mobile station do not require 2713 any additional crypto processing by the AP. 2714 Encrypt WEP 40: All packets to/from the mobile station must be 2715 encrypted using standard 40 bit WEP. 2716 Encrypt WEP 128: All packets to/from the mobile station must be 2717 encrypted using standard 128 bit WEP. 2718 Encrypt AES-OCB 128: All packets to/from the mobile station must 2719 be encrypted using 128 bit AES OCB [11] 2720 Encrypt TKIP-MIC: All packets to/from the mobile station must be 2721 encrypted using TKIP and authenticated using Michael [9] 2723 Session Key: The session key the AP is to use when encrypting 2724 traffic to/from the mobile station. 2726 Intellectual Property Statement 2728 The IETF takes no position regarding the validity or scope of any 2729 intellectual property or other rights that might be claimed to 2730 pertain to the implementation or use of the technology described in 2731 this document or the extent to which any license under such rights 2732 might or might not be available; neither does it represent that it 2733 has made any effort to identify any such rights. Information on the 2734 IETF's procedures with respect to rights in standards-track and 2735 standards-related documentation can be found in BCP-11. Copies of 2736 claims of rights made available for publication and any assurances of 2737 licenses to be made available, or the result of an attempt made to 2738 obtain a general license or permission for the use of such 2739 proprietary rights by implementors or users of this specification can 2740 be obtained from the IETF Secretariat. 2742 The IETF invites any interested party to bring to its attention any 2743 copyrights, patents or patent applications, or other proprietary 2744 rights which may cover technology that may be required to practice 2745 this standard. Please address the information to the IETF Executive 2746 Director. 2748 Full Copyright Statement 2750 Copyright (C) The Internet Society (2004). All Rights Reserved. 2752 This document and translations of it may be copied and furnished to 2753 others, and derivative works that comment on or otherwise explain it 2754 or assist in its implementation may be prepared, copied, published 2755 and distributed, in whole or in part, without restriction of any 2756 kind, provided that the above copyright notice and this paragraph are 2757 included on all such copies and derivative works. However, this 2758 document itself may not be modified in any way, such as by removing 2759 the copyright notice or references to the Internet Society or other 2760 Internet organizations, except as needed for the purpose of 2761 developing Internet standards in which case the procedures for 2762 copyrights defined in the Internet Standards process must be 2763 followed, or as required to translate it into languages other than 2764 English. 2766 The limited permissions granted above are perpetual and will not be 2767 revoked by the Internet Society or its successors or assignees. 2769 This document and the information contained herein is provided on an 2770 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2771 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2772 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2773 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2774 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2776 Acknowledgment 2778 Funding for the RFC Editor function is currently provided by the 2779 Internet Society.