draft-ohara-capwap-lwapp-00.txt   draft-ohara-capwap-lwapp-01.txt 
Network Working Group P. Calhoun Network Working Group P. Calhoun
Internet-Draft B. O'Hara Internet-Draft B. O'Hara
Expires: November 6, 2004 S. Kelly Expires: August 5, 2005 Airespace
S. Kelly
Facetime Communications
R. Suri R. Suri
Airespace Airespace
M. Williams M. Williams
Nokia, Inc. Nokia, Inc.
M. Vakulenko S. Hares
Legra Systems, Inc. Nexthop Technologies, Inc.
May 8, 2004 Feb 2005
Light Weight Access Point Protocol (LWAPP) Light Weight Access Point Protocol (LWAPP)
draft-ohara-capwap-lwapp-00 draft-ohara-capwap-lwapp-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is subject to all provisions
all provisions of Section 10 of RFC2026. of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 6, 2004. This Internet-Draft will expire on August 5, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
Wireless Access Points are not strictly Layer 2 bridges. Such In the recent years, there has been a shift in wireless LAN product
devices may be much simpler, barely more than radios. They may also architectures from autonomous access points to centralized control of
perform some additional or higher layer functions such as those light weight access points. The general goal has been to move most
performed by switches and routers. For example, in IEEE 802.11 of the traditional wireless functionality such as access control
networks, Access Points can function as Network Access Servers. This (user authentication and authorization), mobility and radio
is one reason Access Points may have IP addresses and function as IP management out of the access point into a centralized controller.
devices.
This document describes the Light Weight Access Point Protocol which The IETF's CAPWAP WG has identified that a standards based protocol
supports control and management of wireless Access Points. Bindings is necessary between a wireless Access Controller and Wireless
for each wireless system specify the protocol as applied to that Termination Points (the latter are also commonly referred to as Light
technology. An IEEE 802.11 binding is provided in this draft. Weight Access Points). This specification defines the Light Weight
Access Point Protocol (LWAPP), which addresses the CAPWAP's protocol
requirements. Although the LWAPP protocol is designed to be flexible
enough to be used for a variety of wireless technologies, this
specific document describes the base protocol, and an extension that
allows it to be used with the IEEE's 802.11 wireless LAN protocol.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Conventions used in this document . . . . . . . . . . . . 6 1.1 Conventions used in this document . . . . . . . . . . . 8
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.1 Wireless Binding Definition . . . . . . . . . . . . . . 11
3.1 Wireless Binding Definition . . . . . . . . . . . . . . . 9 2.2 LWAPP State Machine Definition . . . . . . . . . . . . . 11
3.2 LWAPP State Machine Definition . . . . . . . . . . . . . . 9 3. LWAPP Transport Layers . . . . . . . . . . . . . . . . . . . 18
4. LWAPP Packet Definitions . . . . . . . . . . . . . . . . . . . 10 3.1 LWAPP Transport Header . . . . . . . . . . . . . . . . . 18
4.1 LWAPP Data Messages . . . . . . . . . . . . . . . . . . . 10 3.1.1 VER Field . . . . . . . . . . . . . . . . . . . . . 18
4.2 LWAPP Control Messages Overview . . . . . . . . . . . . . 10 3.1.2 RID Field . . . . . . . . . . . . . . . . . . . . . 18
4.2.1 Control Message Format . . . . . . . . . . . . . . . . 10 3.1.3 C Bit . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Control Channel Management . . . . . . . . . . . . . . . . 12 3.1.4 F Bit . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 Discovery Requests . . . . . . . . . . . . . . . . . . 12 3.1.5 L Bit . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.2 Discovery Reply . . . . . . . . . . . . . . . . . . . 13 3.1.6 Fragment ID . . . . . . . . . . . . . . . . . . . . 19
4.3.3 Join Request . . . . . . . . . . . . . . . . . . . . . 14 3.1.7 Length . . . . . . . . . . . . . . . . . . . . . . . 19
4.3.4 Join Reply . . . . . . . . . . . . . . . . . . . . . . 15 3.1.8 Status and WLANS . . . . . . . . . . . . . . . . . . 19
4.3.5 Echo Request . . . . . . . . . . . . . . . . . . . . . 15 3.1.9 Payload . . . . . . . . . . . . . . . . . . . . . . 19
4.3.6 Echo Response . . . . . . . . . . . . . . . . . . . . 16 3.2 Using IEEE 802.3 MAC as LWAPP transport . . . . . . . . 19
4.3.7 Key Update Request . . . . . . . . . . . . . . . . . . 16 3.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . 19
4.3.8 Key Update Response . . . . . . . . . . . . . . . . . 17 3.2.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 20
4.3.9 Key Update Trigger . . . . . . . . . . . . . . . . . . 17 3.2.3 LWAPP Message Header format over IEEE 802.3 MAC
4.4 AR Configuration . . . . . . . . . . . . . . . . . . . . . 18 transport . . . . . . . . . . . . . . . . . . . . . 20
4.4.1 Configure Request . . . . . . . . . . . . . . . . . . 18 3.2.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 20
4.4.2 Configure Response . . . . . . . . . . . . . . . . . . 18 3.2.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 20
4.4.3 Configuration Update Request . . . . . . . . . . . . . 19 3.3 Using IPv4/UDP as LWAPP transport . . . . . . . . . . . 20
4.4.4 Configuration Update Response . . . . . . . . . . . . 20 3.3.1 Framing . . . . . . . . . . . . . . . . . . . . . . 20
4.4.5 Statistics Report . . . . . . . . . . . . . . . . . . 20 3.3.2 AC Discovery . . . . . . . . . . . . . . . . . . . . 21
4.4.6 Statistics Response . . . . . . . . . . . . . . . . . 21 3.3.3 LWAPP Message Header format over IPv4/UDP transport 21
4.4.7 Reset Request . . . . . . . . . . . . . . . . . . . . 21 3.3.4 Fragmentation/Reassembly . . . . . . . . . . . . . . 22
4.4.8 Reset Response . . . . . . . . . . . . . . . . . . . . 21 3.3.5 Multiplexing . . . . . . . . . . . . . . . . . . . . 22
4.5 Mobile Session Management . . . . . . . . . . . . . . . . 22 4. LWAPP Packet Definitions . . . . . . . . . . . . . . . . . . 23
4.5.1 Add Mobile Request . . . . . . . . . . . . . . . . . . 22 4.1 LWAPP Data Messages . . . . . . . . . . . . . . . . . . 23
4.5.2 Add Mobile Response . . . . . . . . . . . . . . . . . 23 4.2 LWAPP Control Messages Overview . . . . . . . . . . . . 23
4.5.3 Delete Mobile Request . . . . . . . . . . . . . . . . 23 4.2.1 Control Message Format . . . . . . . . . . . . . . . 24
4.5.4 Delete Mobile Response . . . . . . . . . . . . . . . . 24 4.2.2 Message Element Format . . . . . . . . . . . . . . . 26
4.6 Firmware Management . . . . . . . . . . . . . . . . . . . 24 5. LWAPP Discovery Operations . . . . . . . . . . . . . . . . . 28
4.6.1 Image Data Request . . . . . . . . . . . . . . . . . . 24 5.1 Discovery Request . . . . . . . . . . . . . . . . . . . 28
4.6.2 Image Data Response . . . . . . . . . . . . . . . . . 25 5.1.1 Discovery Type . . . . . . . . . . . . . . . . . . . 29
5. LWAPP Message Elements . . . . . . . . . . . . . . . . . . . . 26 5.1.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 29
5.1 Result Code . . . . . . . . . . . . . . . . . . . . . . . 27 5.1.3 WTP Radio Information . . . . . . . . . . . . . . . 30
5.2 AR Address . . . . . . . . . . . . . . . . . . . . . . . . 27 5.2 Discovery Response . . . . . . . . . . . . . . . . . . . 30
5.3 AP Descriptor . . . . . . . . . . . . . . . . . . . . . . 27 5.2.1 AC Descriptor . . . . . . . . . . . . . . . . . . . 31
5.4 AP Name . . . . . . . . . . . . . . . . . . . . . . . . . 28 5.2.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 31
5.5 AR Descriptor . . . . . . . . . . . . . . . . . . . . . . 28 5.2.3 WTP Manager Control IP Address . . . . . . . . . . . 32
5.6 Binding AP WLAN Radio Configuration . . . . . . . . . . . 29 5.3 Primary Discovery Request . . . . . . . . . . . . . . . 32
5.7 Binding Rate Set . . . . . . . . . . . . . . . . . . . . . 29 5.3.1 Discovery Type . . . . . . . . . . . . . . . . . . . 33
5.8 Binding Multi-domain Capability . . . . . . . . . . . . . 29 5.3.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 33
5.9 Binding MAC Operation . . . . . . . . . . . . . . . . . . 29 5.3.3 WTP Radio Information . . . . . . . . . . . . . . . 33
5.10 Binding Tx Power Level . . . . . . . . . . . . . . . . . . 29 5.4 Primary Discovery Response . . . . . . . . . . . . . . . 33
5.11 Binding Direct Sequence Control . . . . . . . . . . . . . 30 5.4.1 AC Descriptor . . . . . . . . . . . . . . . . . . . 33
5.12 Binding OFDM Control . . . . . . . . . . . . . . . . . . . 30 5.4.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 33
5.13 Binding Supported Rates . . . . . . . . . . . . . . . . . 30 5.4.3 WTP Manager Control IP Address . . . . . . . . . . . 33
5.14 Test . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6. Control Channel Management . . . . . . . . . . . . . . . . . 35
5.15 Administrative State . . . . . . . . . . . . . . . . . . . 30 6.1 Join Request . . . . . . . . . . . . . . . . . . . . . . 35
5.16 Delete WLAN . . . . . . . . . . . . . . . . . . . . . . . 30 6.1.1 AC Address . . . . . . . . . . . . . . . . . . . . . 35
5.17 AR Name . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.2 WTP Descriptor . . . . . . . . . . . . . . . . . . . 36
5.18 Image Download . . . . . . . . . . . . . . . . . . . . . . 31 6.1.3 WTP Name . . . . . . . . . . . . . . . . . . . . . . 36
5.19 Image Data . . . . . . . . . . . . . . . . . . . . . . . . 31 6.1.4 Location Data . . . . . . . . . . . . . . . . . . . 36
5.20 Location Data . . . . . . . . . . . . . . . . . . . . . . 31 6.1.5 WTP Radio Information . . . . . . . . . . . . . . . 37
5.21 Statistics Timer . . . . . . . . . . . . . . . . . . . . . 32 6.1.6 Certificate . . . . . . . . . . . . . . . . . . . . 37
5.22 Binding Statistics . . . . . . . . . . . . . . . . . . . . 32 6.1.7 Session ID . . . . . . . . . . . . . . . . . . . . . 37
5.23 Binding Antenna . . . . . . . . . . . . . . . . . . . . . 32 6.1.8 Test . . . . . . . . . . . . . . . . . . . . . . . . 37
5.24 Certificate . . . . . . . . . . . . . . . . . . . . . . . 32 6.2 Join Response . . . . . . . . . . . . . . . . . . . . . 38
5.25 Session ID . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 38
5.26 Session Key Payload . . . . . . . . . . . . . . . . . . . 32 6.2.2 Status . . . . . . . . . . . . . . . . . . . . . . . 39
5.27 Binding WLAN Create . . . . . . . . . . . . . . . . . . . 33 6.2.3 Certificate . . . . . . . . . . . . . . . . . . . . 39
5.28 Vendor Specific Payload . . . . . . . . . . . . . . . . . 33 6.2.4 Session Key . . . . . . . . . . . . . . . . . . . . 39
5.29 Binding Tx Power . . . . . . . . . . . . . . . . . . . . . 33 6.2.5 WTP Manager Data IP Address . . . . . . . . . . . . 40
5.30 Add Mobile . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3 Echo Request . . . . . . . . . . . . . . . . . . . . . . 40
5.31 Delete Mobile . . . . . . . . . . . . . . . . . . . . . . 34 6.4 Echo Response . . . . . . . . . . . . . . . . . . . . . 40
5.32 Binding Mobile Session Key . . . . . . . . . . . . . . . . 35 6.5 Key Update Request . . . . . . . . . . . . . . . . . . . 41
6. LWAPP Configuration Variables . . . . . . . . . . . . . . . . 36 6.5.1 Session ID . . . . . . . . . . . . . . . . . . . . . 41
6.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . . 36 6.6 Key Update Response . . . . . . . . . . . . . . . . . . 41
6.2 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . . 36 6.6.1 Session Key . . . . . . . . . . . . . . . . . . . . 42
6.3 SilentInterval . . . . . . . . . . . . . . . . . . . . . . 36 6.7 Key Update Trigger . . . . . . . . . . . . . . . . . . . 42
6.4 NeighborDeadInterval . . . . . . . . . . . . . . . . . . . 36 6.7.1 Session ID . . . . . . . . . . . . . . . . . . . . . 42
6.5 EchoInterval . . . . . . . . . . . . . . . . . . . . . . . 36 7. WTP Configuration Management . . . . . . . . . . . . . . . . 43
6.6 DiscoveryInterval . . . . . . . . . . . . . . . . . . . . 37 7.1 Configure Request . . . . . . . . . . . . . . . . . . . 43
7. LWAPP Transport Layers . . . . . . . . . . . . . . . . . . . . 38 7.1.1 Administrative State . . . . . . . . . . . . . . . . 43
7.1 Using IEEE 802.3 MAC as LWAPP transport . . . . . . . . . 38 7.1.2 AC Name . . . . . . . . . . . . . . . . . . . . . . 44
7.1.1 Framing . . . . . . . . . . . . . . . . . . . . . . . 38 7.1.3 AC Name with Index . . . . . . . . . . . . . . . . . 44
7.1.2 AR Discovery . . . . . . . . . . . . . . . . . . . . . 38 7.1.4 WTP Board Data . . . . . . . . . . . . . . . . . . . 44
7.1.3 Fragmentation/Reassembly . . . . . . . . . . . . . . . 38 7.1.5 Statistics Timer . . . . . . . . . . . . . . . . . . 45
7.1.4 Multiplexing . . . . . . . . . . . . . . . . . . . . . 39 7.1.6 WTP Static IP Address Information . . . . . . . . . 45
7.1.5 LWAPP Message Header format over IEEE 802.3 MAC 7.1.7 WTP Reboot Statistics . . . . . . . . . . . . . . . 46
transport . . . . . . . . . . . . . . . . . . . . . . 39 7.2 Configure Response . . . . . . . . . . . . . . . . . . . 46
7.2 Using IPv4/UDP as LWAPP transport . . . . . . . . . . . . 40 7.2.1 Decryption Error Report Period . . . . . . . . . . . 47
7.2.1 Framing . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.2 Change State Event . . . . . . . . . . . . . . . . . 47
7.2.2 AR Discovery . . . . . . . . . . . . . . . . . . . . . 40 7.2.3 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 48
7.2.3 Fragmentation/Reassembly . . . . . . . . . . . . . . . 41 7.2.4 AC List . . . . . . . . . . . . . . . . . . . . . . 48
7.2.4 Multiplexing . . . . . . . . . . . . . . . . . . . . . 41 7.2.5 WTP Fallback . . . . . . . . . . . . . . . . . . . . 48
7.2.5 LWAPP Message Header format over IPv4/UDP transport . 42 7.2.6 Idle Timeout . . . . . . . . . . . . . . . . . . . . 49
8. Light Weight Access Protocol Constants . . . . . . . . . . . . 43 7.3 Configuration Update Request . . . . . . . . . . . . . . 49
9. Security Considerations . . . . . . . . . . . . . . . . . . . 44 7.3.1 WTP Name . . . . . . . . . . . . . . . . . . . . . . 49
10. IPR Statement . . . . . . . . . . . . . . . . . . . . . . . 45 7.3.2 Change State Event . . . . . . . . . . . . . . . . . 50
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 7.3.3 Administrative State . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 46 7.3.4 Statistics Timer . . . . . . . . . . . . . . . . . . 50
A. Session Key Generation . . . . . . . . . . . . . . . . . . . . 48 7.3.5 Location Data . . . . . . . . . . . . . . . . . . . 50
A.1 Securing AP-AR communications . . . . . . . . . . . . . . 48 7.3.6 Decryption Error Report Period . . . . . . . . . . . 50
A.2 Authenticated Key Exchange . . . . . . . . . . . . . . . . 49 7.3.7 AC List . . . . . . . . . . . . . . . . . . . . . . 50
A.3 Refreshing Cryptographic Keys . . . . . . . . . . . . . . 50 7.3.8 Add Blacklist Entry . . . . . . . . . . . . . . . . 50
B. Wireless Bindings . . . . . . . . . . . . . . . . . . . . . . 52 7.3.9 Delete Blacklist Entry . . . . . . . . . . . . . . . 51
B.1 IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . 52 7.3.10 Add Static Blacklist Entry . . . . . . . . . . . . . 51
B.1.1 Transport specific bindings . . . . . . . . . . . . . 52 7.3.11 Delete Static Blacklist Entry . . . . . . . . . . . 52
B.1.2 Data Message bindings . . . . . . . . . . . . . . . . 53 7.3.12 LWAPP Timers . . . . . . . . . . . . . . . . . . . . 52
B.1.3 Control Message bindings . . . . . . . . . . . . . . . 53 7.3.13 AC Name with Index . . . . . . . . . . . . . . . . . 52
B.1.4 Message Element Bindings . . . . . . . . . . . . . . . 55 7.3.14 WTP Fallback . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . 66 7.3.15 Idle Timeout . . . . . . . . . . . . . . . . . . . . 52
7.4 Configuration Update Response . . . . . . . . . . . . . 52
7.4.1 Result Code . . . . . . . . . . . . . . . . . . . . 53
7.5 Change State Event Request . . . . . . . . . . . . . . . 53
7.5.1 Change State Event . . . . . . . . . . . . . . . . . 53
7.6 Change State Event Response . . . . . . . . . . . . . . 53
7.7 Clear Config Indication . . . . . . . . . . . . . . . . 54
8. Device Management Operations . . . . . . . . . . . . . . . . 55
8.1 Image Data Request . . . . . . . . . . . . . . . . . . . 55
8.1.1 Image Download . . . . . . . . . . . . . . . . . . . 55
8.1.2 Image Data . . . . . . . . . . . . . . . . . . . . . 55
8.2 Image Data Response . . . . . . . . . . . . . . . . . . 56
8.3 Reset Request . . . . . . . . . . . . . . . . . . . . . 56
8.4 Reset Response . . . . . . . . . . . . . . . . . . . . . 56
8.5 WTP Event Request . . . . . . . . . . . . . . . . . . . 56
8.5.1 Decryption Error Report . . . . . . . . . . . . . . 57
8.5.2 Duplicate IP Address . . . . . . . . . . . . . . . . 57
8.6 WTP Event Response . . . . . . . . . . . . . . . . . . . 58
8.7 Data Transfer Request . . . . . . . . . . . . . . . . . 58
8.7.1 Data Transfer Mode . . . . . . . . . . . . . . . . . 58
8.7.2 Data Transfer Data . . . . . . . . . . . . . . . . . 59
8.8 Data Transfer Response . . . . . . . . . . . . . . . . . 59
9. Mobile Session Management . . . . . . . . . . . . . . . . . 60
9.1 Mobile Config Request . . . . . . . . . . . . . . . . . 60
9.1.1 Delete Mobile . . . . . . . . . . . . . . . . . . . 60
9.2 Mobile Config Response . . . . . . . . . . . . . . . . . 61
9.2.1 Result Code . . . . . . . . . . . . . . . . . . . . 61
10. Session Key Generation . . . . . . . . . . . . . . . . . . 62
10.1 Securing WTP-AC communications . . . . . . . . . . . . . 62
10.2 LWAPP Frame Encryption . . . . . . . . . . . . . . . . . 63
10.3 Authenticated Key Exchange . . . . . . . . . . . . . . . 63
10.4 Refreshing Cryptographic Keys . . . . . . . . . . . . . 65
11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . 67
11.1 Transport specific bindings . . . . . . . . . . . . . . 67
11.1.1 Status and WLANS field . . . . . . . . . . . . . . . 67
11.2 Data Message bindings . . . . . . . . . . . . . . . . . 68
11.3 Control Message bindings . . . . . . . . . . . . . . . . 68
11.3.1 Mobile Config Request . . . . . . . . . . . . . . . 68
11.3.2 WTP Event Request . . . . . . . . . . . . . . . . . 72
11.4 802.11 Control Messages . . . . . . . . . . . . . . . . 74
11.4.1 IEEE 802.11 WLAN Config Request . . . . . . . . . . 74
11.4.2 IEEE 802.11 WLAN Config Response . . . . . . . . . . 78
11.4.3 IEEE 802.11 WTP Event . . . . . . . . . . . . . . . 78
11.5 Message Element Bindings . . . . . . . . . . . . . . . . 79
11.5.1 IEEE 802.11 WTP WLAN Radio Configuration . . . . . . 80
11.5.2 IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 81
11.5.3 IEEE 802.11 Multi-domain Capability . . . . . . . . 82
11.5.4 IEEE 802.11 MAC Operation . . . . . . . . . . . . . 82
11.5.5 IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 84
11.5.6 IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 84
11.5.7 IEEE 802.11 Direct Sequence Control . . . . . . . . 84
11.5.8 IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 85
11.5.9 IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 86
11.5.10 IEEE 802.11 Supported Rates . . . . . . . . . . . 86
11.5.11 IEEE 802.11 CFP Status . . . . . . . . . . . . . . 87
11.5.12 IEEE 802.11 WTP Mode and Type . . . . . . . . . . 87
11.5.13 IEEE 802.11 Broadcast Probe Mode . . . . . . . . . 88
11.5.14 IEEE 802.11 WTP Quality of Service . . . . . . . . 88
11.5.15 IEEE 802.11 MIC Error Report From Mobile . . . . . 89
11.6 IEEE 802.11 Message Element Values . . . . . . . . . . . 90
12. LWAPP Protocol Timers . . . . . . . . . . . . . . . . . . 91
12.1 MaxDiscoveryInterval . . . . . . . . . . . . . . . . . . 91
12.2 SilentInterval . . . . . . . . . . . . . . . . . . . . . 91
12.3 NeighborDeadInterval . . . . . . . . . . . . . . . . . . 91
12.4 EchoInterval . . . . . . . . . . . . . . . . . . . . . . 91
12.5 DiscoveryInterval . . . . . . . . . . . . . . . . . . . 91
12.6 RetransmitInterval . . . . . . . . . . . . . . . . . . . 91
12.7 ResponseTimeout . . . . . . . . . . . . . . . . . . . . 92
12.8 KeyLifetime . . . . . . . . . . . . . . . . . . . . . . 92
13. LWAPP Protocol Variables . . . . . . . . . . . . . . . . . 93
13.1 MaxDiscoveries . . . . . . . . . . . . . . . . . . . . . 93
13.2 DiscoveryCount . . . . . . . . . . . . . . . . . . . . . 93
13.3 RetransmitCount . . . . . . . . . . . . . . . . . . . . 93
13.4 MaxRetransmit . . . . . . . . . . . . . . . . . . . . . 93
14. Security Considerations . . . . . . . . . . . . . . . . . 94
15. IANA Considerations . . . . . . . . . . . . . . . . . . . 95
16. IPR Statement . . . . . . . . . . . . . . . . . . . . . . 96
17. References . . . . . . . . . . . . . . . . . . . . . . . . 97
17.1 Normative References . . . . . . . . . . . . . . . . . . 97
17.2 Informational References . . . . . . . . . . . . . . . . 97
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 98
Intellectual Property and Copyright Statements . . . . . . . 100
1. Introduction 1. Introduction
Unlike wired network elements, Access Points (AP) require a set of Unlike wired network elements, Wireless Termination Points (WTPs)
management and control functions related to their primary task of require a set of management and control functions related to their
connecting the wireless and wired mediums. Today, protocols for primary task of connecting the wireless and wired mediums. Today,
managing APs are either Layer 2 specific or non-existent (if the APs protocols for managing WTPs are either Layer 2 specific or
are self-contained). The emergence of simple 802.11 APs that are non-existent (if the WTPs are self-contained). The emergence of
managed by a router or switch (also known as an Access Router, or AR) simple 802.11 WTPs that are managed by a WLAN appliance or switch
suggests that having a standardized, interoperable protocol could (also known as an Access Controller, or AC) suggests that having a
radically simplify the deployment and management of wireless standardized, interoperable protocol could radically simplify the
networks. In many cases the overall control and management functions deployment and management of wireless networks. In many cases the
themselves are generic and could apply to any wireless Layer 2 overall control and management functions themselves are generic and
protocol. Being independent of specific wireless Layer 2 could apply to any wireless Layer 2 protocol. Being independent of
technologies, such a protocol could better support interoperability specific wireless Layer 2 technologies, such a protocol could better
between Layer 2 devices and enable smoother intertechnology support interoperability between Layer 2 devices and enable smoother
handovers. intertechnology handovers.
The details of how these functions would be implemented are dependent The details of how these functions would be implemented are dependent
on the particular Layer 2 wireless technology. Such a protocol would on the particular Layer 2 wireless technology. Such a protocol would
need provisions for binding to specific technologies. need provisions for binding to specific technologies.
LWAPP assumes a network configuration that consists of multiple APs LWAPP assumes a network configuration that consists of multiple WTPs
communicating either via layer 2 (MAC) or layer 3 (IP) to an AR. The communicating either via layer 2 (MAC) or layer 3 (IP) to an AC. The
AP can be considered as remote RF interfaces, being controlled by the WTP can be considered as remote RF interfaces, being controlled by
AR. The AR forwards all L2 frames it wants to transmit to an AP via the AC. The AC forwards all L2 frames it wants to transmit to an WTP
the LWAPP protocol. Packets from mobile nodes are forwarded by the via the LWAPP protocol. Packets from mobile nodes are forwarded by
AP to the AR, also via this protocol. Figure 1illustrates this the WTP to the AC, also via this protocol. Figure 1 illustrates this
arrangement as applied to an IEEE 802.11 binding. arrangement as applied to an IEEE 802.11 binding.
+-+ 802.11frames +-+ +-+ 802.11frames +-+
| |--------------------------------| | | |--------------------------------| |
| | +-+ | | | | +-+ | |
| |--------------| |---------------| | | |--------------| |---------------| |
| | 802.11 PHY/ | | LWAPP | | | | 802.11 PHY/ | | LWAPP | |
| | MAC sublayer | | | | | | MAC sublayer | | | |
+-+ +-+ +-+ +-+ +-+ +-+
STA AP AR STA WTP AC
Figure 1: LWAPP Architecture Figure 1: LWAPP Architecture
Security is another aspect of Access Point management that is not Security is another aspect of Wireless Termination Point management
well served by existing solutions. Provisioning APs with security that is not well served by existing solutions. Provisioning WTPs
credentials, and managing which APs are authorized to provide service with security credentials, and managing which WTPs are authorized to
are today handled by proprietary solutions. Allowing these functions provide service are today handled by proprietary solutions. Allowing
to be performed from a centralized router or switch in an these functions to be performed from a centralized AC in an
interoperable fashion increases managability and allows network interoperable fashion increases managability and allows network
operators to more tightly control their wireless network operators to more tightly control their wireless network
infrastructure. infrastructure.
This document describes the Light Weight Access Point Protocol This document describes the Light Weight Access Point Protocol
(LWAPP), allowing an AR to manage a collection of APs. The protocol (LWAPP), allowing an AC to manage a collection of WTPs. The protocol
is defined to be independent of Layer 2 technology, but an 802.11 is defined to be independent of Layer 2 technology, but an 802.11
binding is provided for use in growing 802.11 wireless LAN networks. binding is provided for use in growing 802.11 wireless LAN networks.
Goals Goals
The following are goals for this protocol: The following are goals for this protocol:
1. Centralization of the bridging, forwarding, authentication, 1. Centralization of the bridging, forwarding, authentication and
encryption and policy enforcement functions for a wireless policy enforcement functions for a wireless network. Optionally,
network. This will permit reduced cost and higher efficiency when the AC may also provide centralized encryption of user traffic.
applying the capabilities of network processing silicon to the This will permit reduced cost and higher efficiency when applying
wireless network, as it has already been applied to wired LANs. the capabilities of network processing silicon to the wireless
network, as it has already been applied to wired LANs.
2. Permit shifting of the higher level protocol processing burden 2. Permit shifting of the higher level protocol processing burden
away from the AP. This leaves the computing resource of the AP to away from the WTP. This leaves the computing resource of the WTP
the timing critical applications of wireless control and access. to the timing critical applications of wireless control and
This makes the most efficient use of the computing power available access. This makes the most efficient use of the computing power
in APs that are the subject of severe cost pressure. available in WTPs that are the subject of severe cost pressure.
3. Providing a generic encapsulation and transport mechanism, the 3. Providing a generic encapsulation and transport mechanism, the
protocol may be applied to other access point protocols in the protocol may be applied to other access point protocols in the
future by adding the binding. future by adding the binding.
The LWAPP protocol concerns itself solely on the interface between The LWAPP protocol concerns itself solely on the interface between
the AP and the AR. Inter-AR, or mobile to AR communication is the WTP and the AC. Inter-AC, or mobile to AC communication is
strictly outside the scope of this document. strictly outside the scope of this document.
1.1 Conventions used in this document 1.1 Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [7]. document are to be interpreted as described in RFC 2119 [1].
2. Protocol Overview 2. Protocol Overview
LWAPP is a generic protocol defining how Access Points communicate LWAPP is a generic protocol defining how Wireless Termination Points
with Access Routers. Access Points and Access Routers may communicate with Access Controllers. Wireless Termination Points and
communicate either by means of Layer 2 protocols or by means of a Access Controllers may communicate either by means of Layer 2
routed IP network. protocols or by means of a routed IP network.
LWAPP messages and procedures defined in this document apply to both LWAPP messages and procedures defined in this document apply to both
types of transports unless specified otherwise. Transport types of transports unless specified otherwise. Transport
independence is achieved by defining formats for both MAC level and independence is achieved by defining formats for both MAC level and
IP level transport (see Section 7). Also defined are framing, IP level transport (see Section 3). Also defined are framing,
fragmentation/reassembly, and multiplexing services to LWAPP for each fragmentation/reassembly, and multiplexing services to LWAPP for each
transport type. transport type.
The LWAPP Transport layer carries two types of payload. LWAPP Data
Messages are forwarded wireless frames. LWAPP Control Messages are
management messages exchanged between an WTP and is AC. The LWAPP
transport header defines the "C-bit", which is used to distinguish
data and control traffic. When used over IP, the LWAPP data and
control traffic are also sent over separate UDP ports. Since both
data and control frames can exceed PMTU, the payload of an LWAPP data
or control message can be fragmented. The fragmentation behavior is
highly dependent upon the lower layer transport and is defined in
Section 3.
Layer 2 LWAPP Data Frame
+-----------------------------------------------------------+
| MAC Header | LWAPP Header [C=0] | Forwarded Data ... |
+-----------------------------------------------------------+
Layer 3 LWAPP Data Frame
+--------------------------------------------+
| MAC Header | IP | UDP | LWAPP Header [C=0] |
+--------------------------------------------+
|Forwarded Data ... |
+-------------------+
Layer 2 LWAPP Control Frame
+---------------------------------------------------+
| MAC Header | LWAPP Header [C=1] | Control Message |
+---------------------------------------------------+
| Message Elements ... |
+----------------------+
Layer 3 LWAPP Control Frame
+--------------------------------------------+
| MAC Header | IP | UDP | LWAPP Header [C=1] |
+--------------------------------------------+
| Control Message | Message Elements ... |
+-----------------+----------------------+
The Light Weight Access Protocol (LWAPP) begins with a discovery The Light Weight Access Protocol (LWAPP) begins with a discovery
phase. The APs send a Discovery Request frame, causing any Access phase. The WTPs send a Discovery Request frame, causing any Access
Router (AR) [8], receiving that frame to respond with a Discovery Controller (AC) , receiving that frame to respond with a Discovery
Reply. From the Discovery Replies received, an AP will select an AR Response. From the Discovery Responses received, an WTP will select
with which to associate, using the Join Request and Join Reply. The an AC with which to associate, using the Join Request and Join
Join Request also provides an MTU discovery mechanism, to determine Response. The Join Request also provides an MTU discovery mechanism,
whether there is support for the transport of large frames between to determine whether there is support for the transport of large
the AP and it's AR. If support for large frames is not present, the frames between the WTP and it's AC. If support for large frames is
LWAPP frames will be fragmented to the maximum length discovered to not present, the LWAPP frames will be fragmented to the maximum
be supported by the layer 2 network. length discovered to be supported by the network.
Once the AP and the AR have joined, a configuration exchange is Once the WTP and the AC have joined, a configuration exchange is
accomplished that will cause both devices to agree on version accomplished that will cause both devices to agree on version
information. During this exchange the AP may receive provisioning information. During this exchange the WTP may receive provisioning
settings. For the 802.11 binding, this information would typically settings. For the 802.11 binding, this information would typically
include a name (802.11 Service Set Identifier, SSID), and security include a name (802.11 Service Set Identifier, SSID), and security
parameters, the data rates to be advertised as well as the radio parameters, the data rates to be advertised as well as the radio
channel (channels, if the AP is capable of operating more than one channel (channels, if the WTP is capable of operating more than one
802.11 MAC and PHY simultaneously) to be used. Finally, the APs are 802.11 MAC and PHY simultaneously) to be used. Finally, the WTPs are
enabled for operation. enabled for operation.
When the AP and AR have completed the version and provision exchange When the WTP and AC have completed the version and provision exchange
and the AP is enabled, the LWAPP encapsulates the 802.11 frames sent and the WTP is enabled, the LWAPP encapsulates the wireless frames
between them. LWAPP will fragment its packets, if the size of the sent between them. LWAPP will fragment its packets, if the size of
encapsulated 802.11 Data or Management frames causes the resultant the encapsulated wireless user data (Data) or protocol control
LWAPP packet to exceed the MTU supported between the AP and AR. (Management) frames causes the resultant LWAPP packet to exceed the
Fragmented LWAPP packets are reassembled to reconstitute the original MTU supported between the WTP and AC. Fragmented LWAPP packets are
encapsulated payload. reassembled to reconstitute the original encapsulated payload.
In addition to the functions thus far described, LWAPP also provides In addition to the functions thus far described, LWAPP also provides
for the delivery of commands from the AR to the AP for the management for the delivery of commands from the AC to the WTP for the
of devices that are communicating with the AP. This may include the management of devices that are communicating with the WTP. This may
creation of local data structures in the AP for the managed devices include the creation of local data structures in the WTP for the
and the collection of statistical information about the communication managed devices and the collection of statistical information about
between the AP and the 802.11 devices. LWAPP provides the ability the communication between the WTP and the 802.11 devices. LWAPP
for the AR to obtain any statistical information collected by the AP. provides the ability for the AC to obtain any statistical information
collected by the WTP.
LWAPP also provides for a keep alive feature that preserves the LWAPP also provides for a keep alive feature that preserves the
communication channel between the AP and AR. If the AR fails to communication channel between the WTP and AC. If the AC fails to
appear alive, the AP will try to discover a new AR to communicate appear alive, the WTP will try to discover a new AC to communicate
through. through.
3. Definitions This Document uses terminology defined in [5]
This Document uses terminology defined in [8]
3.1 Wireless Binding Definition 2.1 Wireless Binding Definition
This draft standard specifies a protocol independent of a specific This draft standard specifies a protocol independent of a specific
wireless access point radio technology. Elements of the protocol are wireless access point radio technology. Elements of the protocol are
designed to accommodate specific needs of each wireless technology in designed to accommodate specific needs of each wireless technology in
a standard way. Implementation of this standard for a particular a standard way. Implementation of this standard for a particular
wireless technology must follow the binding requirements defined for wireless technology must follow the binding requirements defined for
that technology. that technology. This specification includes a binding for the IEEE
802.11 (see Section 11).
3.2 LWAPP State Machine Definition When defining a bindings for other technologies, the authors MUST
include any necessary definitions for technology-specific messages
and all technology-specific message elements for those messages. At
a minimum, a binding MUST provide definition of binding-specific
Statistics message element, which is carried in the WTP Event Request
message, and Add Mobile message element, which is carried in the
Mobile Configure Request. If any technology specific message
elements are required for any of the existing LWAPP messages defined
in this specification, they MUST also be defined in the technology
binding document.
The following state diagram represents the lifecycle of an AP-AR The naming of binding-specific message elements MUST begin with the
name of the technology type, e.g., the binding for IEEE 802.11,
provided in this standard, begins with "IEEE 802.11"."
2.2 LWAPP State Machine Definition
The following state diagram represents the lifecycle of an WTP-AC
session: session:
+------+(--------------------------------\ /-------------\
| Idle | | | v
+------+ | | +------+
/ +---------+--)+------------+ | | C| Idle |<-------------------------------------\
/ | Run | | Key Update | | | +------+<--------------------------\ |
v +---------+(--+------------+ | | ^ | ^ | |
+-----------+ ^ | | | | | | \---------------\ | |
| Discovery | | v \----------->+-------+ | | | | | |
+-----------+ +-----------+ | Reset | | / | +---------+-->+------------+ |
| ^ \ /--)| Configure | +-------+ | / | C| Run | | Key Update | |
v | \ / +-----------+ ^ | / | +---------+<--+------------+ |
+---------+ v / | | / v | ^ | | |
| Sulking | +------+ +------------+ | | | +-----------+ | | | v |
+---------+ | Join |------------)| Image Data |--/ | | C| Discovery |<--------/ | \------------>+-------+
+------+ +------------+ | | +-----------+ +-----------+ | Reset |
| | | \ ^ /-->| Configure |------->+-------+
| | v \ \ / +-----------+ ^
| +---------+ v \ / |
| C| Sulking | +------+ |
| +---------+ C| Join |----------------------\ |
| +------+ v |
\ | +------------+
\-----------------/ C| Image Data |
+------------+
Figure 2: LWAPP State Machine Figure 3: LWAPP State Machine
Each of the states above correspond to an LWAPP control message type, The LWAPP state machine, depicted above, is used by both the AC and
defined later in this document. the WTP. For every state defined, only certain messages are
permitted to be sent and received. In all of the LWAPP control
messages defined in this specification, the specific state for which
they are valid is specified.
Note that in the state diagram figure above, the 'C' character is
used to represent a condition that causes the state to remain the
same.
The following text discusses the various state transitions, and the
events that cause them.
Idle to Discovery: This is the initialization state.
WTP: The WTP enters the Discovery state prior to transmitting the
first Discovery Request (see Section 5.1). Upon entering this
state, the WTP sets the DiscoveryInterval timer (see
Section 12). The WTP resets the DiscoveryCount counter to zero
(0) (see Section 13). The WTP also clears all information from
ACs (e.g., AC Addresses) it may have received during a previous
Discovery phase.
AC: The AC does not need to maintain state information for the WTP
upon reception of the Discovery Request, but it MUST respond
with a Discovery Response (see Section 5.2).
Discovery to Discovery: This is the state the WTP uses to determine
which AC it wishes to connect to.
WTP: This event occurs when the DiscoveryInterval timer expires.
The WTP transmits a Discovery Request to every AC which the WTP
hasn't received a response to. For every transition to this
event, the WTP increments DisoveryCount counter. See
Section 5.1) for more information on how the WTP knows which
ACs it should transmit the Discovery Requests to. The WTP
restarts the DiscoveryInterval timer.
AC: This is a noop.
Discovery to Sulking: This state occurs on a WTP when Discovery or
connectivity to the AC fails.
WTP: The WTP enters this state when the DiscoveryInterval timer
expires and the DiscoveryCount variable is equal to the
MaxDiscoveries variable (see Section 13). Upon entering this
state, the WTP will start the SilentInterval timer. While in
the Sulking state, all LWAPP messages received are ignored.
AC: This is a noop.
Sulking to Idle: This state occurs on a WTP when it must restart the
discovery phase.
WTP: The WTP enters this state when the SilentInterval timer (see
Section 12) expires.
AC: This is a noop.
Discovery to Join: This state is used by the WTP to confirm its
commitment to an AC that it wishes to be provided service.
WTP: The WTP selects the best AC based on the information it
gathered during the Discovery Phase. It then transmits a Join
Request (see Section 6.1 to its preferred AC. The WTP starts
the WaitJoin Timer (see Section 12).
AC: The AC enters this state for the given WTP upon reception of a
Join Request. The WTP processes the request and responds with
a Join Response.
Join to Join: This state transition during the join phase.
WTP: The WTP enters this state when the WaitJoin timer expires,
and the underlying transport requires LWAPP MTU detection
Section 3).
AC: This state occurs when the AC receives a retransmission of a
Join Request. The WTP processes the request and responds with
the Join Response..
Join to Idle: This state is used when the join process failed.
WTP: This state transition is invalid.
AC: The AC enters this state when it transmits an unsuccessful
Join Response.
Join to Discovery: This state is used when the join process failed.
WTP: The WTP enters this state when it receives an unsuccessful
Join Response. Upon entering this state, the WTP sets the
DiscoveryInterval timer (see Section 12). The WTP resets the
DiscoveryCount counter to zero (0) (see Section 13).
AC: This state transition is invalid.
Join to Configure: This state is used by the WTP and the AC to
exchange configuration information.
WTP: The WTP enters this state when it receives a successful Join
Response, and determines that its version number and the
version number advertised by the AC are the same. The WTP
transmits the Configure Request (see Section 7.1) message to
the AC with a snapshot of its current configuration. The WTP
also starts the ResponseTimeout timer (see Section 12).
AC: This state transition transition occurs when the AC receives
the Configure Request from the WTP. The AC must transmit a
Configure Response (see Section 7.2) to the WTP, and may
include specific message elements to override the WTP's
configuration.
Join to Image Data: This state is used by the WTP and the AC to
download executable firmware.
WTP: The WTP enters this state when it receives a successful Join
Response, and determines that its version number and the
version number advertised by the AC are different. The WTP
transmits the Image Data Request (see Section 8.1) message
requesting that the AC's latest firmware be initiated.
AC: This state transition transition occurs when the AC receives
the Image Data Request from the WTP. The AC must transmit a
Image Data Response (see Section 8.2) to the WTP, which
includes a portion of the firmware.
Image Data to Image Data: This state is used by WTP and the AC during
the firmware download phase.
WTP: The WTP enters this state when it receives a Image Data
Response that indicates that the AC has more data to send.
AC: This state transition transition occurs when the AC receives
the Image Data Request from the WTP while already in this
state, and it detects that the firmware download has not
completed.
Image Data to Reset: This state is used when the firmware download is
completed.
WTP: The WTP enters this state when it receives a Image Data
Response that indicates that the AC has no more data to send,
or if the underlying LWAPP transport indicates a link failure.
At this point, the WTP reboots itself.
AC: This state transition occurs when the AC receives the Image
Data Request from the WTP while already in this state, and it
detects that the firmware download has completed, or if the
underlying LWAPP transport indicates a link failure. Note that
the AC itself does not reset, but it places the specific WTPs
context it is communicating with in the reset state, meaning
that it clears all state associated with the WTP.
Configure to Reset: This state transition occurs if the Configure
phase fails.
WTP: The WTP enters this state when the reliable transport fails
to deliver the Configure Request, or if the ResponseTimeout
Timer (see Section 12)expires.
AC: This state transition occurs if the AC is unable to transmit
the Configure Response. Note that the AC itself does not
reset, but it places the specific WTPs context it is
communicating with in the reset state, meaning that it clears
all state associated with the WTP.
Configure to Run: This state transition occurs when the WTP and AC
enters their normal state of operation.
WTP: The WTP enters this state when it receives a successful
Configure Response from the AC. The WTP initializes the
HeartBeat Timer (see Section 12), and transmits the Change
State Event Request message (see Section 7.5).
AC: This state transition occurs when the AC receives the Change
State Event Request (see Section 7.5) from the WTP. The AC
responds with a Change State Event Response (see Section 7.6)
message. The AC must start the Session ID and Neighbor Dead
timers (see Section 12).
Run to Run: This is the normal state of operation.
WTP: This is the WTP's normal state of operation, and there are
many events that cause this to occur:
Configuration Update: The WTP receives a Configuration Update
Request (see Section 7.3). The WTP MUST respond with a
Configuration Update Response (see Section 7.4).
Change State Event: The WTP receives a Change State Event
Response, or determines that it must initiate a Change State
Event Request, as a result of a failure or change in the
state of a radio.
Echo Request: The WTP receives an Echo Request message
Section 6.3), which it MUST respond with an Echo Response
(see Section 6.4).
Clear Config Indication: The WTP receives a Clear Config
Indication message Section 7.7). The WTP MUST reset its
configuration back to manufacturer defaults.
WTP Event: The WTP generates a WTP Event Request to send
information to the AC Section 8.5). The WTP receives a WTP
Event Response from the AC Section 8.6).
Data Transfer: The WTP generates a Data Transfer Request to the
AC Section 8.7). The WTP receives a Data Transfer Response
from the AC Section 8.8).
WLAN Config Request: The WTP receives an WLAN Config Request
message Section 11.4.1), which it MUST respond with an WLAN
Config Response (see Section 11.4.2).
Mobile Config Request: The WTP receives an Mobile Config
Request message Section 9.1), which it MUST respond with an
Mobile Config Response (see Section 9.2).
AC: This is the AC's normal state of operation, and there are many
events that cause this to occur:
Configuration Update: The AC sends a Configuration Update
Request (see Section 7.3) to the AP to update its
configuration. The AC receives a Configuration Update
Response (see Section 7.4) from the WTP.
Change State Event: The AC receives a Change State Event
Request (see Section 7.5), which it MUST respond to with the
Change State Event Response (see Section 7.6).
Echo: The AC sends an Echo Request message Section 6.3) or
receives the associated Echo Response (see Section 6.4) from
the WTP.
Clear Config Indication: The AC sends a Clear Config Indication
message Section 7.7).
WLAN Config: The AC sends an WLAN Config Request message
Section 11.4.1) or receives the associated WLAN Config
Response (see Section 11.4.2) from the WTP.
Mobile Config: The AC sends an Mobile Config Request message
Section 9.1) or receives the associated Mobile Config
Response (see Section 9.2) from the WTP.
Data Transfer: The AC receives a Data Transfer Request from the
AC (see Section 8.7) and MUST generate the associated Data
Transfer Response message (see Section 8.8).
WTP Event: The AC receives a WTP Event Request from the AC (see
Section 8.5) and MUST generate the associated WTP Event
Response message (see Section 8.6).
Run to Reset: This event occurs when the AC wishes for the WTP re
reboot.
WTP: The WTP enters this state when it receives a Reset Request
(see Section 8.3). It must respond with a Reset Response (see
Section 8.4), and once the reliable transport acknowledgement
has been received, it must reboot itself.
AC: This state transition occurs either through some
administrative action, or via some internal event on the AC
that causes it to request that the WTP disconnect. Note that
the AC itself does not reset, but it places the specific WTPs
context it is communicating with in the reset state.
Run to Idle: This event occurs when an error occurs in the
communication between the WTP and the AC.
WTP: The WTP enters this state when the underlying reliable
transport in unable to transmit a message within the
RetransmitInterval timer (see Section 12), and the maximum
number of RetransmitCount counter has reached the MaxRetransmit
variable (see Section 13).
AC: The AC enters this state when the underlying reliable
transport in unable to transmit a message within the
RetransmitInterval timer (see Section 12), and the maximum
number of RetransmitCount counter has reached the MaxRetransmit
variable (see Section 13).
Run to Key Update: This event occurs when the WTP and the AC are to
exchange new keying material, with which it must use to protect
all future messages.
WTP: This state transition occurs when the KeyLifetime timer
expires (see Section 12).
AC: The WTP enters this state when it receives a Key Update
Request (see Section 6.5). It must create new keying material
and include it in the Key Update Response (see Section 6.6).
Key Update to Run: This event occurs when the key exchange phase is
completed.
WTP: This state transition occurs when the AC receives the Key
Update Response. The WTP must plumb the new keys in its crypto
module, allowing it to communicate with the AC using the new
key.
AC: The WTP enters this state when it transmits the Key Update
Response message. The key is then plumbed into its crypto
module, allowing it to communicate with the WTP using the new
key.
3. LWAPP Transport Layers
The LWAPP protocol can operate at layer 2 or 3. For layer 2 support,
the LWAPP messages are carried in a native Ethernet frame. As such,
the protocol is not routable and depends upon layer 2 connectivity
between the WTP and the AC. Layer 3 support is provided by
encapsulating the LWAPP messages within UDP.
3.1 LWAPP Transport Header
All LWAPP protocol packets are encapsulated using a common header
format, regardless of the transport used to carry the frames.
However, certain flags are not applicable for a given transport, and
it is therefore necessary to refer to the specific transport section
in order to determine which flags are valid.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER| RID |C|F|L| Frag ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status/WLANs | Payload... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3.1.1 VER Field
A 2 bit field which contains the version of LWAPP used in this
packet. The value for this draft is 0.
3.1.2 RID Field
A 3 bit field which contains the Radio ID number for this packet.
WTPs with multiple radios but a single MAC Address use this field to
indicate which radio is associated with the packet.
3.1.3 C Bit
The C bit indicates whether this packet carries a data message or a
control message. When this bit is 0, the packet carries an LWAPP
data message in the payload. When this bit is 1, the packet carries
an LWAPP control messwage as defined in section 4 for consumption by
the addressed destination.
3.1.4 F Bit
The F bit indicates whether this packet is a fragment. When this bit
is 1, the packet is a fragment and MUST be combined with the other
corresponding fragments to reassemble the complete information
exchanged between the WTP and AC.
3.1.5 L Bit
The L bit is valid only if the 'F' bit is set and indicates whether
the packet contains the last fragment of a fragmented exchange
between WTP and AC. When this bit is 1, the packet is not the last
fragment. When this bit is 0, the packet is the last fragment.
3.1.6 Fragment ID
An 8 bit field whose value is assigned to each group of fragments
making up a complete set. The value of Fragment ID is incremented
with each new set of fragments. The Fragment ID wraps to zero after
the maximum value has been used to identify a set of fragments.
LWAPP only supports up to 2 fragments per frame.
3.1.7 Length
The 16 bit length field contains the number of bytes in the Payload.
The field is encoded as an unsigned number.
3.1.8 Status and WLANS
The interpretation of this 16 bit field is binding specific. Refer
to the transport portion of the binding for a wireless technology for
the specification.
3.1.9 Payload
This field contains the header for an LWAPP Data Message or LWAPP
Control Message, followed by the data associated with that message.
3.2 Using IEEE 802.3 MAC as LWAPP transport
This section describes how the LWAPP protocol is provided over native
ethernet frames. An LWAPP packet is formed from the MAC frame header
followed by the LWAPP message header.
3.2.1 Framing
Source Address
A MAC address belonging to the interface from which this message is
sent. If multiple source addresses are configured on an interface,
then the one chosen is implementation dependent.
Destination Address
A MAC address belonging to the interface to which this message is to
be sent. This destination address MAY be either an individual
address or a multicast address, if more than one destination
interface is intended.
Ethertype
The Ethertype field is set to 0x88bb.
3.2.2 AC Discovery
When run over IEEE 802.3, LWAPP messages are distributed to a
specific MAC level broadcast domain. The AC discovery mechanism used
with this transport is for an WTP to transmit a Discovery Request
message to a broadcast destination MAC address. The ACs will receive
this message and reply based on their policy.
3.2.3 LWAPP Message Header format over IEEE 802.3 MAC transport
All of the fields described in Section 3.1 are used when LWAPP uses
the IEEE 802.3 MAC transport.
3.2.4 Fragmentation/Reassembly
Fragmentation at the MAC layer is managed using the F,L and Frag ID
fields of the LWAPP message header. The LWAPP protocol only allows a
single packet to be fragmented into 2, which is sufficient for a
frame that exceeds MTU due to LWAPP encapsulation. When used with
layer 2 (Ethernet) transport, both fragments MUST include the LWAPP
header.
3.2.5 Multiplexing
LWAPP control messages and data messages are distinguished by the C
Bit in the LWAPP message header.
3.3 Using IPv4/UDP as LWAPP transport
This section defines how LWAPP makes use of IPV4/UDP transport
between the WTP and the AC. When this transport is used, the MAC
layer is controlled by the IPv4 stack, and there are therefore no
special MAC layer requirements.
3.3.1 Framing
Communication between WTP and AC is established according to the
standard UDP client/server model. The connection is initiated by the
WTP (client) to the well-known UDP port of the AC (server) used for
control messages. This UDP port number of the AC is 12222 for LWAPP
data and 12223 for LWAPP control frames.
3.3.2 AC Discovery
When LWAPP is run over routed IPv4 networks, the WTP and the AC do
not need to reside in the same IP subnet (broadcast domain).
However, in the event the peers reside on separate subnets, there
must exist a mechanism for the WTP to discover the AC.
As the WTP attempts to establish communication with the AC, it sends
the Discovery Request message and receives the corresponding response
message from the AC. The WTP must send the Discovery Request message
to either the limited broadcast IP address (255.255.255.255), a well
known multicast address or to the unicast IP address of the AC. Upon
receipt of the message, the AC issues a Discovery Response message to
the unicast IP address of the WTP, regardless of whether Discovery
Request was sent as a broadcast, multicast or unicast message.
Whether the WTP uses a limited IP broadcast, multicast or unicast IP
address is implementation dependent.
In order for a WTP to transmit a Discovery Request to a unicast
address, the WTP must first obtain the IP address of the AC. Any
static configuration of an AC's IP address on the WTP non-volatile
storage is implementation dependent. However, additional dynamic
schemes are possible, for example:
DHCP: A comma delimited ASCII encoded list of AC IP addresses is
embedded inside a DHCP vendor specific option 43 extension. An
example of the actual format of the vendor specific payload is of
the form "LWAPP=10.1.1.1, 10.1.1.2".
DNS: The DNS name "LWAPP-AC-Address" MAY be resolvable to or more AC
addresses
3.3.3 LWAPP Message Header format over IPv4/UDP transport
All of the fields described in Section 3.1 are used when LWAPP uses
the IPv4/UDP transport, with the following exceptions:
3.3.3.1 F Bit
This flag field is not used with this transport, and MUST be set to
zero.
3.3.3.2 L Bit
This flag field is not used with this transport, and MUST be set to
zero.
3.3.3.3 Frag ID
This field is not used with this transport, and MUST be set to zero.
3.3.4 Fragmentation/Reassembly
When LWAPP is implemented at L3, the transport layer uses IP
fragmentation to fragment and reassemble LWAPP messages that are
longer than MTU size used by either WTP or AC. The details of IP
fragmentation are covered in [8]. When used with the IP transport,
only the first fragment would include the LWAPP header
[ed: IP fragmentation may raise security concerns and bring
additional configuration requirements for certain firewalls and NATs.
One alternative is to re-use the layer 2 (application layer)
fragmentation reassembly. Comments are welcomed.]
3.3.5 Multiplexing
LWAPP messages convey control information between WTP and AC, as well
as binding specific data frames or binding specific management
frames. As such, LWAPP messages need to be multiplexed in the
transport sub-layer and be delivered to the proper software entities
in the endpoints of the protocol. However, the 'C' bit is still used
to differentiate between data and control frames.
In case of Layer 3 connection, multiplexing is achieved by use of
different UDP ports for control and data packets (see Section 3.3.1.
As part of Join procedure, the WTP and AC may negotiate different IP
Addresses for data or control messages. The IP Address returned in
the AP Manager Control IP Address message element is used to inform
the WTP with the IP address to which it must sent all control frames.
The AP Manager Data IP Address message element MAY be present only if
the AC has a different IP Address which the WTP is to use to send its
data LWAPP frames.
In the event the WTP and AC are separated by a NAT, with the WTP
using private IP address space, it is the responsibility of the NAT
to manage appropriate UDP port mapping.
4. LWAPP Packet Definitions 4. LWAPP Packet Definitions
This section contains the packet types and format. The LWAPP This section contains the packet types and format. The LWAPP
protocol is designed to be transport agnostic by specifying packet protocol is designed to be transport agnostic by specifying packet
formats for both MAC frames and IP packets. An LWAPP packet consists formats for both MAC frames and IP packets. An LWAPP packet consists
of an LWAPP Transport Layer packet header followed by an LWAPP of an LWAPP Transport Layer packet header followed by an LWAPP
message. message.
Transport details can be found in Section 7. Transport details can be found in Section 3.
4.1 LWAPP Data Messages 4.1 LWAPP Data Messages
An LWAPP data message is a forwarded wireless frame. When forwarding An LWAPP data message is a forwarded wireless frame. When forwarding
wireless frames, LWAPP is light weight and encapsulates the frames wireless frames, the sender simply encapsulates the wireless frame in
only in the transport layer header. an LWAPP data packet, using the appropriate transport rules defined
in section Section 3.
In the event that the encapsulated frame would exceed the transport
layer's MTU, the sender is responsible for the fragmentation of the
frame, as specified in the transport specific section of Section 3.
The actual format of the encapsulated LWAPP data frame is subject to
the rules defined under the specific wireless technology binding.
4.2 LWAPP Control Messages Overview 4.2 LWAPP Control Messages Overview
The LWAPP Control protocol provides a control channel between the AP The LWAPP Control protocol provides a control channel between the WTP
and the AR. The control channel is the series of control messages and the AC. The control channel is the series of control messages
between the AP and AR, associated with a session ID and key. Control between the WTP and AC, associated with a session ID and key.
is divided into the following distinct message types. Control Control messages are divided into the following distinct message
Channel, AR Configuration and Mobile Session Management MUST be types:
implemented. Firmware Management MAY be implemented. Discovery: LWAPP Discovery messages are used to identify potential
ACs, their load and capabilities.
Control Channel Management: Messages that fall within this Control Channel Management: Messages that fall within this
classification are used for the discovery of ARs by the APs as classification are used for the discovery of ACs by the WTPs as
well as the establishment and maintenance of an LWAPP control well as the establishment and maintenance of an LWAPP control
channel. channel.
AR Configuration: The AR Configuration messages are used by the AR to WTP Configuration: The WTP Configuration messages are used by the AC
push a specific configuration to the APs it has a control channel to push a specific configuration to the WTPs it has a control
with. Messages that deal with the retrieval of statistics from channel with. Messages that deal with the retrieval of statistics
the AP also fall in this category. from the WTP also fall in this category.
Mobile Session Management: Mobile session management messages are Mobile Session Management: Mobile session management messages are
used by the AR to push specific mobile policies to the AP. used by the AC to push specific mobile policies to the WTP.
Firmware Management: Messages in this category are used by the AR to Firmware Management: Messages in this category are used by the AC to
push a new firmware image down to the AP. push a new firmware image down to the WTP.
Control Channel, WTP Configuration and Mobile Session Management MUST
be implemented. Firmware Management MAY be implemented.
In addition, technology specific bindings may introduce new control
channel commands that depart from the above list.
4.2.1 Control Message Format 4.2.1 Control Message Format
All LWAPP control messages are sent encapsulated within the LWAPP All LWAPP control messages are sent encapsulated within the LWAPP
header (see for example Section 7.1.5 and Section 7.2.5) with the header (see Section 3.1). Immediately following the header, is the
following header values: LWAPP control header, which has the following format:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Seq Num | Msg Element Length | | Message Type | Seq Num | Msg Element Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID | | Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Element [0..N] | | Msg Element [0..N] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.2.1.1 Message Type 4.2.1.1 Message Type
The Message Type field identifies the function of the LWAPP control The Message Type field identifies the function of the LWAPP control
message. The valid values for Message Type are the following: message. The valid values for Message Type are the following:
Description Value Description Value
Discovery Request 1 Discovery Request 1
Discovery Reply 2 Discovery Response 2
Join Request 3 Join Request 3
Join Reply 4 Join Response 4
Configure Request 5 Unused 5-9
Configure Response 6 Configure Request 10
Configuration Update Request 7 Configure Response 11
Configuration Update Response 8 Configuration Update Request 12
Statistics Report 9 Configuration Update Response 13
Statistics Report Response 10 WTP Event Request 14
Reserved 11-16 WTP Event Response 15
Echo Request 17 Change State Event Request 16
Echo Response 18 Change State Event Response 17
Image Data Request 19 Unused 18-21
Image Data Response 20 Echo Request 22
Reset Request 21 Echo Response 23
Reset Response 22 Image Data Request 24
Key Update Request 23 Image Data Response 25
Key Update Response 24 Reset Request 26
Reserved 25-26 Reset Response 27
Key Update Trigger 27 Unused 28-29
Key Update Request 30
Key Update Response 31
Primary Discovery Request 32
Primary Discovery Response 33
Data Transfer Request 34
Data Transfer Response 35
Clear Config Indication 36
WLAN Config Request 37
WLAN Config Response 38
Mobile Config Request 39
Mobile Config Response 40
4.2.1.2 Sequence Number 4.2.1.2 Sequence Number
The Sequence Number Field is an identifier value to match request/ The Sequence Number Field is an identifier value to match
response packet exchanges. When an LWAPP packet with a request request/response packet exchanges. When an LWAPP packet with a
message type is received, the value of the sequence number field is request message type is received, the value of the sequence number
copied into the corresponding response packet. field is copied into the corresponding response packet.
When an LWAPP control frame is sent, its internal sequence number
counter is monotonically incremented, ensuring that no two requests
pending have the same sequence number. This field will wrap back to
zero.
4.2.1.3 Message Element Length 4.2.1.3 Message Element Length
The Length field indicates the number of bytes following the Session The Length field indicates the number of bytes following the Session
ID field. ID field.
4.2.1.4 Session ID 4.2.1.4 Session ID
The Session ID is a 32-bit unsigned integer that is used to identify The Session ID is a 32-bit unsigned integer that is used to identify
the security context for encrypted exchanges between the AP and the the security context for encrypted exchanges between the WTP and the
AR. AC. Note that a Session ID is a random value that MUST be unique
between a given AC and any of the WTP it may be communicating with.
4.2.1.5 Message Element[0..N] 4.2.1.5 Message Element[0..N]
The message element(s) carry the information pertinent to each of the The message element(s) carry the information pertinent to each of the
control message types. The total length of the message elements is control message types. Every control message in this specification
indicated in the Message Element Length field. specifies which message elements are permitted.
4.2.2 Message Element Format
The message element is used to carry information pertinent to a
control message. Every message element is identified by the Type
field, whose numbering space is managed via IANA (see Section 15).
The total length of the message elements is indicated in the Message
Element Length field.
All of the message element definitions in this document use a diagram
similar to the one below in order to depict its format. Note that in
order to simplify this specification, these diagrams do not include
the header fields (Type and Length). However, in every message
element description, the header's fields values will be defined.
Note that additional message elements may be defined in separate IETF
documents.
The format of a message element uses the TLV format shown here: The format of a message element uses the TLV format shown here:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ... | | Type | Length | Value ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where Type (8 bit) identifies the character of the information Where Type (8 bit) identifies the character of the information
carried in the Value field and Length (16 bits) indicates the number carried in the Value field and Length (16 bits) indicates the number
of bytes in the Value field. of bytes in the Value field.
The LWAPP message elements are defined in Section 5 4.2.2.1 Generic Message Elements
4.3 Control Channel Management This section includes message elements that are not bound to a
specific control message.
The Control Channel Management messages are used by the AP and AR to 4.2.2.1.1 Vendor Specific
create and maintain a channel of communication on which various other
commands may be transmitted, such as configuration, firmware update,
etc.
4.3.1 Discovery Requests The Vendor Specific Payload is used to communicate vendor specific
information between the WTP and the AC. The value contains the
following format:
The Discovery Request is used by the AP to automatically discovery 0 1 2 3
potential ARs available in the network. An AP must transmit this 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
command even if it has a statically configured AR, as it is a +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
required step in the LWAPP state machine. | Vendor Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.1.1 Sending Discovery Requests Type: 104 for Vendor Specific
Length: >= 7
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI
Network Management Private Enterprise Codes" [9]
Element ID: A 16-bit Element Idenfier which is managed by the
vendor.
Value: The value associated with the vendor specific element.
Discovery Requests MUST be sent by an AP in the Discover state after 5. LWAPP Discovery Operations
The Discovery messages are used by an WTP to determine which ACs are
available to provide service, as well as the capabilities and load of
the ACs.
5.1 Discovery Request
The Discovery Request is used by the WTP to automatically discover
potential ACs available in the network. An WTP must transmit this
command even if it has a statically configured AC, as it is a
required step in the LWAPP state machine.
Discovery Requests MUST be sent by an WTP in the Discover state after
waiting for a random delay less than MaxDiscoveryInterval, after an waiting for a random delay less than MaxDiscoveryInterval, after an
AP first comes up or is (re)initialized. An AP MUST send no more WTP first comes up or is (re)initialized. An WTP MUST send no more
than a maximum of MaxDiscoveries discoveries, waiting for a random than a maximum of MaxDiscoveries discoveries, waiting for a random
delay less than MaxDiscoveryInterval between each successive delay less than MaxDiscoveryInterval between each successive
discovery. discovery.
This is to prevent an explosion of AP Discoveries. An example of This is to prevent an explosion of WTP Discoveries. An example of
this occurring would be when many APs are powered on at the same this occurring would be when many WTPs are powered on at the same
time. time.
Discovery requests MUST be sent by an AP when no echo responses are Discovery requests MUST be sent by an WTP when no echo responses are
received for NeighborDeadInterval and the AP returns to the discover received for NeighborDeadInterval and the WTP returns to the Idle
state. Discovery requests are sent after NeighborDeadInterval, they state. Discovery requests are sent after NeighborDeadInterval, they
MUST be sent after waiting for a random delay less than MUST be sent after waiting for a random delay less than
MaxDiscoveryInterval. An AP MAY send up to a maximum of MaxDiscoveryInterval. An WTP MAY send up to a maximum of
MaxDiscoveries discoveries, waiting for a random delay less than MaxDiscoveries discoveries, waiting for a random delay less than
MaxDiscoveryInterval between each successive discovery. MaxDiscoveryInterval between each successive discovery.
If a discovery response is not received after sending the maximum If a discovery response is not received after sending the maximum
number of discovery requests, the AP enters the Sulking state and number of discovery requests, the WTP enters the Sulking state and
MUST wait for an interval equal to SilentInterval before sending MUST wait for an interval equal to SilentInterval before sending
further discovery requests. further discovery requests.
The Discovery Request message may be sent as a unicast, broadcast or The Discovery Request message may be sent as a unicast, broadcast or
multicast message. multicast message.
TODO: Specify exponential backoff of discovery requests. Upon receiving a discovery request, the AC will respond with a
Discovery Response sent to the address in the source address of the
4.3.1.2 Format of a Discovery Request
The Discovery Request carries the following message elements:
AP
Radio Payload (one for each radio in the AP)
4.3.1.3 Receiving Discovery Requests
Upon receiving a discovery request, the AR will respond with a
Discovery Reply sent to the address in the source address of the
received discovery request. received discovery request.
4.3.2 Discovery Reply The following subsections define the message elements that MUST be
included in this LWAPP operation.
The Discovery Reply is a mechanism by which an AR advertises its
services to requesting APs.
4.3.2.1 Sending Discovery Replies
Discovery Replies are sent by an AR after receiving a Discovery
Request.
4.3.2.2 Format of a Discovery Reply
The Discovery Reply carries the following message elements:
AR
AR Name
4.3.2.3 Receiving Discovery Replies
When an AP receives a Discovery Reply, it MUST wait for an interval 5.1.1 Discovery Type
not less than DiscoveryInterval for receipt of additional discovery
replies. After the DiscoveryInterval elapses, the AP enters the
Joining state and will select one of the ARs that sent a discovery
reply and send a Join Request to that AR.
4.3.3 Join Request The Discovery message element is used to configure an WTP to operate
in a specific mode.
The Join Request is used by an AP to inform an AR that it wishes to 0
provide services through it. 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Discovery Type|
+-+-+-+-+-+-+-+-+
4.3.3.1 Sending Join Requests Type: 58 for Discovery Type
Length: 1
Discovery Type: An 8-bit value indicating how the AC was discovered.
The following values are supported:
0 - Broadcast
1 - Configured
Join Requests are sent by an AP in the Joining state after receiving 5.1.2 WTP Descriptor
one or more Discovery Replies. The Join Request is also used as an
MTU discovery mechanism by the AP. The AP issues a Join Request with
a Test message element, bringing the total size of the message to
exceed MTU.
The initial Join Request is padded with the Test message element to The WTP descriptor message element is used by the WTP to communicate
1596 bytes. If a Join Reply is received, the AP can forward frames it's current hardware/firmware configuration. The value contains the
without requiring any fragmentation. If no Join Reply is received, following fields.
it issues a second Join Request padded with the Test payload to a
total of 1500 bytes. The AP continues to cycle from large (1596) to
small (1500) packets until a Join Reply has been received, or until
both packets sizes have been retransmitted 3 times. If the Join
Reply is not received after the maximum number of retransmissions,
the AP MUST abandon the AR and restart the discovery phase.
4.3.3.2 Format of a Join Request 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Boot Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Encryption Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Join Request carries the following message elements: Type: 3 for WTP Descriptor
Length: 16
Hardware Version: A 32-bit integer representing the WTP's hardware
version number
Software Version: A 32-bit integer representing the WTP's Firmware
version number
Boot Version: A 32-bit integer representing the WTP's boot loader's
version number
Max Radios: An 8-bit value representing the number of radios (where
each radio is identified via the RID field) supported by the WTP
Radios in use: An 8-bit value representing the number of radios
present in the WTP
Encryption Capabilities: This 16-bit field is used by the WTP to
communicate it's capabilities to the AC. Since most WTPs support
link layer encryption, the AC may make use of these services.
There are binding dependent encryption capabilites. An WTP that
does not have any encryption capabilities would set this field to
zero (0). Refer to the specific binding for the specification.
AR Address 5.1.3 WTP Radio Information
AP Descriptor
AP Name Payload
Location Data
Radio Payload (one for each radio)
Certificate
Session ID
Test
4.3.3.3 Receiving Join Requests The WTP radios information message element is used to communicate the
radio information in a specific slot. The Discovery Request MUST
include one such message element per radio in the WTP. The
Radio-Type field is used by the AC in order to determine which
technology specific binding is to be used with the WTP.
When an AR receives a Join Request it will respond with a Join Reply. The value contains two fields, as shown.
The AR validates the certificate found in the request. If valid, the
AR generates a session key which will be used to secure the control
frames it exchanges with the AP. When the AR issues the Join Reply,
the AR creates a context for the session with the AP.
Details on the key generation is found in appendix A. 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Radio Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.3.4 Join Reply Type: 4 for WTP Radio Information
Length: 2
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP
Radio Type: The type of radio present. The following values are
supported
1 - 802.11bg: An 802.11bg radio.
2 - 802.11a: An 802.11a radio.
3 - 802.16: An 802.16 radio.
4 - Ultra Wideband: An UWB radio.
7 - all: Used to specify all radios in the WTP.
The Join Reply is sent by the AR to indicate to an AP whether it is 5.2 Discovery Response
capable and willing to provide service to it.
4.3.4.1 Sending Join Replies The Discovery Response is a mechanism by which an AC advertises its
services to requesting WTPs.
Join Replies are sent by the AR after receiving a Join Request. Once Discovery Responses are sent by an AC after receiving a Discovery
the Join Reply has been sent, the heartbeat timer is initiated for
the session. Expiration of the timer will result in delete of the
AR-AP session. The timer is refreshed upon receipt of the Echo
Request. Request.
4.3.4.2 Format of a Join Reply When an WTP receives a Discovery Response, it MUST wait for an
interval not less than DiscoveryInterval for receipt of additional
The Join Reply carries the following message elements: Discovery Responses. After the DiscoveryInterval elapses, the WTP
enters the Joining state and will select one of the ACs that sent a
Result Code Discovery Response and send a Join Request to that AC.
Certificate
Session Key
4.3.4.3 Receiving Join Replies
When an AP receives a Join Reply it enters the Joined state and
initiates the Configure Request to the AR to which it is now joined.
Upon entering the Joined state, the AP begins timing an interval
equal to NeighborDeadInterval. Expiration of the timer will result
in the transmission of the Echo Request.
4.3.5 Echo Request
The Echo Request message is a keepalive mechanism for the LWAPP
control message.
4.3.5.1 Sending Echo Requests
Echo Requests are sent by an AP in the Join or Run state to determine
the state of the connection between the AP and the AR.
4.3.5.2 Format of a Echo Request
The Echo Request carries no message elements.
4.3.5.3 Receiving Echo Requests
When an AR receives an Echo Request it responds with a Echo Response.
4.3.6 Echo Response
The Echo Response acknowledges the Echo Request.
4.3.6.1 Sending Echo Responses
Echo Responses are sent by an AR after receiving an Echo Request.
4.3.6.2 Format of a Echo Response
The Echo Response carries no message elements.
4.3.6.3 Receiving Echo Responses The following subsections define the message elements that MUST be
included in this LWAPP operation.
When an AP receives an Echo Response it resets the timer that is 5.2.1 AC Descriptor
timing the NeighborDeadInterval. If the NeighborDeadInterval timer
expires prior to receiving an Echo Response, the AP enters the
Discovery state.
4.3.7 Key Update Request The AC payload message element is used by the AC to communicate it's
current state. The value contains the following fields.
The Key Update Request updates the LWAPP session key used to secure 0 1 2 3
messages between the AP and the AR. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Hardware Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Ver | Software Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Ver | Stations | Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit | Radios | Max Radio |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radio |
+-+-+-+-+-+-+-+-+
4.3.7.1 Sending Key Update Requests Type: 6 for AC Descriptor
Length: 17
Reserved: MUST be set to zero
Hardware Version: A 32-bit integer representing the AC's hardware
version number
Software Version: A 32-bit integer representing the AC's Firmware
version number
Stations: A 16-bit integer representing number of mobile stations
currently associated with the AC
Limit: A 16-bit integer representing the maximum number of stations
supported by the AC
Radios: A 16-bit integer representing the number of WTPs currently
attached to the AC
Max Radio: A 16-bit integer representing the maximum number of WTPs
supported by the AC
Key Update Requests are sent by an AP in the Run state to update a 5.2.2 AC Name
session key. The Session ID message element MUST include a new
session identifier.
4.3.7.2 Format of a Key Update Request The AC name message element contains an ASCII representation of the
AC's identity. The value is a variable length byte string. The
string is NOT zero terminated.
The Key Update Request carries the following message elements: 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Name ...
+-+-+-+-+-+-+-+-+
Session ID Type: 31 for AC Name
Length: > 0
Name: A variable length ASCII string containing the AC's name
4.3.7.3 Receiving Key Update Requests 5.2.3 WTP Manager Control IP Address
When an AR receives a Key Update Request it generates a new key (see The WTP Manager Control IP Address message element is sent by the AC
appendix A) and responds with a Key Update Response. to the WTP during the discovery process and is used by the AC to
provide the interfaces available on the AC, and their current load.
This message elemenet is useful for the WTP to perform load balancing
across multiple interfaces.
4.3.8 Key Update Response 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WTP Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Key Update Response updates the LWAPP session key used to secure Type: 99 for WTP Manager Control IP Address
messages between the AP and the AR, and acknowledges the Key Update Length: 6
Request. IP Address: The IP Address of an interface.
WTP Count: The number of WTPs currently connected to the interface.
4.3.8.1 Sending Key Update Responses 5.3 Primary Discovery Request
Key Update Responses are sent by a AR after receiving a Key Update The Primary Discovery Request is sent by the WTP in order to
Request. The Key Update Responses is secured using public key determine whether its preferred (or primary) AC is available.
cryptography.
4.3.8.2 Format of a Key Update Response Primary Discovery Request are sent by an WTP when it has a primary AC
configured, and is connected to another AC. This generally occurs as
a result of a failover, and is used by the WTP as a means to discover
when its primary AC becomes available. As a consequence, this
message is only sent by a WTP when it is in the Run state.
The Key Update Response carries the following message elements: The frequency of the Primary Discovery Requests should be no more
often than the sending of the Echo Request message.
Session Key Upon receiving a discovery request, the AC will respond with a
Primary Discovery Response sent to the address in the source address
of the received Primary Discovery Request.
4.3.8.3 Receiving Key Update Responses The following subsections define the message elements that MUST be
included in this LWAPP operation.
When an AP receives a Key Update Response it will use the information 5.3.1 Discovery Type
contained in the Session Key message element to determine the keying
material used to encrypt the LWAPP communications between the AP and
the AR.
4.3.9 Key Update Trigger The Discovery Type message element is defined in section
Section 5.1.1.
The Key Update Trigger is used by the AR to request that a Key Update 5.3.2 WTP Descriptor
Request be initiated by the AP.
4.3.9.1 Sending Key Update Trigger The WTP Descriptor message element is defined in section
Section 5.1.2.
Key Update Requests are sent by an AR in the Run state to inform the 5.3.3 WTP Radio Information
AP to initiate a Key Update Request message.
4.3.9.2 Format of a Key Update Trigger An WTP Radio Information message element must be present for every
radio in the WTP. This message element is defined in section
Section 5.1.3.
The Key Update Request carries the following message elements: 5.4 Primary Discovery Response
Session ID The Primary Discovery Response is a mechanism by which an AC
advertises its availability and services to requesting WTPs that are
configured to have the AC as its primary AC.
4.3.9.3 Receiving Key Update Trigger Primary Discovery Responses are sent by an AC after receiving a
Primary Discovery Request.
When a AP receives a Key Update Trigger it generates a key Update When an WTP receives a Primary Discovery Response, it may opt to
Request. establish an LWAPP connection to its primary AC, based on the
configuration of the WTP Fallback Status message element on the WTP.
4.4 AR Configuration The following subsections define the message elements that MUST be
included in this LWAPP operation.
The AR Configuration messages serve two purposes. They are used to 5.4.1 AC Descriptor
exchange configuration between AR and AP. Thy are also used by the
AR to retrieve statistics from the AP.
4.4.1 Configure Request The Discovery Type message element is defined in section
Section 5.2.1.
The Configure Request message is sent by an AP to send its current 5.4.2 AC Name
configuration to its AR.
4.4.1.1 Sending Configure Requests The AC Name message element is defined in section Section 5.2.2.
Configure Requests are sent by an AP after receiving a Join Reply. 5.4.3 WTP Manager Control IP Address
4.4.1.2 Format of a Configure Request An WTP Radio Information message element must be present for every
radio in the WTP. This message element is defined in section
Section 5.2.3.
The Configure Request carries binding specific message elements. 6. Control Channel Management
Refer to the appropriate binding for the definition of this
structure.
4.4.1.3 Receiving Configure Requests The Control Channel Management messages are used by the WTP and AC to
create and maintain a channel of communication on which various other
commands may be transmitted, such as configuration, firmware update,
etc.
When an AR receives a Configure Request it will act upon the content 6.1 Join Request
of the packet and respond to the AP with a Configure Response.
4.4.2 Configure Response The Join Request is used by an WTP to inform an AC that it wishes to
provide services through it.
The Configure Response message is sent by an AR and provides an Join Requests are sent by an WTP in the Joining state after receiving
opportunity for the AR to override an AP's requested configuration. one or more Discovery Responses. The Join Request is also used as an
MTU discovery mechanism by the WTP. The WTP issues a Join Request
with a Test message element, bringing the total size of the message
to exceed MTU.
4.4.2.1 Sending Configure Responses If the transport used does not provide MTU path discovery, the
initial Join Request is padded with the Test message element to 1596
bytes. If a Join Response is received, the WTP can forward frames
without requiring any fragmentation. If no Join Response is
received, it issues a second Join Request padded with the Test
payload to a total of 1500 bytes. The WTP continues to cycle from
large (1596) to small (1500) packets until a Join Response has been
received, or until both packets sizes have been retransmitted 3
times. If the Join Response is not received after the maximum number
of retransmissions, the WTP MUST abandon the AC and restart the
discovery phase.
Configure Responses are sent by an AR after receiving a Configure When an AC receives a Join Request it will respond with a Join
Request. Response. The AC validates the certificate found in the request. If
valid, the AC generates a session key which will be used to secure
the control frames it exchanges with the WTP. When the AC issues the
Join Response, the AC creates a context for the session with the WTP.
4.4.2.2 Format of a Configure Response Details on the key generation is found in Section 10.
The Configure Response carries binding specific message elements. The following subsections define the message elements that MUST be
Refer to the appropriate binding for the definition of this included in this LWAPP operation.
structure.
4.4.2.3 Receiving Configure Responses 6.1.1 AC Address
When an AP receives a Configure Response it acts upon the content of The AC address message element is used to communicate the identity of
the packet, as appropriate. the AC. The value contains two fields, as shown.
4.4.3 Configuration Update Request 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Configuration Update Request is a message initiated by the AR to Type: 2 for AC Address
update the configuration of an AP while in the Run state. Length: 7
Reserved: MUST be set to zero
Mac Address: The MAC Address of the AC
4.4.3.1 Sending Configuration Update Requests 6.1.2 WTP Descriptor
Configure Update Requests are sent by the AR to provision the AP The WTP Descriptor message element is defined in section
while in the Run state. This is used to modify the configuration of Section 5.1.2.
the AP while it is operational.
4.4.3.2 Format of a Configure Update Request 6.1.3 WTP Name
The Configure Command Request carries any of the following message The WTP name message element value is a variable length byte string.
elements: The string is NOT zero terminated.
AP Name 4 0
Reserved 6 0 1 2 3 4 5 6 7
Rate Set 8 +-+-+-+-+-+-+-+-+
Multi-domain capability 9 | Name ...
MAC Operation 10 +-+-+-+-+-+-+-+-+
Reserved 11
Tx Power Level 12
Direct Sequence Control 13
OFDM Control 14
Supported Rates 15
Reserved 25
Administrative State 26
Delete WLAN 27
Reserved 28-29
Reserved 33
Location Data 34
Reserved 35
Statistics Timer 36
Session 44
WLAN Payload 50
Vendor Specific 51
Tx Power 52
Add Mobile 53
Delete Mobile 54
Mobile Session key 55
When an AR receives a Configuration Update Request it will respond Type: 5 for WTP Name
with a Configuration Update Reply, with the appropriate Result Code. Length: > 0
Name: A non zero terminated string containing the WTP's name.
4.4.3.3 Receiving Configuration Update Requests 6.1.4 Location Data
When an AR receives a Configuration Update Request it will respond The location data message element is a variable length byte string
with a Configuration Update Reply, with the appropriate Result Code. containing user defined location information (e.g. "Next to
Fridge"). The string is NOT zero terminated.
4.4.4 Configuration Update Response 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Location ...
+-+-+-+-+-+-+-+-+
Type: 35 for Location Data
Length: > 0
Location: A non zero terminated string containing the WTP's
location.
The Configuration Update Response is the acknowledgement message for 6.1.5 WTP Radio Information
the Configuration Update Request.
4.4.4.1 Sending Configuration Update Responses An WTP Radio Information message element must be present for every
radio in the WTP. This message element is defined in section
Section 5.1.3.
Configuration Update Responses are sent by an AP after receiving a 6.1.6 Certificate
Configuration Update Request.
4.4.4.2 Format of a Configuration Update Response The certificate message element value is a byte string containing a
DER-encoded x.509v3 certificate.
The Configuration Update Response carries the following message 0
elements: 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Certificate...
+-+-+-+-+-+-+-+-+
Result Code 1 Type: 44 for Certificate
Length: > 0
Certificate: A non zero terminated string containing the device's
certificate.
4.4.4.3 Receiving Configure Update Responses 6.1.7 Session ID
When an AR receives a Configure Update Response the result code The session ID message element value contains a randomly generated
indicates if the AP successfully accepted the configuration. [4] unsigned 32-bit integer.
4.4.5 Statistics Report 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Statistics Reports are used for statistics collection at the AR. Type: 45 for Session ID
Length: 4
Session ID: 32 bit random session identifier.
4.4.5.1 Sending Statistics Reports 6.1.8 Test
Statistics Reports are sent by an AP periodically, based on the The test message element is used as padding to perform MTU discovery,
configuration, to transfer statistics to the AR. and MAY contain any value, of any length.
4.4.5.2 Format of a Statistics Report 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Padding ...
+-+-+-+-+-+-+-+-+
The Statistics Report carries the following message elements: Type: 18 for Test
Length: > 0
Padding: A variable length pad.
Statistics 6.2 Join Response
When an AR receives a Statistics Report it will respond with a
Statistics Response.
4.4.5.3 Receiving Statistics Report The Join Response is sent by the AC to indicate to an WTP whether it
is capable and willing to provide service to it.
When an AR receives a Statistics Report it will respond with a Join Responses are sent by the AC after receiving a Join Request.
Statistics Response. Once the Join Response has been sent, the heartbeat timer is
initiated for the session to EchoInterval. Expiration of the timer
will result in deletion of the AC-WTP session. The timer is
refreshed upon receipt of the Echo Request.
4.4.6 Statistics Response When an WTP receives a Join Response it enters the Joined state and
initiates either a Configure Request or Image Data to the AC to which
it is now joined. Upon entering the Joined state, the WTP begins
timing an interval equal to NeighborDeadInterval. Expiration of the
timer will result in the transmission of the Echo Request.
Statistics Response acknowledges the Statistics Report. The following subsections define the message elements that MUST be
included in this LWAPP operation.
4.4.6.1 Sending Statistics Responses 6.2.1 Result Code
Statistics Responses are sent by an AR after receiving a Statistics The Result Code message element value is a 32-bit integer value,
Report. indicating the result of the request operation corresponding to the
sequence number in the message. The Result Code is included in a
successful Join Response.
4.4.6.2 Format of a Statistics Response 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Statistics Response carries no message elements. Type: 2 for Result Code
Length: 4
Result Code: The following values are defined:
0 Success
1 Failure
4.4.6.3 Receiving Statistics Responses 6.2.2 Status
The Statistics Response is simply an acknowledgement of the The Status message element is sent by the AC to the WTP in a
Statistics Report. non-successful Join Response message. This message element is used
to indicate the reason for the failure and should only be accompanied
with a Result Code message element that indicates a failure.
4.4.7 Reset Request 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Status |
+-+-+-+-+-+-+-+-+
The Reset Request is used to cause an AP to reboot. Type: 60 for Status
Length: 1
Status: The status field indicates the reason for an LWAPP failure.
The following values are supported:
1 - Reserved - do not use
2 - Resource Depletion
3 - Unknown Source
4 - Incorrect Data
4.4.7.1 Sending Reset Requests 6.2.3 Certificate
Reset Requests are sent by an AR to cause an AP to reinitialize its The Certificate message element is defined in section Section 6.1.6.
operation.
4.4.7.2 Format of a Reset Request 6.2.4 Session Key
The Reset Request carries no message elements. The Session Key message element is sent by the AC to the WTP and
includes the randomly generated session key, which is used to protect
the LWAPP control messages. More details are available in
Section 10. The value contains the following fields.
4.4.7.3 Receiving Reset Requests 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When an AP receives a Reset Request it will respond with a Reset Type: 46 for Session Key
Response and then reinitialize itself. Length: 20
Session ID: A 32-bit value defined in the session ID above.
Session Key: A signed, encrypted 128-bit randomly generated session
key. See Section 10 for more information on how this field is
created.
4.4.8 Reset Response 6.2.5 WTP Manager Data IP Address
The Reset Response acknowledges the Reset Request. The WTP Manager Data IP Address message element is optionally sent by
the AC to the WTP during the join phase. If present, the IP Address
contained in this message element is the address the WTP is to use
when sending any of its LWAPP data frames.
4.4.8.1 Sending Reset Responses Note this message element is only valid when LWAPP uses the IP/UDP
layer 3 transport
Reset Responses are sent by an AP after receiving a Reset Request. 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.8.2 Format of a Reset Response Type: TBD for WTP Manager Data IP Address
Length: 4
IP Address: The IP Address of an interface.
The Reset Response carries no message elements. Its purpose is to 6.3 Echo Request
acknowledge the receipt of the Reset Request.
4.4.8.3 Receiving Reset Responses The Echo Request message is a keepalive mechanism for the LWAPP
control message.
When an AR receives a Reset Response it is notified that the AP will Echo Requests are sent periodically by an WTP in the Run state (see
now reinitialize its operation. Figure 3) to determine the state of the connection between the WTP
and the AC. The Echo Request is sent by the WTP when the Heartbeat
timer expires, and it MUST start its NeighborDeadInterval timer.
4.5 Mobile Session Management The Echo Request carries no message elements.
Messages in this section are used by the AR to create session state When an AC receives an Echo Request it responds with an Echo
on the APs. Response.
4.5.1 Add Mobile Request 6.4 Echo Response
The Add Mobile Request is used by the AR to inform an AP that it The Echo Response acknowledges the Echo Request, and are only
should forward traffic from a particular mobile station. The add accepted while in the Run state (see Figure 3).
mobile request may also include security parameters that must be
enforced by the AP for the particular mobile.
4.5.1.1 Sending Add Mobile Requests Echo Responses are sent by an AC after receiving an Echo Request.
After transmitting the Echo Response, the AC should reset its
Heartbeat timer to expire in the value configured for EchoInterval.
If another Echo request is not received by the AC when the timer
expires, the AC SHOULD consider the AP to no longer be reachable.
When the AR sends an Add Mobile Request, it includes any security The Echo Response carries no message elements.
parameters that may be required. An AR that wishes to update a
mobile's policy on an AP may be done by simply sending a new Add
Mobile Request message.
4.5.1.2 Format of a Add Mobile Request When an WTP receives an Echo Response it stops the
NeighborDeadInterval timer, and starts the Heartbeat timer to
EchoInterval.
When sent by the AP, the Add Mobile Request contains the following If the NeighborDeadInterval timer expires prior to receiving an Echo
message elements: Response, the WTP enters the Idle state.
Add Mobile 6.5 Key Update Request
Mobile Session Key
4.5.1.3 Receiving Add Mobile Requests The Key Update Request updates the LWAPP session key used to secure
messages between the WTP and the AC.
When an AP receives an Add Mobile Request, it must first override any Key Update Requests are sent by an WTP in the Run state to update a
existing state it may have for the mobile station in question. The session key. The Session ID message element MUST include a new
latest Add Mobile Request overrides any previously received messages. session identifier.
If the Add Mobile message element's Not Authenticated bit is set, the
AP MUST only allow EAP packets to be forwarded to the AR, and must
drop any other messages. The AP will be notified via an Add Mobile
when it may accept other messages via a new Add Mobile Request from
the AR.
If the Mobile Session Key message element was present, the AP MUST When an AC receives a Key Update Request it generates a new key (see
add the key to its session key table to ensure that all future Section 10) and responds with a Key Update Response.
packets to the mobile are encrypted using the new key.
There are additional binding specific behaviours for this message. The following subsections define the message elements that MUST be
See the appropriate binding for additional specifications. included in this LWAPP operation.
4.5.2 Add Mobile Response 6.5.1 Session ID
The Add Mobile Response is used to acknowledge a previously received The Session ID message element is defined in section Section 6.1.7.
Add Mobile Request, and includes a Result Code message element which
indicates whether an error occured on the AP.
4.5.2.1 Sending Add Mobile Response 6.6 Key Update Response
Add Mobile Response is sent by the AP as a response to the Add Mobile The Key Update Response updates the LWAPP session key used to secure
messages between the WTP and the AC, and acknowledges the Key Update
Request. Request.
4.5.2.2 Format of a Add Mobile Response Key Update Responses are sent by a AC after receiving a Key Update
Request. The Key Update Responses is secured using public key
The Add Mobile Response includes the following message element: cryptography.
Result Code
4.5.2.3 Receiving Add Mobile Response
This message requires no special processing, and is only used to
acknowledge the Add Mobile Request.
4.5.3 Delete Mobile Request
The Delete Mobile Request is used by the AR to inform the AP to
terminate service to a particular mobile station.
4.5.3.1 Sending Delete Mobile Requests
The AR sends the Delete Mobile Request when it determines that
service to the mobile must be terminated. This could occur for
various reasons, including for administrative reaons, as a result of
the fact that the mobile has roamed to another AP, etc.
4.5.3.2 Format of a Delete Mobile Request When an WTP receives a Key Update Response it will use the
information contained in the Session Key message element to determine
the keying material used to encrypt the LWAPP communications between
the WTP and the AC.
The Delete Mobile Request message must include the following message The following subsections define the message elements that MUST be
element: included in this LWAPP operation.
Delete Mobile 6.6.1 Session Key
4.5.3.3 Receiving Delete Mobile Requests The Session Key message element is defined in section Section 6.2.4.
When an AP receives the Delete Mobile Request, it must immediately 6.7 Key Update Trigger
terminate service to the mobile station.
There are additional binding specific behaviours for this message. The Key Update Trigger is used by the AC to request that a Key Update
See the appropriate binding for additional specifications. Request be initiated by the WTP.
4.5.4 Delete Mobile Response Key Update Trigger are sent by an AC in the Run state to inform the
WTP to initiate a Key Update Request message.
The Delete Mobile Response is used to acknowledge a Delete Mobile When a WTP receives a Key Update Trigger it generates a key Update
Request. Request.
4.5.4.1 Sending Delete Mobile Response The following subsections define the message elements that MUST be
included in this LWAPP operation.
This message requires no special processing, and is only used to
acknowledge the Delete Mobile Request.
4.5.4.2 Format of a Delete Mobile Response
The Delete Mobile Response message includes the following message
element:
Result Code
4.5.4.3 Receiving Delete Mobile Response
No special processing is required for this packet by the AR.
4.6 Firmware Management
The Firmware Management messages are used by the AR to ensure that
the image being run on each AP is appropriate.
4.6.1 Image Data Request
The Image Data Request is used to update firmware on the AP.
4.6.1.1 Sending Image Data Requests
Image Data Requests are exchanged between the AP and the AR to
download a new program image to an AP.
4.6.1.2 Format of a Image Data Request
When sent by the AP, the Image Data Request contains the following 6.7.1 Session ID
message elements:
Image Download The Session ID message element is defined in section Section 6.1.7.
When sent by the AR, the Image Data Request contains the following 7. WTP Configuration Management
message elements:
Image Data The Wireless Termination Point Configuration messages are used to
exchange configuration between the AC and the WTP.
4.6.1.3 Receiving Image Data Requests 7.1 Configure Request
When an AP or AR receives an Image Data Request it will respond with The Configure Request message is sent by an WTP to send its current
a Image Data Response. configuration to its AC.
4.6.2 Image Data Response Configure Requests are sent by an WTP after receiving a Join
Response, while in the Configure state.
The Image Data Response acknowledges the Image Data Request. The Configure Request carries binding specific message elements.
Refer to the appropriate binding for the definition of this
structure.
4.6.2.1 Sending Image Data Response When an AC receives a Configure Request it will act upon the content
of the packet and respond to the WTP with a Configure Response.
An Image Data Responses is sent in response to an Image Data Request. The Configure Request includes multiple Administrative State message
Its purpose is to acknowledge the receipt of the Image Data Request Elements. There is one such message element for the WTP, and then
packet. one per radio in the WTP.
4.6.2.2 Format of an Image Data Response The following subsections define the message elements that MUST be
included in this LWAPP operation.
The Image Data Response carries no message elements. 7.1.1 Administrative State
4.6.2.3 Receiving Image Data Responses The administrative event message element is used to communicate the
state of a particular radio. The value contains the following
fields.
No action is necessary on receipt. 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5. LWAPP Message Elements Type: 27 for Administrative State
Length: 2
Radio ID: An 8-bit value representing the radio to configure. The
Radio ID field may also include the value of 0xff, which is used
to identify the WTP itself. Therefore, if an AC wishes to change
the administrative state of an WTP, it would include 0xff in the
Radio ID field.
As previously specified, the LWAPP messages MAY include one or more Admin State: An 8-bit value representing the administrative state of
message elements. The message element types are defined in this the radio. The following values are supported:
section. 1 - Enabled
2 - Disabled
The specified values for the Type field are the following: 7.1.2 AC Name
Description Type The AC Name message element is defined in section Section 5.2.2.
Result Code 1
AR Address 2
AP Descriptor 3
AP Name 4
AR Descriptor 5
Reserved 6
Binding AP WLAN Radio Configuration 7
Binding Rate Set 8
Binding Multi-domain capability 9
Binding MAC Operation 10
Reserved 11
Binding Tx Power Level 12
Binding Direct Sequence Control 13
Binding OFDM Control 14
Supported Rates 15
Reserved 16
Test 17
Reserved 18-25
Administrative State 26
Delete WLAN 27
Reserved 28-29
AR Name 30
Image Download 31
Image Data 32
Reserved 33
Location Data 34
Reserved 35
Statistics Timer 36
Binding Statistics 37
Binding Antenna xx
Reserved 38-42
Certificate 43
Session 44
Session key 45
Reserved 46-49
Binding WLAN Create 50
Vendor Specific 51
Binding Tx Power 52
Add Mobile 53
Delete Mobile 54
Mobile Session key 55
5.1 Result Code 7.1.3 AC Name with Index
The result code message element value is a 32-bit integer value, The AC Name with Index message element is sent by the AC to the WTP
indicating the result of the request operation corresponding to the to configure preferred ACs. The number of instances where this
sequence number in the message. message element would be present is equal to the number of ACs
configured on the WTP.
0 1 2 3 0 1
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 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Result Code | | Index | AC Name...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Result Code: The following values are defined: Type: 90 for AC Name with Index
0 Success Length: 5
1 Failure Index: The index of the preferred server (e.g., 1=primary,
2=secondary).
AC Name: A variable length ASCII string containing the AC's name.
5.2 AR Address 7.1.4 WTP Board Data
The AR address message element is used to communicate the identity of The WTP Board Data message element is sent by the WTP to the AC and
the AR. The value contains two fields, as shown. contains information about the hardware present.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | MAC Address | | Card ID | Card Revision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | WTP Model |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: MUST be set to zero
Mac Address: The MAC Address of the AR
5.3 AP Descriptor
The AP descriptor message element is used by the AP to communicate
it's current hardware/firmware configuration. The value contains the
following fields.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Hardware Version | | WTP Model |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Software Version | | WTP Serial Number ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Boot Version | | WTP Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radios | Radios in use | Encryption Capabilities | | Ethernet MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethernet MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Hardware Version: A 32-bit integer representing the AP's hardware Type: 50 for WTP Board Data
version number Length: 26
Software Version: A 32-bit integer representing the AP's Firmware Card ID: A hardware identifier.
version number Card Revision: Revision of the card.
Boot Version: A 32-bit integer representing the AP's boot loader's WTP Model: WTP Model Number.
version number WTP Serial Number: WTP Serial Number.
Max Radios: An 8-bit value representing the number of radios (where WTP Options: A vendor specific field encoding specific options
each radio is identified via the RID field) supported by the AP enabled on the WTP.
Radios in use: An 8-bit value representing the number of radios Ethernet MAC Address: MAC Address of the WTP's Ethernet interface.
present in the AP
Encryption Capabilities: This 16-bit field is used by the AP to
communicate it's capabilities to the AR. Since most APs support
link layer encryption, the AR may make use of these services.
There are binding dependent encryption capabilites. Refer to the
specific binding for the specification. This bitfield also
defines the following binding-independent values:
4 - Encrypt AES-CCM 128: All packets to/from the mobile station
must be encrypted using 128 bit AES CCM [11].
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using TKIP and authenticated using Michael [9].
5.4 AP Name 7.1.5 Statistics Timer
The AP name message element value is a variable length byte string. The statistics timer message element value is used by the AC to
The string is NOT zero terminated. inform the WTP of the frequency which it expects to receive updated
statistics.
5.5 AR Descriptor 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The AR payload message element is used by the AR to communicate it's Type: 37 for Statistics Timer
current state. The value contains the following fields. Length: 2
Statistics Timer: A 16-bit unsigned integer indicating the time, in
seconds
7.1.6 WTP Static IP Address Information
The WTP Static IP Address Information message element is used by an
AC to configure or clear a previously configured static IP address on
an WTP.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Hardware Version ... | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HW Ver | Software Version ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SW Ver | Stations | Limit | | Netmask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Limit | Radios | Max Radio | | Gateway |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Max Radio | | Static |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Type: 82 for WTP Static IP Address Information
Length: 13
IP Address: The IP Address to assign to the WTP.
Netmask: The IP Netmask.
Gateway: The IP address of the gateway.
Netmask: The IP Netmask.
Static: An 8-bit boolean stating whether the WTP should use a static
IP address or not.
Hardware Version: A 32-bit integer representing the AP's hardware 7.1.7 WTP Reboot Statistics
version number
Software Version: A 32-bit integer representing the AP's Firmware
version number
Stations: A 16-bit integer representing number of mobile stations
currently associated with the AR
Limit: A 16-bit integer representing the maximum number of stations
supported by the AR
Radios: A 16-bit integer representing the number of APs currently
attached to the AR
Max Radio: A 16-bit integer representing the maximum number of APs
supported by the AR
5.6 Binding AP WLAN Radio Configuration The WTP Reboot Statistics message element is sent by the WTP to the
AC to communicate information about reasons why reboots have
occurred.
The AP WLAN radio configuration is used by the AR to configure a 0 1 2 3
Radio on the AP. The message element definition is binding specific. 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
Refer to the appropriate binding for the specification. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Crash Count | LWAPP Initiated Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Failure Count | Failure Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.7 Binding Rate Set Type: 67 for WTP Reboot Statistics
Length: 7
Crash Count: The number of reboots that have occurred due to an WTP
crash.
LWAPP Initiated Count: The number of reboots that have occured at
the request of some LWAPP message, such as a change in
configuration that required a reboot or an explicit LWAPP reset
request.
Link Failure Count: The number of times that an LWAPP connection
with an AC has failed.
Failure Type: The last WTP failure. The following values are
supported:
0 - Link Failure
1 - LWAPP Initiated
2 - WTP Crash
The rate set message element value is sent by the AR and contains the 7.2 Configure Response
supported operational rates. The message element definition is
binding specific. Refer to the appropriate binding for the
specification.
5.8 Binding Multi-domain Capability The Configure Response message is sent by an AC and provides an
opportunity for the AC to override an WTP's requested configuration.
The multi-domain capability message element is used by the AR to Configure Responses are sent by an AC after receiving a Configure
inform the AP of regulatory limits. The message element definition Request.
is binding specific. Refer to the appropriate binding for the
specification.
5.9 Binding MAC Operation The Configure Response carries binding specific message elements.
The MAC operation message element is sent by the AR to set the 802.11 Refer to the appropriate binding for the definition of this
MAC parameters on the AP. The message element definition is binding structure.
specific. Refer to the appropriate binding for the specification.
5.10 Binding Tx Power Level When an WTP receives a Configure Response it acts upon the content of
the packet, as appropriate. If the Configure Response message
includes a Change State Event message element that causes a change in
the operational state of one of the Radio, the WTP will transmit a
Change State Event to the AC, as an acknowledgement of the change in
state.
The Tx power level message element is sent by the AP and contains the The following subsections define the message elements that MUST be
different power levels supported. The message element definition is included in this LWAPP operation.
binding specific. Refer to the appropriate binding for the
specification.
5.11 Binding Direct Sequence Control 7.2.1 Decryption Error Report Period
The direct sequence control message element is a bi-directional The Decryption Error Report Period message element value is used by
element. When sent by the AP, it contains the current state. When the AC to inform the WTP how frequently it should send decryption
sent by the AR, the AP MUST adhere to the values. The message error report messages.
element definition is binding specific. Refer to the appropriate
binding for the specification.
5.12 Binding OFDM Control 0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Report Interval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OFDM control message element is a bi-directional element. When Type: 38 for Decryption Error Report Period
sent by the AP, it contains the current state. When sent by the AR, Length: 3
the AP MUST adhere to the values. The message element definition is Radio ID: The Radio Identifier, typically refers to some interface
binding specific. Refer to the appropriate binding for the index on the WTP
specification. Report Interval: A 16-bit unsigned integer indicating the time, in
seconds
5.13 Binding Supported Rates 7.2.2 Change State Event
The supported rates message element is sent by the AP to indicate the The WTP radios information message element is used to communicate the
rates that it supports. The message element definition is binding operational state of a radio. The value contains two fields, as
specific. Refer to the appropriate binding for the specification. shown.
5.14 Test 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | State | Cause |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The test message element is used as padding to perform MTU discovery, Type: 26 for Change State Event
and MAY contain any value, of any length. Length: 3
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
State: An 8-bit boolean containing the state of the radio.
Cause: In the event of a radio being inoperable, the cause field
would contain the reason the radio is out of service.
5.15 Administrative State 7.2.3 LWAPP Timers
The administrative event message element is used to communicate the The LWAPP Timers message element is used by an AC to configure LWAPP
state of a particular radio. The value contains the following timers on an WTP.
fields.
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Admin State | | Discovery | Echo Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio to configure Type: 68 for LWAPP Timers
Admin State: An 8-bit value representing the administrative state of Length: 2
the radio. The following values are supported: Discovery: The number of seconds between LWAPP Discovery packets,
0 - Enabled when the WTP is in the discovery mode.
1 - Disabled Echo Request: The number of seconds between WTP Echo Request LWAPP
messages.
5.16 Delete WLAN 7.2.4 AC List
The delete WLAN message element is used to inform the AP that a The AC List message element is used to configure an WTP with the
previously created WLAN is to be deleted. The value contains the latest list of ACs in a cluster.
following fields:
0 1 2 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | | AC IP Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio Type: 59 for AC List
WLAN ID: A 16-bit value specifying the WLAN Identifier Length: >= 4
AC IP Address: An array of 32-bit integers containing an AC's IP
Address.
5.17 AR Name 7.2.5 WTP Fallback
The AR name message element contains an ASCII representation of the The WTP Fallback message element is sent by the AC to the WTP to
AR's identity. The value is a variable length byte string. The enable or disable automatic LWAPP fallback in the event that an WTP
string is NOT zero terminated. detects its preferred AC, and is not currently connected to it.
5.18 Image Download 0
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Mode |
+-+-+-+-+-+-+-+-+
The image download message element is sent by the AP to the AR and Type: 91 for WTP Fallback
contains the image filename. The value is a variable length byte Length: 1
string. The string is NOT zero terminated. Mode: The 8-bit boolean value indicates the status of automatic
LWAPP fallback on the WTP. When enabled, if the WTP detects that
its primary AC is available, and it is not connected to it, it
SHOULD automatically disconnect from its current AC and reconnect
to its primary. If disabled, the WTP will only reconnect to its
primary through manual intervention (e.g., through the Reset
Request command).
5.19 Image Data 7.2.6 Idle Timeout
The image data message element value contains the following fields. The Idle Timeout message element is sent by the AC to the WTP to
provide it with the idle timeout that it should enforce on its active
mobile station entries.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opcode | Checksum | Image Data | | Timeout |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Image Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Opcode: An 8-bit value representing the transfer opcode. The Type: 97 for Idle Timeout
following values are supported: Length: 4
3 - Image data is included Timeout: The current idle timeout to be enforced by the WTP.
5 - An error occurred. Transfer is aborted
Checksum: A 16-bit value containing a checksum of the image data
that follows
Image Data: A variable length firmward data
5.20 Location Data
The location data message element is a variable length byte string
containing user defined location information (e.g. "Next to
Fridge"). The string is NOT zero terminated.
5.21 Statistics Timer 7.3 Configuration Update Request
The statistics timer message element value is used by the AR to Configure Update Requests are sent by the AC to provision the WTP
inform the AP of the frequency which it expects to receive updated while in the Run state. This is used to modify the configuration of
statistics. the WTP while it is operational.
0 1 When an AC receives a Configuration Update Request it will respond
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 with a Configuration Update Response, with the appropriate Result
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Code.
| Statistics Timer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Statistics Timer: A 16-bit unsigned integer indicating the time, in The following subsections define the message elements introduced by
seconds this LWAPP operation.
5.22 Binding Statistics 7.3.1 WTP Name
The statistics message element is sent by the AP to transmit it's The WTP Name message element is defined in section Section 6.1.3.
current statistics. The message element definition is binding
specific. Refer to the appropriate binding for the specification.
5.23 Binding Antenna 7.3.2 Change State Event
The antenna message element is communicated by the AP to the AR to The Change State Event message element is defined in section
provide information on the antennas available. The AR MAY use this Section 7.2.2.
element to reconfigure the AP's antennas. The message element
definition is binding specific. Refer to the appropriate binding for
the specification.
5.24 Certificate 7.3.3 Administrative State
The certificate message element value is a byte string containing a The Administrative State message element is defined in section
DER-encoded x.509v3 certificate. Section 7.1.1.
5.25 Session ID 7.3.4 Statistics Timer
The session ID message element value contains a randomly generated The Statistics Timer message element is defined in section
[5] unsigned 32-bit integer. Section 7.1.5.
5.26 Session Key Payload 7.3.5 Location Data
The Session Key Payload message element is sent by the AR to the AP The Location Data message element is defined in section
and includes the randomly generated session key, which is used to Section 6.1.4.
protect the LWAPP control messages. More details are available in
Appendix A. The value contains the following fields.
0 1 2 3 7.3.6 Decryption Error Report Period
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session Key |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session ID: A 32-bit value defined in the session ID above. The Decryption Error Report Period message element is defined in
Session Key: A 128-bit value randomly generated session key [5] section Section 7.2.1.
5.27 Binding WLAN Create 7.3.7 AC List
The WLAN Create message element is used by the AR to define a The AC List message element is defined in section Section 7.2.4.
wireless LAN on the AP. The message element definition is binding
specific. Refer to the appropriate binding for the specification.
5.28 Vendor Specific Payload 7.3.8 Add Blacklist Entry
The Vendor Specific Payload is used to communicate vendor specific The Add Blacklist Entry message element is used by an AC to add a
information between the AP and the AR. The value contains the blacklist entry on an WTP, ensuring that the WTP no longer provides
following format: any service to the MAC addresses provided in the message. The MAC
Addresses provided in this message element are not expected to be
saved in non-volative memory on the WTP.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor Identifier | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Element ID | Value... | | MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 65 for Add Blacklist Entry
Length: >= 7
Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to add to the blacklist
entry.
Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 7.3.9 Delete Blacklist Entry
Network Management Private Enterprise Codes" [6]
Element ID: A 16-bit Element Idenfier which is managed by the
vendor.
Element ID: Value The value associated with the vendor specific
element.
5.29 Binding Tx Power The Delete Blacklist Entry message element is used by an AC to delete
a previously added blacklist entry on an WTP, ensuring that the WTP
provides service to the MAC addresses provided in the message.
The Tx power message element value is bi-directional. When sent by 0 1 2 3
the AP, it contains the current power level of the radio in question. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
When sent by the AR, it contains the power level the AP MUST adhere Type: 66 for Delete Blacklist Entry
to. The message element definition is binding specific. Refer to Length: >= 7
the appropriate binding for the specification. Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to delete from the blacklist
entry.
5.30 Add Mobile 7.3.10 Add Static Blacklist Entry
The Add Mobile message element is used by the AR to inform the AP The Add Static Blacklist Entry message element is used by an AC to
that it should allow traffic from/to a particular mobile station. add a permanent blacklist entry on an WTP, ensuring that the WTP no
longer provides any service to the MAC addresses provided in the
message. The MAC Addresses provided in this message element are
expected to be saved in non-volative memory on the WTP.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | MAC Address | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Preamble Mode | WLAN ID |Supported Rates|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Not Auth'ted | | MAC Address[] |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio Type: 70 for Delete Blacklist Entry
Association ID: A 16-bit value specifying the 802.11 Association Length: >= 7
Identifier Num of Entries: The number of MAC Addresses in the array.
MAC Address: The mobile station's MAC Address
Preamble Mode: This field is set by the AR to inform the AP whether
short or long preamble should be used with the mobile station.
The following values are supported:
0 - Long Preamble: Long preamble is to be used by the AP when
communicating with the mobile station.
1 - Short Preamble: Short preamble is to be used by the AP when
communicating with the mobile station.
WLAN ID: A 16-bit value specifying the WLAN Identifier
Supported Rates: The supported rates to be used with the mobile
station.
Not Authenticated: The AR sets this field to one (1) during the
authentication phase to inform the AP the mobile needs to be
authenticated first and should only accept EAP packets.
5.31 Delete Mobile MAC Address: An array of MAC Addresses to add to the permanent
blacklist entry.
The Delete Mobile message element is used by the AR to inform an AP 7.3.11 Delete Static Blacklist Entry
that it should no longer provide service to a particular mobile
station. The Delete Static Blacklist Entry message element is used by an AC to
delete a previously added static blacklist entry on an WTP, ensuring
that the WTP provides service to the MAC addresses provided in the
message.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | MAC Address | | Num of Entries| MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | | MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio Type: 71 for Delete Blacklist Entry
MAC Address: The mobile station's MAC Address Length: >= 7
Num of Entries: The number of MAC Addresses in the array.
MAC Address: An array of MAC Addresses to delete from the static
blacklist entry.
5.32 Binding Mobile Session Key 7.3.12 LWAPP Timers
The Mobile Session Key Payload message element is sent when the AR The LWAPP Timers message element is defined in section Section 7.2.3.
determines that encryption between a mobile station and the AP ir
required. This message element MUST NOT be present without the Add
Mobile (see Section 5.30)message element, and MUST NOT be sent if the
AP had not specifically advertised support for the requested
encryption scheme (see Section 5.3). The message element definition
is binding specific. Refer to the appropriate binding for the
specification.
6. LWAPP Configuration Variables 7.3.13 AC Name with Index
An AP or AR that implements LWAPP discovery MUST allow for the The AC Name with Index message element is defined in section
following variables to be configured by system management; default Section 7.1.3.
values are specified so as to make it unnecessary to configure any of
these variables in many cases.
6.1 MaxDiscoveryInterval 7.3.14 WTP Fallback
The maximum time allowed between sending discovery requests from the The WTP Fallback message element is defined in section Section 7.2.5.
interface, in seconds. Must be no less than 2 seconds and no greater
than 180 seconds.
Default: 20 seconds. 7.3.15 Idle Timeout
6.2 MaxDiscoveries The Idle Timeout message element is defined in section Section 7.2.6.
The maximum number of discovery requests that will be sent after an 7.4 Configuration Update Response
AP boots.
Default: 10 The Configuration Update Response is the acknowledgement message for
the Configuration Update Request.
6.3 SilentInterval Configuration Update Responses are sent by an WTP after receiving a
Configuration Update Request.
The minimum time, in seconds, an AP MUST wait after failing to When an AC receives a Configure Update Response the result code
receive any responses to its discovery requests, before it MAY again indicates if the WTP successfully accepted the configuration.
send discovery requests.
Default: 30 The following subsections define the message elements that must be
present in this LWAPP operation.
6.4 NeighborDeadInterval 7.4.1 Result Code
The minimum time, in seconds, an AP MUST wait without having received The Result Code message element is defined in section Section 6.2.1.
echo replies to its echo responses, before the destination for the
echo replies may be considered dead. Must be no less than
2*EchoInterval seconds and no greater than 240 seconds.
Default: 60 7.5 Change State Event Request
6.5 EchoInterval The Change State Event is used by the WTP to inform the AC of a
change in the operational state.
The minimum time, in seconds, between sending echo requests to the AR The Change State Event message is sent by the WTP when it receives a
with which the AP has joined. Configuration Response that includes a Change State Event message
element. It is also sent in the event that the WTP detects an
operational failure with a radio. The Change State Event may be sent
in either the Configure or Run state (see Figure 3.
Default: 30 When an AC receives a Change State Event it will respond with a
Change State Event Response and make any necessary modifications to
internal WTP data structures.
6.6 DiscoveryInterval The following subsections define the message elements that must be
present in this LWAPP operation.
The minimum time, in seconds, that an AP MUST wait after receiving a 7.5.1 Change State Event
discovery reply, before sending a join request.
Default: 5 The Change State Event message element is defined in section
Section 7.2.2.
7. LWAPP Transport Layers 7.6 Change State Event Response
The LWAPP protocol can operate at layer 2 or 3. For layer 2 support, The Change State Event Response acknowledges the Change State Event.
the LWAPP messages are carried in a native Ethernet frame. As such,
the protocol is not routable and depends upon layer 2 connectivity
between the AP and the AR. Layer 3 support is provided by
encapsulating the LWAPP messages within UDP.
7.1 Using IEEE 802.3 MAC as LWAPP transport Change State Event Response are sent by an WTP after receiving a
Change State Event.
This section describes how the LWAPP protocol is provided over native The Change State Event Response carries no message elements. Its
ethernet frames. An LWAPP packet is formed from the MAC frame header purpose is to acknowledge the receipt of the Change State Event.
followed by the LWAPP message header.
7.1.1 Framing The WTP does not need to perform any special processing of the Change
State Event Response message.
Source Address 7.7 Clear Config Indication
A MAC address belonging to the interface from which this message is The Clear Config Indication is used to reset an WTP's configuration.
sent. If multiple source addresses are configured on an interface,
then the one chosen is implementation dependent.
Destination Address The Clear Config Indication is sent by an AC to request that an WTP
reset its configuration to manufacturing defaults. The Clear Config
Indication message is sent while in the Run LWAPP state.
A MAC address belonging to the interface to which this message is to The Reset Request carries no message elements.
be sent. This destination address MAY be either an individual
address or a multicast address, if more than one destination
interface is intended.
Ethertype When an WTP receives a Clear Config Indication it will reset its
configuration to manufacturing defaults.
The Ethertype field is set to 0x88bb. 8. Device Management Operations
7.1.2 AR Discovery This section defines LWAPP operations responsible for debugging,
gathering statistics, logging, and firmware management.
When run over IEEE 802.3, LWAPP messages are distributed to a 8.1 Image Data Request
specific MAC level broadcast domain. The AR discovery mechanism used
with this transport is for an AP to transmit a Discovery Request
message to a broadcast destination MAC address. The ARs will receive
this message and reply based on their policy.
7.1.3 Fragmentation/Reassembly The Image Data Request is used to update firmware on the WTP. This
message and its companion response are used by the AC to ensure that
the image being run on each WTP is appropriate.
Fragmentation at the MAC layer is managed using the C,F,L and Frag ID Image Data Requests are exchanged between the WTP and the AC to
fields of the LWAPP message header. download a new program image to an WTP.
7.1.4 Multiplexing When an WTP or AC receives an Image Data Request it will respond with
a Image Data Response.
LWAPP control messages and data messages are distinguished by the C The format of the Image Data and Image Download message elements are
Bit in the LWAPP message header. described in the following subsections.
7.1.5 LWAPP Message Header format over IEEE 802.3 MAC transport 8.1.1 Image Download
The LWAPP message header for data and command messages in the 802.3 The image download message element is sent by the WTP to the AC and
MAC transport follows immediately after the MAC header: contains the image filename. The value is a variable length byte
string. The string is NOT zero terminated.
8.1.2 Image Data
The image data message element is present when sent by the AC and
contains the following fields.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER| RID |C|F|L| Frag ID | Length | | Opcode | Checksum | Image Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Image Data ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status/WLANs | Payload... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
7.1.5.1 VER Field (2 bits)
Defines the version of LWAPP used in this packet. The value for this
draft is 0.
7.1.5.2 RID Field (3 bits)
The RID field gives the Radio ID number for this packet. APs with
multiple radios but a single MAC use this to indicate which radio is
associated with the packet.
7.1.5.3 C Bit
The C bit indicates whether this packet carries a data message or a
control message. When this bit is 0, the packet carries an LWAPP
data message in the payload. When this bit is 1, the packet carries
an LWAPp control messwage as defined in section 4 for consumption by
the addressed destination.
7.1.5.4 F Bit
The F bit indicates whether this packet is a fragment. When this bit
is 1, the packet is a fragment and MUST be combined with the other
corresponding fragments to reassemble the complete information
exchanged between the AP and AR.
7.1.5.5 L Bit
The L bit is valid only if the 'F' bit is set and indicates whether
the packet contains the last fragment of a fragmented exchange
between AP and AR. When this bit is 1, the packet is not the last
fragment. When this bit is 0, the packet is the last fragment.
7.1.5.6 Fragment ID (8 bits)
The Fragment ID is a value assigned to each group of fragments making
up a complete set. The value of Fragment ID is incremented with each
new set of fragments. The Fragment ID wraps to zero after the
maximum value has been used to identify a set of fragments. LWAPP
only supports up to 2 fragments.
7.1.5.7 Length (16 bits) Type: 33 for Image Data
Length: >= 5
Opcode: An 8-bit value representing the transfer opcode. The
following values are supported:
3 - Image data is included
5 - An error occurred. Transfer is aborted
Checksum: A 16-bit value containing a checksum of the image data
that follows
Image Data: The Image Data field contains 1024 characters, unless
the payload being sent is the last one (end of file)
The length field is the unsigned number of bytes in the Payload. 8.2 Image Data Response
7.1.5.8 Status and WLANS (16 bits) The Image Data Response acknowledges the Image Data Request.
The interpretation of this field is binding specific. Refer to the An Image Data Responses is sent in response to an Image Data Request.
transport portion of the binding for a wireless technology for the Its purpose is to acknowledge the receipt of the Image Data Request
specification. packet.
7.1.5.9 Payload The Image Data Response carries no message elements.
This field contains the header for an LWAPP Data Message or LWAPP No action is necessary on receipt.
Control Message, followed by the data associated with that message.
7.2 Using IPv4/UDP as LWAPP transport 8.3 Reset Request
This section defines how LWAPP makes use of IPV4/UDP transport The Reset Request is used to cause an WTP to reboot.
between the AP and the AR. In case of this transport, the MAC layer
is as standard for an IPv4 packet.
7.2.1 Framing Reset Requests are sent by an AC to cause an WTP to reinitialize its
operation.
Communication between AP and AR is established according to the The Reset Request carries no message elements.
standard UDP client/server model. The connection is initiated by the
AP (client) to the well-known UDP port of the AR (server) used for
control messages. This UDP port number of the AR is TBD.
7.2.2 AR Discovery When an WTP receives a Reset Request it will respond with a Reset
Response and then reinitialize itself.
When LWAPP is run over routed IPv4 networks, the AP and the AR do not 8.4 Reset Response
need to reside in the same IP subnet (broadcast domain). However, in
the event the peers reside on separate subnets, there must exist a
mechanism for the AP to discover the AR.
As the AP attempts to establish communication with the AR, it sends The Reset Response acknowledges the Reset Request.
the Discovery Request message and receives the corresponding reply
message from the AR. The AP must send the Discovery Request message
to either the limited broadcast IP address (255.255.255.255) or to
the unicast IP address of the AR. Upon receipt of the message, the
AR issues a Discovery Reply message to the IP address of the AP,
regardless of whether Discovery Request was sent as a broadcast or
unicast message.
Whether the AP uses a limited IP broadcast or unicast IP address is Reset Responses are sent by an WTP after receiving a Reset Request.
implementation dependent.
In order for the AP to use a unicast address, it must first obtain The Reset Response carries no message elements. Its purpose is to
the IP address of the AR. The configuration of the AR's address in acknowledge the receipt of the Reset Request.
the AP is implementation dependent.
Informative note: Some possibilities are to make use of a vendor When an AC receives a Reset Response it is notified that the WTP will
specific DHCP option, DNS name resolution, or even static now reinitialize its operation.
provisioning of the AR's IP address in non-volatile storage.
7.2.3 Fragmentation/Reassembly 8.5 WTP Event Request
When LWAPP is implemented at L3, the transport layer uses IP WTP Event Request is used by an WTP to send an information to its AC.
fragmentation to fragment and reassemble LWAPP messages that are These types of events may be periodical, or some asynchronous event
longer than MTU size used by either AP or AR. The details of IP on the WTP. For instance, an WTP collects statistics and uses the
fragmentation are covered in [3]. WTP Event Request to transmit this information to the AC.
[ed: IP fragmentation may raise security concerns and bring When an AC receives a WTP Event Request it will respond with a WTP
additional configuration requirements for certain firewalls and NATs. Event Request.
One alternative is to re-use the layer 2 (application layer)
fragmentation reassembly. Comments are welcomed.]
7.2.4 Multiplexing The WTP Event Request message MUST contain one of the following
message element described in the next subsections, or a message
element that is defined for a specific technology.
LWAPP messages convey control information between AP and AR, as well 8.5.1 Decryption Error Report
as binding specific data frames or binding specific management
frames. As such, LWAPP messages need to be multiplexed in the
transport sub-layer and be delivered to the proper software entities
in the endpoints of the protocol.
In case of Layer 3 connection, multiplexing is achieved by use of The Decryption Error Report message element value is used by the WTP
different UDP ports for control and data packets. to inform the AC of decryption errors that have occured since the
last report.
As part of Join procedure, the AP and AR may negotiate different UDP 0 1 2
ports, as well as, different IP addresses for data or session 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
management messages. [ed: details on how to communicate this +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
information in the protocol is still missing]. | Radio ID |Num Of Entries | Mobile MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobile MAC Address[] |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the event the AP and AR are separated by a NAT, with the AP using Type: 39 for Decryption Error Report
private IP address space, it is the responsibility of the NAT to Length: >= 8
manage appropriate UDP port mapping. Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP
Num Of Entries: An 8-bit unsigned integer indicating the number of
mobile MAC addresses.
Mobile MAC Address: An array of mobile station MAC addresses that
have caused decryption errors.
7.2.5 LWAPP Message Header format over IPv4/UDP transport 8.5.2 Duplicate IP Address
The LWAPP message header for data and command messages using the The Duplicate IP Address message element is used by an WTP to inform
IPv4/UDP transport follows immediately after the UDP header: an AC that it has detected another host using the same IP address it
is currently using.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VER| RID | Reserved | Length | | IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status/WLANS | Payload... | | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
7.2.5.1 VER (2 bits) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 77 for Duplicate IP Address
Defines the version of LWAPP used in this packet. The value for this Length: 10
draft is 0. IP Address: The IP Address currently used by the WTP.
MAC Address: The MAC Address of the offending device.
7.2.5.2 RID (3 bits)
The RID field gives the Radio ID number for this packet. APs with
multiple radios but a single IPv4 address use this to indicate which
radio is associated with the packet.
7.2.5.3 Reserved (11 bits)
The reserved field MUST be set to zero.
7.2.5.4 Length (16 bits)
The length field is the unsigned number of bytes in the Payload.
7.2.5.5 Status and WLANS (16 bits)
The interpretation of this field is binding specific. Refer to the
transport portion of the binding for a wireless technology for the
specification.
7.2.5.6 Payload 8.6 WTP Event Response
This field contains the LWAPP Data Message or LWAPP Control Message. WTP Event Response acknowledges the WTP Event Request.
8. Light Weight Access Protocol Constants WTP Event Response are sent by an AC after receiving a WTP Event
Request.
MAX_RESPONSE_DELAY 2 seconds The WTP Event Response carries no message elements.
MAX_SOLICITATION_DELAY 1 second 8.7 Data Transfer Request
SOLICITATION_INTERVAL 3 seconds The Data Transfer Request is used to upload debug information from
the WTP to the AC.
MAX_SOLICITATIONS 3 transmissions Data Transfer Requests are sent by the WTP to the AC when it
determines that it has important information to send to the AC. For
instance, if the WTP detects that its previous reboot was caused by a
system crash, it would want to send the crash file to the AC. The
remote debugger function in the WTP also uses the data transfer
request in order to send console output to the AC for debugging
purposes.
9. Security Considerations When an AC receives an Data Transfer Request it will respond with a
Data Transfer Response. The AC may log the information received, as
it sees fit.
LWAPP uses public key cryptography to ensure trust between the AP and The data transfer request message MUST contain ONE of the following
the AR. During the Join phase, the AR generates a session key, which message element described in the next subsection.
is used to secure future control messages. The AP does not
participate in the key generation, but public key cryptography is
used to authenticate the resulting key material. A secured delivery
mechanism to place the certificate in the devices is required. In
order to maximize session key security, the AP and AR periodically
update the session keys, which are encrypted using public key
cryptography. This ensures that a potentially previously compromised
key does not affect the security of communication with new key
material.
One question that periodically arises is why the Join Request is not 8.7.1 Data Transfer Mode
signed. It was felt that requiring a signature in this messages was
not required for the following reasons:
1. The Join Request is replayable, so requiring a signature doesn't
provide much protection unless the switches keep track of all
previous Join Requests from a given AP. One alternative would
have been to add a timestamp, but this introduces clock
synchronization issues. Further, authentication occurs in a later
exchange anyway (see point 2 below).
2. The AP is authenticated by virtue of the fact that it can decrypt
and then use the session keys (encrypted with its own public key),
so it *is* ultimately authenticated.
3. A signed Join Request provides a potential Denial of Service
attack on the AR, which would have to authenticate each
(potentially malicious) message.
10. IPR Statement The Data Transfer Mode message element is used by the AC to request
information from the WTP for debugging purposes.
The IETF has been notified of intellectual property rights claimed in 0
regard to some or all of the specification contained in this 0 1 2 3 4 5 6 7
document. For more information consult the online list of claimed +-+-+-+-+-+-+-+-+
rights. | Data Type |
+-+-+-+-+-+-+-+-+
Type: 52 for Data Transfer Mode
Length: 1
Data Type: An 8-bit value the type of information being requested.
The following values are supported:
1 - WTP Crash Data
2 - WTP Memory Dump
Please refer to http://www.ietf.org/ietf/IPR for more information. 8.7.2 Data Transfer Data
11 References The Data Transfer Data message element is used by the WTP to provide
information to the AC for debugging purposes.
[1] "Advanced Encryption Standard (AES)", November 2001, <FIPS PUB 0 1 2 3
197>. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data Type | Data Length | Data ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[2] "Counter with CBC-MAC (CCM)", January 2003, Type: 53 for Data Transfer Data
<ftp://ftp.isi.edu/internet-drafts/draft-housley-ccm-mode-02.txt> Length: >= 3
. Data Type: An 8-bit value the type of information being sent. The
following values are supported:
1 - WTP Crash Data
2 - WTP Memory Dump
Data Length: Length of data field.
Data: Debug information.
[3] "IP DATAGRAM REASSEMBLY ALGORITHMS", July 1992, 8.8 Data Transfer Response
<ftp://ftp.isi.edu/in-notes/rfc815>.
[4] "Key words for use in RFCs to Indicate Requirement Levels", The Data Transfer Response acknowledges the Data Transfer Request.
March 1997, <ftp://ftp.isi.edu/in-notes/rfc2119>.
[5] "Randomness Recommendations for Security", December 1994, An Data Transfer Response is sent in response to an Data Transfer
<ftp://ftp.isi.edu/in-notes/rfc1750>. Request. Its purpose is to acknowledge the receipt of the Data
Transfer Request packet.
[6] "Assigned Numbers: RFC 1700 is Replaced by an On-line The Data Transfer Response carries no message elements.
Database", January 2002, <ftp://ftp.isi.edu/in-notes/rfc3232>.
[7] "The Internet Standards Process Revision 3", October 1996, Upon receipt of a Data Transfer Response, the WTP transmits more
<ftp://ftp.isi.edu/in-notes/rfc2026>. information, if any is available.
[8] "Mobility Related Terminology", April 2003, 9. Mobile Session Management
<ftp://ftp.isi.edu/internet-drafts/draft-ietf-seamoby-terminology-04.txt>
.
[9] "WiFi Protected Access (WPA) rev 1.6", April 2003. Messages in this section are used by the AC to create, modify or
delete mobile station session state on the WTPs.
[10] "IEEE Std 802.11: Wireless LAN Medium Access Control (MAC) and 9.1 Mobile Config Request
Physical Layer (PHY) Specifications", 1999.
[11] "IEEE Std 802.11i/3.0: Specification for Enhanced Security", The Mobile Config Request message is used to create, modify or delete
November 2003. mobile session state on an WTP. The message is sent by the AC to the
WTP, and may contain one or more message elements. The message
elements for this LWAPP control message include information that is
generally highly technology specific. Therefore, please refer to the
appropriate binding section or document for the definitions of the
messages elements that may be used in this control message.
[12] "Security Architecture for IP, IETF RFC 2401", November 1998, This section defines the format of the Delete Mobile message element,
<http://www.ietf.org/rfc/rfc2401.txt>. since it does not contain any technology specific information.
Authors' Addresses 9.1.1 Delete Mobile
Pat R. Calhoun The Delete Mobile message element is used by the AC to inform an WTP
Airespace that it should no longer provide service to a particular mobile
110 Nortech Parkway station. The WTP must terminate service immediately upon receiving
San Jose, CA 95134 this message element.
Phone: +1 408-635-2000 The transmission of a Delete Mobile message element could occur for
EMail: pcalhoun@airespace.com various reasons, including for administrative reaons, as a result of
the fact that the mobile has roamed to another WTP, etc.
Bob O'Hara Once access has been terminated for a given station, any future
Airespace packets received from the mobile must result in a deauthenticate
110 Nortech Parkway message, as specified in [6].
San Jose, CA 95134
Phone: +1 408-635-2025 0 1 2 3
EMail: bob@airespace.com 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Scott Kelly Type: 30 for Delete Mobile
Airespace Length: 7
110 Nortech Parkway Radio ID: An 8-bit value representing the radio
San Jose, CA 95134 MAC Address: The mobile station's MAC Address
Phone: +1 408-635-2022 9.2 Mobile Config Response
EMail: skelly@airespace.com
Rohit Suri The Mobile Configuration Response is used to acknowledge a previously
Airespace received Mobile Configuration Request, and includes a Result Code
110 Nortech Parkway message element which indicates whether an error occured on the WTP.
San Jose, CA 95134
Phone: +1 408-635-2026 This message requires no special processing, and is only used to
EMail: rsuri@airespace.com acknowledge the Mobile Configuration Request.
Michael Glenn Williams The data transfer request message MUST contain the message elements
Nokia, Inc. described in the next subsection.
313 Fairchild Drive
Mountain View, CA 94043
Phone: +1 650-714-7758 9.2.1 Result Code
EMail: Michael.G.Williams@Nokia.com
Michael Vakulenko
Legra Systems, Inc.
3 Burlington Woods Drive
Burlington, MA 01803
Phone: +1 781-272-8400 The Result Code message element is defined in section Section 6.2.1.
EMail: michaelv@legra.com
Appendix A. Session Key Generation 10. Session Key Generation
Note: This version only defines a certificate based mechanism to Note: This version only defines a certificate based mechanism to
secure traffic between the AP and the AR. A shared-secret mechanism secure traffic between the WTP and the AC. A shared-secret mechanism
will be added in a future version. will be added in a future version.
A.1 Securing AP-AR communications 10.1 Securing WTP-AC communications
While it is generally straightforward to produce network While it is generally straightforward to produce network
installations in which the communications medium between the AP and installations in which the communications medium between the WTP and
AR is not accessible to the casual user (e.g. these LAN segments are AC is not accessible to the casual user (e.g. these LAN segments are
isolated, no RJ45 or other access ports exist between the AP and the isolated, no RJ45 or other access ports exist between the WTP and the
AR), this will not always be the case. Furthermore, a determined AC), this will not always be the case. Furthermore, a determined
attacker may resort to various more sophisticated monitoring and/or attacker may resort to various more sophisticated monitoring and/or
access techniques, thereby compromising the integrity of this access techniques, thereby compromising the integrity of this
connection. connection.
In general, a certain level of threat on the local (wired) LAN is In general, a certain level of threat on the local (wired) LAN is
expected and accepted in most computing environments. That is, it is expected and accepted in most computing environments. That is, it is
expected that in order to provide users with an acceptable level of expected that in order to provide users with an acceptable level of
service and maintain reasonable productivity levels, a certain amount service and maintain reasonable productivity levels, a certain amount
of risk must be tolerated. It is generally believed that a certain of risk must be tolerated. It is generally believed that a certain
perimeter is maintained around such LANs, that an attacker must have perimeter is maintained around such LANs, that an attacker must have
access to the building(s) in which such LANs exist, and that they access to the building(s) in which such LANs exist, and that they
must be able to "plug in" to the LAN in order to access the network. must be able to "plug in" to the LAN in order to access the network.
With these things in mind, we can begin to assess the general With these things in mind, we can begin to assess the general
security requirements for AR-AP communications. While an in-depth security requirements for AC-WTP communications. While an in-depth
security analysis of threats and risks to these communication is security analysis of threats and risks to these communication is
beyond the scope of this document, some discussion of the motivation beyond the scope of this document, some discussion of the motivation
for various security-related design choices is useful. The for various security-related design choices is useful. The
assumptions driving the security design thus far include the assumptions driving the security design thus far include the
following: following:
o AP-AR communications take place over a wired connection which may o WTP-AC communications take place over a wired connection which may
be accessible to a sophisticated attacker be accessible to a sophisticated attacker
o access to this connection is not trivial for an outsider (i.e. o access to this connection is not trivial for an outsider (i.e.
someone who does not "belong" in the building) to access someone who does not "belong" in the building) to access
o if authentication and/or privacy of end to end traffic for which o if authentication and/or privacy of end to end traffic for which
the AP and AR are intermediaries is required, this may be provided the WTP and AC are intermediaries is required, this may be
via IPsec [12]. provided via IPsec [11].
o privacy and authentication for at least some AP-AR control traffic o privacy and authentication for at least some WTP-AC control
is required (e.g. WEP keys for user sessions, passed from AR to traffic is required (e.g. WEP keys for user sessions, passed from
AP) AC to WTP)
o the AR can be trusted to generate strong cryptographic keys o the AC can be trusted to generate strong cryptographic keys
AR-AP traffic can be considered to consist of two types: data traffic AC-WTP traffic can be considered to consist of two types: data
(e.g. to or from an end user), and control traffic which is strictly traffic (e.g. to or from an end user), and control traffic which is
between the AR and AP. Since data traffic may be secured using IPsec strictly between the AC and WTP. Since data traffic may be secured
(or some other end-to-end security mechanism), we confine our using IPsec (or some other end-to-end security mechanism), we confine
solution to control traffic. The resulting security consists of two our solution to control traffic. The resulting security consists of
components: an authenticated key exchange, and control traffic two components: an authenticated key exchange, and control traffic
security encapsulation. The security encapsulation is accomplished security encapsulation. The security encapsulation is accomplished
using CCM, described in [2]. This encapsulation provides for strong using AES CCM, described in [3]. This encapsulation provides for
AES-based authentication and encryption. The exchange of strong AES-based authentication and encryption. The exchange of
cryptographic keys used for CCM is described below. cryptographic keys used for CCM is described below.
A.2 Authenticated Key Exchange 10.2 LWAPP Frame Encryption
The AR and AP accomplish mutual authentication and a cryptographic While, the LWAPP protocol uses AES-CCM to encrypt control traffic, it
key exchange in a single round trip using the JOIN request/response is important to note that not all control frames are encrypted. The
pair. To accomplish this, the AP includes its identity certificate LWAPP discovery and join phase are not encrypted. The Discovery
(see Section 5.24) and a randomly-generated session ID (see Section messages are sent in the clear since there does not exist a security
5.25) which functions as a cryptographic nonce in the JOIN request. association between the WTP and the AC during the discovery phase.
The AR verifies the AP's certificate, and replies with its own The Join phase is used to negotiate symmetric session keys (see
identity certificate, and a signed concatenation of the session ID Section 6.2.4).
and and encrypted cryptographic session key. This exchange is
detailed below, using the following notation: Once the join phase has been successfully completed, the LWAPP state
o Kpriv - the private key of a public-private key pair. machine Figure 3 will move to the Configure state, at which time all
LWAPP control frames are encrypted using AES-CCM.
Encryption of a control message begins at the Message Element field,
meaning tha the Msg Type, Seq Num, Msg Element Length and Session ID
fields are left intact (see Section 4.2.1).
The AES-CCM 12 byte authentication data is appended to the end of the
message. The authentication data is calculated from the start of the
LWAPP packet, and includes the complete LWAPP header.
The AES-CCM block cipher protocol requires an initialization vector.
The IV is initialized on both the WTP and the AC to the Session ID,
and the IV is monotonically increased for every packet transmitted.
Note that the IV is implicit, and is not transmitted in the LWAPP
header, and therefore an LWAPP device MUST keep track of both
bi-directional IVs. The IV is 13 bytes long, and the first byte is
set to zero, while the remaining four bytes are set to the
monotonically increasing 32 bit counter previously mentioned.
10.3 Authenticated Key Exchange
The AC and WTP accomplish mutual authentication and a cryptographic
key exchange in a single round trip using the Join Request and
Response pair (see Section 6.1).
The following notations are used throughout this section:
o Kpriv - the private key of a public-private key pair
o Kpub - the public key of the pair o Kpub - the public key of the pair
o KeyMaterial - clear text LWAPP session key, randomly generated on
the AC when it receives the Join Request
o SessionID - randomly generated LWAPP session identifier, provided
by the WTP in the Join Request
o M - a clear-text message o M - a clear-text message
o C - a cipher-text message. o C - a cipher-text message.
o S - signed cipher-text message.
o PKCS1(z) - the PKCS#1 encapsulation of z o PKCS1(z) - the PKCS#1 encapsulation of z
o E-x{Kpriv, M} - encryption of M using X's private key o E-x{Kpriv, M} - encryption of M using X's private key
o E-x{Kpub, M} - encryption of M using X's public key o E-x{Kpub, M} - encryption of M using X's public key
o S-x{M} - a digital signature over M produced by X o S-x{M} - a digital signature over M produced by X
o V-x{S-x, M} - verification of X's digital signature over M o V-x{S-x, M} - verification of X's digital signature over M
o D-x{Kpriv, C} - decryption of C using X's private key o D-x{Kpriv, C} - decryption of C using X's private key
o D-x{Kpub, C} - decryption of C using X's public key o D-x{Kpub, C} - decryption of C using X's public key
o Certificate-AR - AR's Certificate o Certificate-AC - AC's Certificate
o Certificate-AP - AP's Certificate o Certificate-WTP - WTP's Certificate
When the AR receives the SessionID value along with the AP's Note that the constant 'x' is used in the above notations to
certificate, it constructs the reply payload as follows: represent one of the parties in the LWAPP exchange. For instance, if
o Randomly generate enough key material to produce an encryption key the WTP must encrypt some text, it would use its own private key, and
and an authentication hash key (xx bytes in length). [TBD: therefore the notation "E-wtp{Kpriv, M}" would be used.
detailed key material generation instructions]
o Compute C1 = E-ap{ Kpub , PKCS1(KeyMaterial)}; this encrypts the
PKCS#1-encoded key material with the public key of the AP, so that
only the AP can decrypt it and determine the session keys.
o Compute S1 = S-ar{SessionID|C1}; this computes the AR's digital
signature over the concatenation of the nonce and the encrypted
key material, and can be verified using the public key of the AR,
"proving" that the AR produced this; this forms the basis of trust
for the AP with respect to the source of the session keys.
o AR sends (Certificate-AR, C1, S1, SessionID) to AP The following text describes the exchange between the WTP and the AC
o AP verifies that SessionID matches an outstanding request that creates a session key, which is used to secure LWAPP control
o AP verifies authenticity of Certificate-AR messages.
o AP computes V-ar{S1, SessionID|C1}, verifying the AR's signature o The WTP adds the Certificate message element (see Section 6.1.6)
over the session identifier and the encrypted key material with the contents set to Certificate-WTP in the Join Request.
o AP computes PKCS1(KeyMaterial) = D-ar{ Kpriv , C1}, decrypting the o The WTP adds the Session ID message element (see Section 6.1.7)
with the contents set to a randomly generated session identifer
(see [4]) in the Join Request. The WTP MUST save the Session ID
in order to validate the Join Response.
o Upon receiving the Join Request, the AC verifies Certificate-WTP,
encoded in the Certificate message element.
o The AC Randomly generates 4 random session keys. The four keys
are (in order) a 16 byte Transmission AES key, a 16 byte Reception
AES Key, a 20 byte HMAC-SHA1 Transmission Key and a 20 byte
HMAC-SHA1 Reception Key. These four keys are concatenated into a
single bit string, which is now referred to as KeyMaterial. The
directionality of these keys is from the standpoint of the AC.
o The AC encrypts the key into cipher-text (C), using E-wtp{Kpub ,
PKCS1(KeyMaterial)}. This encrypts the PKCS#1-encoded key
material with the public key of the WTP, so that only the WTP can
decrypt it and determine the session keys.
o The AC compute a signature (S), using S-ac{SessionID|C} of the
cipher-text; this computes the AC's digital signature over the
concatenation of the 32-bit SessionID and the encrypted key
material (C), and can be verified using the public key of the AC,
"proving" that the AC produced this; this forms the basis of trust
for the WTP with respect to the source of the session keys
(KeyMaterial).
o AC creates the Join Response, and includes two message elements.
Certificate-AC in included in the Certificate message element.
The Session Key message element is added, with the Session ID
encoded and the signed cipher-text (S) included in the Session Key
field. The resulting Join Response is sent to the WTP.
o WTP verifies that SessionID in the Join Response's Session Key
message element matches an outstanding request
o WTP verifies authenticity of Certificate-AC in the Join Response's
Certificate message element.
o WTP computes V-ac{S, SessionID|C}, where S is the Session Key
field of the Session Key message element, verifying the AC's
signature over the session identifier and the encrypted key
material
o WTP computes PKCS1(KeyMaterial) = D-ac{Kpriv , C}, decrypting the
session keys using its private key; since these were encrypted session keys using its private key; since these were encrypted
with the AP's public key, only the AP can successfully decrypt with the WTP's public key, only the WTP can successfully decrypt
this. this.
KeyMaterial is divided into the encryption key and the HMAC key KeyMaterial is divided into the four transmission and reception
[TBD: say how] From this point on, all control protocol payloads AES and HMAC-SHA1 session keys. From this point on, all control
between the AP and AR are encrypted and authenticated. The protocol payloads between the WTP and AC are encrypted and
related payloads are described in the sections above. authenticated. The related payloads are described in the sections
above.
A.3 Refreshing Cryptographic Keys 10.4 Refreshing Cryptographic Keys
Since AR-AP associations will tend to be relatively long-lived, it is Since AC-WTP associations will tend to be relatively long-lived, it
sensible to periodically refresh the encryption and authentication is sensible to periodically refresh the encryption and authentication
keys; this is referred to as "rekeying". When the key lifetime keys; this is referred to as "rekeying". When the key lifetime
reaches 95% of the configured value, the rekeying will proceed as reaches 95% of the configured value, identified in the KeyLifetime
follows: timer (see Section 12), the rekeying will proceed as follows:
o AP generates a fresh SessionID value, and constructs a TLV payload o WTP generates a fresh random Session identier value and encodes it
of type SESSION which contains new SessionID and sends it in within the Key Update Request's Session ID message elemenet. The
KEY-UPDATE message to AR. new session identifier is saved on the WTP in order to verify the
o When the AR receives KEY-UPDATE request with SessionID it Key Update Response. The Key Update Request is sent to the AC.
constructs the reply payload as follows: o When the AC receives Key Update Request with the SessionID message
i) Randomly generate enough key material to produce an encryption element, the AC randomly generates 4 random session keys. The
key and an authentication hash key (xx bytes in length). four keys are (in order) a 16 byte Transmission AES key, a 16 byte
[TBD:detailed key material generation instructions] Reception AES Key, a 20 byte HMAC-SHA1 Transmission Key and a 20
ii) Compute C1 = E-ap{ Kpub , PKCS1(KeyMaterial)}; this encrypts byte HMAC-SHA1 Reception Key. These four keys are concatenated
the PKCS#1-encoded key material with the public key of the AP, into a single bit string, which is now referred to as KeyMaterial.
so that only the AP can decrypt it and determine the session The directionality of these keys is from the standpoint of the AC.
keys.
iii) Compute S1 = S-ar{SessionID|C1}; this computes the AR's
digital signature over the concatenation of the sessionId and
the encrypted key material, and can be verified using the
public key of the AR, "proving" that the AR produced this; this
forms the basis of trust for the AP with respect to the source
of the session keys.
iv) AR then sends a KEY-UPDATE-RSP message to the AP using the new
session values.
o AP must maintain session state for the original SessionID and keys
until it receives the KEY-UPDATE-RSP, at which time it clears the
old session.
o If AP does not receive the KEY-UPDATE-RSP within a reasonable
period of time (1 minute?), it will resend the original request
and reset its response timer. If no response occurs by the time
the original session expires, the AP will delete the new and old
session information, and initiate the DISCOVER process anew.
Appendix B. Wireless Bindings o The AC encrypts the key into cipher-text (C), using E-wtp{Kpub ,
PKCS1(KeyMaterial)}. This encrypts the PKCS#1-encoded key
material with the public key of the WTP, so that only the WTP can
decrypt it and determine the session keys.
o The AC compute a signature (S), using S-ac{SessionID|C} of the
cipher-text; this computes the AC's digital signature over the
concatenation of the 32-bit SessionID and the encrypted key
material (C), and can be verified using the public key of the AC,
"proving" that the AC produced this; this forms the basis of trust
for the WTP with respect to the source of the session keys
(KeyMaterial).
o AC then sends a Key Update Response message to the WTP using the
old session key. Once the message has been sent, the new session
key is plumbed into the AC's crypto engine.
o WTP verifies that SessionID in the Key Update Response's Session
Key message element matches an outstanding request
o WTP computes V-ac{S, SessionID|C}, where S is the Session Key
field of the Session Key message element, verifying the AC's
signature over the session identifier and the encrypted key
material
o WTP computes PKCS1(KeyMaterial) = D-ac{Kpriv , C}, decrypting the
session keys using its private key; since these were encrypted
with the WTP's public key, only the WTP can successfully decrypt
this.
o KeyMaterial is divided into the four transmission and reception
AES and HMAC-SHA1 session keys. From this point on, all control
protocol payloads between the WTP and AC are encrypted and
authenticated using the new session keys. The related payloads
are described in the sections above.
Each wireless technology supported by LWAPP has an associated If WTP does not receive the Key Update Response by the time the
binding. LWAPP is designed to support multiple wireless technologies ResponseTimeout timer expires (see Section 12), the WTP MUST delete
using this method of specification. The binding is divided into the new and old session information, and reset the state machine to
three portions: transport specific, ref. Section 7; LWAPP data the Idle state.
message, ref. Section 4; LWAPP control message, ref. Section 4.
B.1 IEEE 802.11 Binding 11. IEEE 802.11 Binding
B.1.1 Transport specific bindings 11.1 Transport specific bindings
All LWAPP transports have the following IEEE 802.11 specific All LWAPP transports have the following IEEE 802.11 specific
bindings: bindings:
B.1.1.1 Status and WLANS field (16 bits) 11.1.1 Status and WLANS field
The interpretation of this field depends on the direction of The interpretation of this 16 bit field depends on the direction of
transmission of the packet. Refer to the figure in Section 7.1.5. transmission of the packet. Refer to the figure in Section
Section 3.1.
Status Status
When an LWAPP packet is transmitted from an AP to an AR, this field When an LWAPP packet is transmitted from an WTP to an AC, this field
is called the status field and indicates radio resource information is called the status field and indicates radio resource information
associated with the frame. When the message is an LWAPP control associated with the frame. When the message is an LWAPP control
message this field is transmitted as zero. message this field is transmitted as zero.
The status field is divided into the signal strength and signal to The status field is divided into the signal strength and signal to
noise ratio with which an IEEE 802.11 frame was received, encoded in noise ratio with which an IEEE 802.11 frame was received, encoded in
the following manner: the following manner:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSSI | SNR | | RSSI | SNR |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RSSI (8 bits) RSSI
RSSI is a signed, 8-bit value. It is the received signal strength RSSI is a signed, 8-bit value. It is the received signal strength
indication, in dBm. indication, in dBm.
SNR (8 bits) SNR
SNR is a signed, 8-bit value. It is the signal to noise ratio of the SNR is a signed, 8-bit value. It is the signal to noise ratio of the
received IEEE 802.11 frame, in dB. received IEEE 802.11 frame, in dB.
WLANS field (16 bits) WLANS field
When an LWAPP data message is transmitted from an AR to an AP, this When an LWAPP data message is transmitted from an AC to an WTP, this
field indicates on which WLANs the encapsulated IEEE 802.11 frame is 16 bit field indicates on which WLANs the encapsulated IEEE 802.11
to be transmitted. For unicast packets, this field is not used by frame is to be transmitted. For unicast packets, this field is not
the AP. For broadcast or multicast packets, the AP might require used by the WTP. For broadcast or multicast packets, the WTP might
this information if it provides encryption services. require this information if it provides encryption services.
Given that a single broadcast or multicast packet might need to be Given that a single broadcast or multicast packet might need to be
sent to multiple wireless LANs (presumably each with a different sent to multiple wireless LANs (presumably each with a different
broadcast key), this field is defined as a bit field. A bit set broadcast key), this field is defined as a bit field. A bit set
indicates a WLAN ID (see Section 5.27) which will be sent the data. indicates a WLAN ID (see Section Section 11.4.1.1) which will be sent
The WLANS field is encoded in the following manner: the data. The WLANS field is encoded in the following manner:
0 1 0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WLAN ID(s) | | WLAN ID(s) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B.1.2 Data Message bindings 11.2 Data Message bindings
There are no LWAPP Data Message bindings for IEEE 802.11. There are no LWAPP Data Message bindings for IEEE 802.11.
B.1.3 Control Message bindings 11.3 Control Message bindings
The IEEE 802.11 binding has the following Control Message The IEEE 802.11 binding has the following Control Message
definitions. Control Message Bindings are arranged according to the definitions.
four Control Message types:
Control Channel Message Bindings
AR Configuration Message Bindings
Mobile Session Management Bindings
Firmware Management Bindings
Refer to Section 5 and to this binding for the generic and binding 11.3.1 Mobile Config Request
specific message element type definitions.
B.1.3.1 Control Channel Message Bindings This section contains the 802.11 specific message elements that are
used with the Mobile Config Request.
There are no Control Channel Message bindings within the Control 11.3.1.1 Add Mobile
Message Bindings for IEEE 802.11.
B.1.3.2 AR Configuration Message Bindings The Add Mobile Request is used by the AC to inform an WTP that it
should forward traffic from a particular mobile station. The add
mobile request may also include security parameters that must be
enforced by the WTP for the particular mobile.
Configure Request Message When the AC sends an Add Mobile Request, it includes any security
The Configure Request carries the following message elements: parameters that may be required. An AC that wishes to update a
Administrative State (for the AP) mobile's policy on an WTP may be done by simply sending a new Add
AR Name Mobile message element.
Administrative State (for each radio)
AP WLAN Radio Configuration (for each radio)
Multi-domain Capability (for each radio)
MAC Operation (for each radio)
PHY TX Power (for each radio)
PHY TX Power Level (for each Radio)
PHY DSSS Payload or PHY OFDM Payload (for each radio)
Antenna (for each radio)
Supported Rates (for each radio)
Configure Response Message When an WTP receives an Add Mobile message element, it must first
override any existing state it may have for the mobile station in
question. The latest Add Mobile overrides any previously received
messages. If the Add Mobile message element's EAP Only bit is set,
the WTP MUST drop all 802.11 packets that do not contain EAP packets.
Note that when EAP Only is set, the Encryption Policy field MAY have
additional values, and therefore it is possible to inform an WTP to
only accept encrypted EAP packets. Once the mobile station has
successfully completed EAP authentication, the AC must send a new Add
Mobile message element to push the session key down to the WTP as
well as to remove the EAP Only restriction.
The Configure Response carries the following message elements: If the QoS field is set, the WTP MUST observe and provide policing of
Result Code the 802.11e priority tag to ensure that it does not exceed the value
AP WLAN Radio Configuration (for each radio) provided by the AC.
Operational Rate Set (for each radio)
Multi-domain Capability (for each radio)
MAC Operation (for each radio)
PHY Tx Power (for each Radio)
PHY DSSS or PHY OFDM Payload (for each radio)
Antenna (for each radio)
B.1.3.3 Mobile Session Management Bindings 0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |E| Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Encrypt Policy | Session Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise TSC... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pairwise RSC... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Capabilities | WLAN ID | WME Mode |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 802.11e Mode | Qos | Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Supported Rates |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Add Mobile Request Type: 29 for Add Mobile
Length: 36
Radio ID: An 8-bit value representing the radio
Association ID: A 16-bit value specifying the 802.11 Association
Identifier
MAC Address: The mobile station's MAC Address
E: The one bit field is set by the AR to inform the WTP that is MUST
NOT accept any 802.11 data frames, other than 802.1X frames. This
is the equivalent of the WTP's 802.1X port for the mobile station
to be in the closed state. When set, the WTP MUST drop any
non-802.1X packets it receives from the mobile station.
Encryption Policy: The policy field informs the WTP how to handle
packets from/to the mobile station. The following values are
supported:
0 - Encrypt WEP 104: All packets to/from the mobile station must
be encrypted using standard 104 bit WEP.
When the AR sends an Add Mobile Request, it includes any security 1 - Clear Text: All packets to/from the mobile station do not
parameters that may be required. Further, if the AR's policy is that require any additional crypto processing by the WTP.
802.1X (or WPA) is required, it must set the 802.1X only bit in the 2 - Encrypt WEP 40: All packets to/from the mobile station must
Add Mobile message element. An AR that wishes to update a mobile's be encrypted using standard 40 bit WEP.
policy on an AP may be done by sending a new Add Mobile Request 3 - Encrypt WEP 128: All packets to/from the mobile station must
message. be encrypted using standard 128 bit WEP.
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
must be encrypted using 128 bit AES CCMP [7]
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using TKIP and authenticated using Michael [12]
Session Key: A 32 octet session key the WTP is to use when
encrypting traffic to or decrypting traffic from the mobile
station. The type of key is determined based on the Encryption
Policy field.
Pairwise TSC: The TSC to use for unicast packets transmitted to the
mobile.
Pairwise RSC: The RSC to use for unicast packets received from the
mobile.
Capabilities: A 16-bit field containing the 802.11 capabilities to
use with the mobile.
WLAN ID: An 8-bit value specifying the WLAN Identifier
WME Mode: A 8-bit boolean used to identify whether the station is
WME capable.
802.11e Mode: A 8-bit boolean used to identify whether the station
is 802.11e capable.
QoS: An 8-bit value specifying the QoS policy to enforce for the
station. The following values are supported: PRC: TO CHECK
0 - Silver (Best Effort)
1 - Gold (Video)
2 - Platinum (Voice)
3 - Bronze (Background)
Supported Rates: The supported rates to be used with the mobile
station.
If 802.1X (or WPA) was established with the mobile station, the AR 11.3.1.2 IEEE 802.11 Mobile Session Key
will need to push the session key the AP must use for encrypting all
traffic to the mobile, which is included in the Mobile Session Key
message element.
Delete Mobile Request The Mobile Session Key Payload message element is sent when the AC
determines that encryption of a mobile station must be performed in
the WTP. This message element MUST NOT be present without the Add
Mobile (see Section 11.3.1.1) message element, and MUST NOT be sent
if the WTP had not specifically advertised support for the requested
encryption scheme (see ???).
Any future packets received from the Mobile must result in a 0 1 2 3
deauthenticate message, as specified in [10]. 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy | Session Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
B.1.3.4 Firmware Management Bindings Type: 105 for IEEE 802.11 Mobile Session Key
Length: >= 11
MAC Address: The mobile station's MAC Address
Encryption Policy: The policy field informs the WTP how to handle
packets from/to the mobile station. The following values are
supported:
0 - Encrypt WEP 104: All packets to/from the mobile station must
be encrypted using standard 104 bit WEP.
1 - Clear Text: All packets to/from the mobile station do not
require any additional crypto processing by the WTP.
2 - Encrypt WEP 40: All packets to/from the mobile station must
be encrypted using standard 40 bit WEP.
3 - Encrypt WEP 128: All packets to/from the mobile station must
be encrypted using standard 128 bit WEP.
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
must be encrypted using 128 bit AES CCMP [7]
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using TKIP and authenticated using Michael [12]
Session Key: The session key the WTP is to use when encrypting
traffic to/from the mobile station.
There are no Firmware Management Message bindings within the Control 11.3.1.3 QoS Profile
Message Bindings for IEEE 802.11.
B.1.4 Message Element Bindings The QoS Profile Payload message element contains the maximum 802.11e
priority tag that may be used by the station. Any packets received
that exceeds the value encoded in this message element must either be
dropped or tagged using the maximum value permitted by to the user.
The priority tag must be between zero (0) and seven (7).
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | 802.1P Precedence Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD for IEEE 802.11 QOS Profile
Length: 12
MAC Address: The mobile station's MAC Address
802.1P Precedence Tag: The maximum 802.1P precedence value that the
WTP will allow in the TID field in the extended 802.11e QOS Data
header.
11.3.1.4 IEEE 802.11 Update Mobile QoS
The Update Mobile QoS message element is used to change the Quality
of Service policy on the WTP for a given mobile station.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Association ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address | QoS Profile | Vlan Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DSCP Tag | 802.1P Tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 106 for IEEE 802.11 Update Mobile QoS
Length: 14
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP
Association ID: The 802.11 Association Identifier.
MAC Address: The mobile station's MAC Address.
QoS Profile: An 8-bit value specifying the QoS policy to enforce for
the station. The following values are supported:
0 - Silver (Best Effort)
1 - Gold (Video)
2 - Platinum (Voice)
3 - Bronze (Background)
VLAN Identifier: PRC.
DSCP Tag: The DSCP label to use if packets are to be DSCP tagged.
802.1P Tag: The 802.1P precedence value to use if packets are to be
802.1P tagged.
11.3.2 WTP Event Request
This section contains the 802.11 specific message elements that are
used with the WTP Event Request message.
11.3.2.1 IEEE 802.11 Statistics
The statistics message element is sent by the WTP to transmit it's
current statistics. The value contains the following fields.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Tx Fragment Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Tx Fragment Cnt| Multicast Tx Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Tx Cnt | Failed Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Failed Count | Retry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Retry Count | Multiple Retry Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Multi Retry Cnt| Frame Duplicate Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Dup Cnt | RTS Success Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTS Success Cnt| RTS Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTS Failure Cnt| ACK Failure Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ACK Failure Cnt| Rx Fragment Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Rx Fragment Cnt| Multicast RX Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mcast Rx Cnt | FCS Error Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS Error Cnt| Tx Frame Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx Frame Cnt | Decryption Errors |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Decryption Errs|
+-+-+-+-+-+-+-+-+
Type: 38 for Statistics
Length: 57
Radio ID: An 8-bit value representing the radio.
Tx Fragment Count: A 32-bit value representing the number of
fragmented frames transmitted.
Multicast Tx Count: A 32-bit value representing the number of
multicast frames transmitted.
Failed Count: A 32-bit value representing the transmit excessive
retries.
Retry Count: A 32-bit value representing the number of transmit
retries.
Multiple Retry Count: A 32-bit value representing the number of
transmits that required more than one retry.
Frame Duplicate Count: A 32-bit value representing the duplicate
frames received.
RTS Success Count: A 32-bit value representing the number of
successfully transmitted Ready To Send (RTS).
RTS Failure Count: A 32-bit value representing the failed
transmitted RTS.
ACK Failure Count: A 32-bit value representing the number of failed
acknowledgements.
Rx Fragment Count: A 32-bit value representing the number of
fragmented frames received.
Multicast RX Count: A 32-bit value representing the number of
multicast frames received.
FCS Error Count: A 32-bit value representing the number of FCS
failures.
Decryption Errors: A 32-bit value representing the number of
Decryption errors that occured on the WTP. Note that this field
is only valid in cases where the WTP provides
encryption/decryption services.
11.4 802.11 Control Messages
This section will define LWAPP Control Messages that are specific to
the IEEE 802.11 binding.
11.4.1 IEEE 802.11 WLAN Config Request
The IEEE 802.11 WLAN Configuration Request is sent by the AC to the
WTP in order to change services provided by the WTP. This control
message is used to either create, update or delete a WLAN on the WTP.
The IEEE 802.11 WLAN Configuration Request is sent as a result of
either some manual admistrative process (e.g., deleting a WLAN), or
automatically to create a WLAN on an WTP. When sent automatically to
create a WLAN, this control message is sent after the LWAPP
Configuration Request message has been received by the WTP.
Upon receiving this control message, the WTP will modify the
necessary services, and transmit an IEEE 802.11 WLAN Configuration
Response.
An WTP MAY provide service for more than one WLAN, therefore every
WLAN is identified through a numerical index. For instance, an WTP
that is capable of supporting up to 16 SSIDs, could accept up to 16
IEEE 802.11 WLAN Configuration Request messages that include the Add
WLAN message element.
Since the index is the primary identifier for a WLAN, an AC SHOULD
attempt to ensure that the same WLAN is identified through the same
index number on all of its WTPs. An AC that does not follow this
approach MUST find some other means of maintaining a WLAN Identifier
to SSID mapping table.
The following subsections define the message elements that are value
for this LWAPP operation. Only one message MUST be present.
11.4.1.1 IEEE 802.11 Add WLAN
The Add WLAN message element is used by the AC to define a wireless
LAN on the WTP. The value contains the following format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN Capability | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Shared Key | WPA Data Len |WPA IE Data ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RSN Data Len |RSN IE Data ...| Reserved .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| WME Data Len |WME IE Data ...| 11e Data Len |11e IE Data ...|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QoS | Auth Type |Broadcast SSID | Reserved... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSID ... |
+-+-+-+-+-+-+-+-+
Type: 7 for IEEE 802.11 Add WLAN
Length: >= 298
Radio ID: An 8-bit value representing the radio.
WLAN Capability: A 16-bit value containing the capabilities to be
advertised by the WTP within the Probe and Beacon messages.
WLAN ID: A 16-bit value specifying the WLAN Identifier.
Encryption Policy: A 32-bit value specifying the encryption scheme
to apply to traffic to and from the mobile station.
The following values are supported:
0 - Encrypt WEP 104: All packets to/from the mobile station must
be encrypted using standard 104 bit WEP.
1 - Clear Text: All packets to/from the mobile station do not
require any additional crypto processing by the WTP.
2 - Encrypt WEP 40: All packets to/from the mobile station must
be encrypted using standard 40 bit WEP.
3 - Encrypt WEP 128: All packets to/from the mobile station must
be encrypted using standard 128 bit WEP.
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
must be encrypted using 128 bit AES CCMP [7]
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using TKIP and authenticated using Michael [12]
6 - Encrypt CKIP: All packets to/from the mobile station must be
encrypted using Cisco TKIP.
Key: A 32 byte Session Key to use with the encryption policy.
Key-Index: The Key Index associated with the key.
Shared Key: A 1 byte boolean that specifies whether the key included
in the Key field is a shared WEP key.
WPA Data Len: Length of the WPA IE.
WPA IE: A 32 byte field containing the WPA Information Element.
RSN Data Len: Length of the RSN IE.
RSN IE: A 64 byte field containing the RSN Information Element.
Reserved: A 49 byte reserved field, which MUST be set to zero (0).
WME Data Len: Length of the WME IE.
WME IE: A 32 byte field containing the WME Information Element.
DOT11E Data Len: Length of the 802.11e IE.
DOT11E IE: A 32 byte field containing the 802.11e Information
Element.
QOS: An 8-bit value specifying the QoS policy to enforce for the
station.
The following values are supported:
0 - Silver (Best Effort)
1 - Gold (Video)
2 - Platinum (Voice)
3 - Bronze (Background)
Auth Type: An 8-bit value specifying the station's authentication
type.
The following values are supported:
0 - Open System
1 - WEP Shared Key
2 - WPA/WPA2 802.1X
3 - WPA/WPA2 PSK
Broadcast SSID: A boolean indicating whether the SSID is to be
broadcast by the WTP.
Reserved: A 40 byte reserved field.
SSID: The SSID attribute is the service set identifier that will be
advertised by the WTP for this WLAN.
11.4.1.2 IEEE 802.11 Delete WLAN
The delete WLAN message element is used to inform the WTP that a
previously created WLAN is to be deleted. The value contains the
following fields:
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 28 for IEEE 802.11 Delete WLAN
Length: 3
Radio ID: An 8-bit value representing the radio
WLAN ID: A 16-bit value specifying the WLAN Identifier
11.4.1.3 IEEE 802.11 Update WLAN
The Update WLAN message element is used by the AC to define a
wireless LAN on the WTP. The value contains the following format:
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID |Encrypt Policy |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Encryption Policy | Key... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Index | Shared Key | WLAN Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 34 for IEEE 802.11 Update WLAN
Length: 43
Radio ID: An 8-bit value representing the radio.
WLAN ID: A 16-bit value specifying the WLAN Identifier.
Encryption Policy: A 32-bit value specifying the encryption scheme
to apply to traffic to and from the mobile station.
The following values are supported:
0 - Encrypt WEP 104: All packets to/from the mobile station must
be encrypted using standard 104 bit WEP.
1 - Clear Text: All packets to/from the mobile station do not
require any additional crypto processing by the WTP.
2 - Encrypt WEP 40: All packets to/from the mobile station must
be encrypted using standard 40 bit WEP.
3 - Encrypt WEP 128: All packets to/from the mobile station must
be encrypted using standard 128 bit WEP.
4 - Encrypt AES-CCMP 128: All packets to/from the mobile station
must be encrypted using 128 bit AES CCMP [7]
5 - Encrypt TKIP-MIC: All packets to/from the mobile station must
be encrypted using TKIP and authenticated using Michael [12]
6 - Encrypt CKIP: All packets to/from the mobile station must be
encrypted using Cisco TKIP.
Key: A 32 byte Session Key to use with the encryption policy.
Key-Index: The Key Index associated with the key.
Shared Key: A 1 byte boolean that specifies whether the key included
in the Key field is a shared WEP key.
WLAN Capability: A 16-bit value containing the capabilities to be
advertised by the WTP within the Probe and Beacon messages.
11.4.2 IEEE 802.11 WLAN Config Response
The IEEE 802.11 WLAN Configuration Response is sent by the WTP to the
AC as an acknowledgement of the receipt of an IEEE 802.11 WLAN
Configuration Request.
This LWAPP control message does not include any message elements.
11.4.3 IEEE 802.11 WTP Event
The IEEE 802.11 WTP Event LWAPP message is used by the WTP in order
to report asynchronous events to the AC. There is no reply message
expected from the AC, except that the message is acknowledged via the
reliable transport.
When the AC receives the IEEE 802.11 WTP Event, it will take whatever
action is necessary, depending upon the message elements present in
the message.
The IEEE 802.11 WTP Event message MUST contain one of the following
message element described in the next subsections.
11.4.3.1 IEEE 802.11 MIC Countermeasures
The MIC Countermeasures message element is sent by the WTP to the AC
to indicate the occurrence of a MIC failure.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | WLAN ID | MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 61 for IEEE 802.11 MIC Countermeasures
Length: 8
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP.
WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier,
on which the MIC failure occurred.
MAC Address: The MAC Address of the mobile station that caused the
MIC failure.
11.4.3.2 IEEE 802.11 WTP Radio Fail Alarm Indication
The WTP Radio Fail Alarm Indication message element is sent by the
WTP to the AC when it detects a radio failure.
0 1 2 3
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Type | Status | Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 95 for WTP Radio Fail Alarm Indication
Length: 4
Radio ID: The Radio Identifier, typically refers to some interface
index on the WTP
Type: The type of radio failure detected. The following values are
supported:
1 - Receiver
2 - Transmitter
Status: An 8-bit boolean indicating whether the radio failure is
being reported or cleared.
Pad: Reserved field MUST be set to zero (0).
11.5 Message Element Bindings
The IEEE 802.11 Message Element binding has the following The IEEE 802.11 Message Element binding has the following
definitions: definitions:
B.1.4.1 Binding AP WLAN Radio Configuration Conf Conf Conf Add
Req Resp Upd Mobile
The AP WLAN radio configuration is used by the AR to configure a IEEE 802.11 WTP WLAN Radio Configuration X X X
Radio on the AP. The message element value contains the following IEEE 802.11 Rate Set X X
IEEE 802.11 Multi-domain Capability X X X
IEEE 802.11 MAC Operation X X X
IEEE 802.11 Tx Power X X X
IEEE 802.11 Tx Power Level X
IEEE 802.11 Direct Sequence Control X X X
IEEE 802.11 OFDM Control X X X
IEEE 802.11 Supported Rates X X
IEEE 802.11 Antenna X X X
IEEE 802.11 CFP Status X X
IEEE 802.11 Broadcast Probe Mode X X
IEEE 802.11 WTP Mode and Type X? X
IEEE 802.11 WTP Quality of Service X X
IEEE 802.11 MIC Error Report From Mobile X
IEEE 802.11 Update Mobile QoS X
IEEE 802.11 Mobile Session Key X
VOIP STUFF
11.5.1 IEEE 802.11 WTP WLAN Radio Configuration
The WTP WLAN radio configuration is used by the AC to configure a
Radio on the WTP. The message element value contains the following
Fields: Fields:
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | Occupancy Limit | | Radio ID | Reserved | Occupancy Limit |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CFP Per | CFP Maximum Duration | BSS ID | | CFP Per | CFP Maximum Duration | BSS ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSS ID | | BSS ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BSS ID | Beacon Period | DTIM Per | | BSS ID | Beacon Period | DTIM Per |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Country String | | Country String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio to configure Type: 8 for IEEE 802.11 WTP WLAN Radio Configuration
Length: 20
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero Reserved: MUST be set to zero
Occupancy Limit: This attribute indicates the maximum amount of Occupancy Limit: This attribute indicates the maximum amount of
time, in TU, that a point coordinator MAY control the usage of the time, in TU, that a point coordinator MAY control the usage of the
wireless medium without relinquishing control for long enough to wireless medium without relinquishing control for long enough to
allow at least one instance of DCF access to the medium. The default allow at least one instance of DCF access to the medium. The
value of this attribute SHOULD be 100, and the maximum value SHOULD default value of this attribute SHOULD be 100, and the maximum
be 1000 value SHOULD be 1000.
CFP Period: The attribute describes the number of DTIM intervals CFP Period: The attribute describes the number of DTIM intervals
between the start of CFPs between the start of CFPs.
CFP Maximum Duration: The attribute describes the maximum duration CFP Maximum Duration: The attribute describes the maximum duration
of the CFP in TU that MAY be generated by the PCF of the CFP in TU that MAY be generated by the PCF.
BSSID: The WLAN Radio's MAC Address BSSID: The WLAN Radio's base MAC Address. For WTPs that support
more than a single WLAN, the value of the WLAN Identifier is added
to the last octet of the BSSID. Therefore, a WTP that supports 16
WLANs MUST have 16 MAC Addresses reserved for it, and the last
nibble is used to represent the WLAN ID.
Beacon Period: This attribute specifies the number of TU that a Beacon Period: This attribute specifies the number of TU that a
station uses for scheduling Beacon transmissions. This value is station uses for scheduling Beacon transmissions. This value is
transmitted in Beacon and Probe Response frames transmitted in Beacon and Probe Response frames.
DTIM Period: This attribute specifies the number of beacon intervals DTIM Period: This attribute specifies the number of beacon intervals
that elapses between transmission of Beacons frames containing a TIM that elapses between transmission of Beacons frames containing a
element whose DTIM Count field is 0. This value is transmitted in TIM element whose DTIM Count field is 0. This value is
the DTIM Period field of Beacon frames transmitted in the DTIM Period field of Beacon frames.
Country Code: This attribute identifies the country in which the Country Code: This attribute identifies the country in which the
station is operating. The first two octets of this string is the two station is operating. The first two octets of this string is the
character country code as described in document ISO/IEC 3166- 1. The two character country code as described in document ISO/IEC 3166-
third octet MUST be one of the following: 1. The third octet MUST be one of the following:
an ASCII space character, if the regulations under which the 1. an ASCII space character, if the regulations under which the
station is operating encompass all environments in the country, station is operating encompass all environments in the
an ASCII 'O' character, if the regulations under which the station country,
is operating are for an outdoor environment only, or 2. an ASCII 'O' character, if the regulations under which the
an ASCII 'I' character, if the regulations under which the station station is operating are for an outdoor environment only, or
is operating are for an indoor environment only 3. an ASCII 'I' character, if the regulations under which the
station is operating are for an indoor environment only
B.1.4.2 Binding Rate Set 11.5.2 IEEE 802.11 Rate Set
The rate set message element value is sent by the AR and contains the The rate set message element value is sent by the AC and contains the
supported operational rates. It contains the following fields. supported operational rates. It contains the following fields.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Rate Set | | Radio ID | Rate Set |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 16 for IEEE 802.11 Rate Set
Length: 4
Radio ID: An 8-bit value representing the radio to configure.
Rate Set: The AC generates the Rate Set that the WTP is to include
in it's Beacon and Probe messages.
Radio ID: An 8-bit value representing the radio to configure 11.5.3 IEEE 802.11 Multi-domain Capability
Rate Set: The AR generates the Rate Set that the AP is to include in
it's Beacon and Probe messages
B.1.4.3 Binding Multi-domain Capability
The multi-domain capability message element is used by the AR to The multi-domain capability message element is used by the AC to
inform the AP of regulatory limits. The value contains the following inform the WTP of regulatory limits. The value contains the
fields. following fields.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | First Channel # | | Radio ID | Reserved | First Channel # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Channels | Max Tx Power Level | | Number of Channels | Max Tx Power Level |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio to configure Type: 10 for IEEE 802.11 Multi-Domain Capability
Length: 8
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero Reserved: MUST be set to zero
First Channnel #: This attribute indicates the value of the lowest First Channnel #: This attribute indicates the value of the lowest
channel number in the subband for the associated domain country channel number in the subband for the associated domain country
string. string.
Number of Channels: This attribute indicates the value of the total Number of Channels: This attribute indicates the value of the total
number of channels allowed in the subband for the associated domain number of channels allowed in the subband for the associated
country string. domain country string.
Max Tx Power Level: This attribute indicates the maximum transmit Max Tx Power Level: This attribute indicates the maximum transmit
power, in dBm, allowed in the subband for the associated domain power, in dBm, allowed in the subband for the associated domain
country string. country string.
B.1.4.4 Binding MAC Operation 11.5.4 IEEE 802.11 MAC Operation
The MAC operation message element is sent by the AR to set the 802.11 The MAC operation message element is sent by the AC to set the 802.11
MAC parameters on the AP. The value contains the following fields. MAC parameters on the WTP. The value contains the following fields.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Radio ID | Reserved | RTS Threshold | | Radio ID | Reserved | RTS Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Short Retry | Long Retry | Fragmentation Threshold | | Short Retry | Long Retry | Fragmentation Threshold |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tx MSDU Lifetime | | Tx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rx MSDU Lifetime | | Rx MSDU Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Radio ID: An 8-bit value representing the radio to configure Type: 11 for IEEE 802.11 MAC Operation
Length: 16
Radio ID: An 8-bit value representing the radio to configure.
Reserved: MUST be set to zero Reserved: MUST be set to zero
RTS Threshold: This attribute indicates the number of octets in an RTS Threshold: This attribute indicates the number of octets in an
MPDU, below which an RTS/CTS handshake MUST NOT be performed. An MPDU, below which an RTS/CTS handshake MUST NOT be performed. An
RTS/CTS handshake MUST be performed at the beginning of any frame RTS/CTS handshake MUST be performed at the beginning of any frame
exchange sequence where the MPDU is of type Data or Management, the exchange sequence where the MPDU is of type Data or Management,
MPDU has an individual address in the Address1 field, and the length the MPDU has an individual address in the Address1 field, and the
of the MPDU is greater than this threshold. Setting this attribute length of the MPDU is greater than this threshold. Setting this
to be larger than the maximum MSDU size MUST have the effect of attribute to be larger than the maximum MSDU size MUST have the
turning off the RTS/CTS handshake for frames of Data or Management effect of turning off the RTS/CTS handshake for frames of Data or
type transmitted by this STA. Setting this attribute to zero MUST Management type transmitted by this STA. Setting this attribute
have the effect of turning on the RTS/CTS handshake for all frames of to zero MUST have the effect of turning on the RTS/CTS handshake
Data or Management type transmitted by this STA. The default value for all frames of Data or Management type transmitted by this STA.
of this attribute MUST be 2347. The default value of this attribute MUST be 2347.
Short Retry: This attribute indicates the maximum number of Short Retry: This attribute indicates the maximum number