idnits 2.17.1 draft-ietf-capwap-protocol-specification-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 6561. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 6538. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 6545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 6551. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 48 instances of too long lines in the document, the longest one being 21 characters in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 21, 2006) is 6518 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'ChangeCipherSpec' on line 1226 -- Looks like a reference, but probably isn't: 'DTLS' on line 1195 == Unused Reference: '2' is defined on line 6409, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 6413, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 6419, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 6438, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 6441, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 6468, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 6471, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 6480, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 6483, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 6486, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 6489, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 6494, but no explicit reference was found in the text == Unused Reference: '27' is defined on line 6499, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Downref: Normative reference to an Informational RFC: RFC 3610 (ref. '3') ** Obsolete normative reference: RFC 1750 (ref. '4') (Obsoleted by RFC 4086) ** Downref: Normative reference to an Informational RFC: RFC 3753 (ref. '5') -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Downref: Normative reference to an Unknown state RFC: RFC 815 (ref. '8') ** Downref: Normative reference to an Informational RFC: RFC 3394 (ref. '9') ** Obsolete normative reference: RFC 1305 (ref. '10') (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 3280 (ref. '11') (Obsoleted by RFC 5280) ** Downref: Normative reference to an Informational RFC: RFC 4017 (ref. '13') ** Obsolete normative reference: RFC 4346 (ref. '15') (Obsoleted by RFC 5246) -- Possible downref: Non-RFC (?) normative reference: ref. '16' -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Obsolete informational reference (is this intentional?): RFC 2401 (ref. '21') (Obsoleted by RFC 4301) Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Calhoun, Editor 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 23, 2006 M. Montemurro, Editor 5 Research In Motion 6 D. Stanley, Editor 7 Aruba Networks 8 June 21, 2006 10 CAPWAP Protocol Specification 11 draft-ietf-capwap-protocol-specification-02 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 23, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 42 Abstract 44 Wireless LAN product architectures have evolved from single 45 autonomous access points to systems consisting of a centralized 46 controller and Wireless Termination Points (WTPs). The general goal 47 of centralized control architectures is to move access control, 48 including user authentication and authorization, mobility management 49 and radio management from the single access point to a centralized 50 controller. 52 This specification defines the Control And Provisioning of Wireless 53 Access Points (CAPWAP) Protocol. The CAPWAP protocol meets the IETF 54 CAPWAP working group protocol requirements. The CAPWAP protocol is 55 designed to be flexible, allowing it to be used for a variety of 56 wireless technologies. This document describes the base CAPWAP 57 protocol, including an extension which supports the IEEE 802.11 58 wireless LAN protocol. Future extensions will enable support of 59 additional wireless technologies. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 64 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 1.2. Conventions used in this document . . . . . . . . . . . 8 66 1.3. Contributing Authors . . . . . . . . . . . . . . . . . . 9 67 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 10 68 1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . 10 69 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 12 70 2.1. Wireless Binding Definition . . . . . . . . . . . . . . 13 71 2.2. CAPWAP Session Establishment Overview . . . . . . . . . 13 72 2.3. CAPWAP State Machine Definition . . . . . . . . . . . . 15 73 2.3.1. CAPWAP Protocol State Transitions . . . . . . . . . 16 74 2.3.2. CAPWAP to DTLS Commands . . . . . . . . . . . . . . 23 75 2.3.3. DTLS to CAPWAP Notifications . . . . . . . . . . . . 24 76 2.3.4. DTLS State Transitions . . . . . . . . . . . . . . . 24 77 2.4. Use of DTLS in the CAPWAP Protocol . . . . . . . . . . . 27 78 2.4.1. DTLS Handshake Processing . . . . . . . . . . . . . 28 79 2.4.2. DTLS Error Handling . . . . . . . . . . . . . . . . 29 80 2.4.3. DTLS Rehandshake Behavior . . . . . . . . . . . . . 30 81 2.4.4. DTLS EndPoint Authentication . . . . . . . . . . . . 33 82 3. CAPWAP Transport . . . . . . . . . . . . . . . . . . . . . . 36 83 3.1. UDP Transport . . . . . . . . . . . . . . . . . . . . . 36 84 3.2. AC Discovery . . . . . . . . . . . . . . . . . . . . . . 36 85 3.3. Fragmentation/Reassembly . . . . . . . . . . . . . . . . 37 86 4. CAPWAP Packet Formats . . . . . . . . . . . . . . . . . . . . 38 87 4.1. CAPWAP Transport Header . . . . . . . . . . . . . . . . 39 88 4.2. CAPWAP Data Messages . . . . . . . . . . . . . . . . . . 42 89 4.3. CAPWAP Control Messages . . . . . . . . . . . . . . . . 42 90 4.3.1. Control Message Format . . . . . . . . . . . . . . . 43 91 4.3.2. Control Message Quality of Service . . . . . . . . . 45 92 4.4. CAPWAP Protocol Message Elements . . . . . . . . . . . . 45 93 4.4.1. AC Descriptor . . . . . . . . . . . . . . . . . . . 48 94 4.4.2. AC IPv4 List . . . . . . . . . . . . . . . . . . . . 49 95 4.4.3. AC IPv6 List . . . . . . . . . . . . . . . . . . . . 50 96 4.4.4. AC Name . . . . . . . . . . . . . . . . . . . . . . 50 97 4.4.5. AC Name with Index . . . . . . . . . . . . . . . . . 50 98 4.4.6. AC Timestamp . . . . . . . . . . . . . . . . . . . . 51 99 4.4.7. Add MAC ACL Entry . . . . . . . . . . . . . . . . . 51 100 4.4.8. Add Mobile Station . . . . . . . . . . . . . . . . . 52 101 4.4.9. Add Static MAC ACL Entry . . . . . . . . . . . . . . 53 102 4.4.10. CAPWAP Timers . . . . . . . . . . . . . . . . . . . 53 103 4.4.11. Data Transfer Data . . . . . . . . . . . . . . . . . 54 104 4.4.12. Data Transfer Mode . . . . . . . . . . . . . . . . . 54 105 4.4.13. Decryption Error Report . . . . . . . . . . . . . . 55 106 4.4.14. Decryption Error Report Period . . . . . . . . . . . 55 107 4.4.15. Delete MAC ACL Entry . . . . . . . . . . . . . . . . 56 108 4.4.16. Delete Mobile Station . . . . . . . . . . . . . . . 56 109 4.4.17. Delete Static MAC ACL Entry . . . . . . . . . . . . 57 110 4.4.18. Discovery Type . . . . . . . . . . . . . . . . . . . 57 111 4.4.19. Duplicate IPv4 Address . . . . . . . . . . . . . . . 58 112 4.4.20. Duplicate IPv6 Address . . . . . . . . . . . . . . . 59 113 4.4.21. Idle Timeout . . . . . . . . . . . . . . . . . . . . 59 114 4.4.22. Image Data . . . . . . . . . . . . . . . . . . . . . 60 115 4.4.23. Image Filename . . . . . . . . . . . . . . . . . . . 60 116 4.4.24. Initiate Download . . . . . . . . . . . . . . . . . 61 117 4.4.25. Location Data . . . . . . . . . . . . . . . . . . . 61 118 4.4.26. MTU Discovery Padding . . . . . . . . . . . . . . . 62 119 4.4.27. Radio Administrative State . . . . . . . . . . . . . 62 120 4.4.28. Result Code . . . . . . . . . . . . . . . . . . . . 63 121 4.4.29. Session ID . . . . . . . . . . . . . . . . . . . . . 64 122 4.4.30. Statistics Timer . . . . . . . . . . . . . . . . . . 64 123 4.4.31. Vendor Specific Payload . . . . . . . . . . . . . . 64 124 4.4.32. WTP Board Data . . . . . . . . . . . . . . . . . . . 65 125 4.4.33. WTP Descriptor . . . . . . . . . . . . . . . . . . . 66 126 4.4.34. WTP Fallback . . . . . . . . . . . . . . . . . . . . 68 127 4.4.35. WTP Frame Tunnel Mode . . . . . . . . . . . . . . . 68 128 4.4.36. WTP IPv4 IP Address . . . . . . . . . . . . . . . . 69 129 4.4.37. WTP MAC Type . . . . . . . . . . . . . . . . . . . . 69 130 4.4.38. WTP Radio Information . . . . . . . . . . . . . . . 70 131 4.4.39. WTP Manager Control IPv4 Address . . . . . . . . . . 71 132 4.4.40. WTP Manager Control IPv6 Address . . . . . . . . . . 71 133 4.4.41. WTP Name . . . . . . . . . . . . . . . . . . . . . . 72 134 4.4.42. WTP Operational Statistics . . . . . . . . . . . . . 72 135 4.4.43. WTP Radio Statistics . . . . . . . . . . . . . . . . 73 136 4.4.44. WTP Reboot Statistics . . . . . . . . . . . . . . . 74 137 4.4.45. WTP Static IP Address Information . . . . . . . . . 76 138 4.5. CAPWAP Protocol Timers . . . . . . . . . . . . . . . . . 77 139 4.5.1. DiscoveryInterval . . . . . . . . . . . . . . . . . 77 140 4.5.2. DTLSRehandshake . . . . . . . . . . . . . . . . . . 77 141 4.5.3. DTLSSessionDelete . . . . . . . . . . . . . . . . . 77 142 4.5.4. EchoInterval . . . . . . . . . . . . . . . . . . . . 77 143 4.5.5. KeyLifetime . . . . . . . . . . . . . . . . . . . . 77 144 4.5.6. MaxDiscoveryInterval . . . . . . . . . . . . . . . . 78 145 4.5.7. NeighborDeadInterval . . . . . . . . . . . . . . . . 78 146 4.5.8. ResponseTimeout . . . . . . . . . . . . . . . . . . 78 147 4.5.9. RetransmitInterval . . . . . . . . . . . . . . . . . 78 148 4.5.10. SilentInterval . . . . . . . . . . . . . . . . . . . 78 149 4.5.11. WaitJoin . . . . . . . . . . . . . . . . . . . . . . 78 150 4.6. CAPWAP Protocol Variables . . . . . . . . . . . . . . . 79 151 4.6.1. DiscoveryCount . . . . . . . . . . . . . . . . . . . 79 152 4.6.2. MaxDiscoveries . . . . . . . . . . . . . . . . . . . 79 153 4.6.3. MaxRetransmit . . . . . . . . . . . . . . . . . . . 79 154 4.6.4. RetransmitCount . . . . . . . . . . . . . . . . . . 79 155 5. CAPWAP Discovery Operations . . . . . . . . . . . . . . . . . 80 156 5.1. Discovery Request Message . . . . . . . . . . . . . . . 80 157 5.2. Discovery Response Message . . . . . . . . . . . . . . . 81 158 5.3. Primary Discovery Request Message . . . . . . . . . . . 81 159 5.4. Primary Discovery Response . . . . . . . . . . . . . . . 82 160 6. CAPWAP Join Operations . . . . . . . . . . . . . . . . . . . 83 161 6.1. Join Request . . . . . . . . . . . . . . . . . . . . . . 83 162 6.2. Join Response . . . . . . . . . . . . . . . . . . . . . 84 163 7. Control Channel Management . . . . . . . . . . . . . . . . . 85 164 7.1. Echo Request . . . . . . . . . . . . . . . . . . . . . . 85 165 7.2. Echo Response . . . . . . . . . . . . . . . . . . . . . 85 166 8. WTP Configuration Management . . . . . . . . . . . . . . . . 86 167 8.1. Configuration Consistency . . . . . . . . . . . . . . . 86 168 8.1.1. Configuration Flexibility . . . . . . . . . . . . . 87 169 8.2. Configuration Status . . . . . . . . . . . . . . . . . . 87 170 8.3. Configuration Status Response . . . . . . . . . . . . . 88 171 8.4. Configuration Update Request . . . . . . . . . . . . . . 88 172 8.5. Configuration Update Response . . . . . . . . . . . . . 89 173 8.6. Change State Event Request . . . . . . . . . . . . . . . 90 174 8.7. Change State Event Response . . . . . . . . . . . . . . 90 175 8.8. Clear Configuration Request . . . . . . . . . . . . . . 90 176 8.9. Clear Configuration Response . . . . . . . . . . . . . . 91 177 9. Device Management Operations . . . . . . . . . . . . . . . . 92 178 9.1. Image Data Request . . . . . . . . . . . . . . . . . . . 92 179 9.2. Image Data Response . . . . . . . . . . . . . . . . . . 93 180 9.3. Reset Request . . . . . . . . . . . . . . . . . . . . . 93 181 9.4. Reset Response . . . . . . . . . . . . . . . . . . . . . 93 182 9.5. WTP Event Request . . . . . . . . . . . . . . . . . . . 93 183 9.6. WTP Event Response . . . . . . . . . . . . . . . . . . . 94 184 9.7. Data Transfer Request . . . . . . . . . . . . . . . . . 94 185 9.8. Data Transfer Response . . . . . . . . . . . . . . . . . 95 186 10. Mobile Session Management . . . . . . . . . . . . . . . . . . 96 187 10.1. Mobile Configuration Request . . . . . . . . . . . . . . 96 188 10.2. Mobile Configuration Response . . . . . . . . . . . . . 96 189 11. IEEE 802.11 Binding . . . . . . . . . . . . . . . . . . . . . 97 190 11.1. Split MAC and Local MAC Functionality . . . . . . . . . 97 191 11.1.1. Split MAC . . . . . . . . . . . . . . . . . . . . . 97 192 11.1.2. Local MAC . . . . . . . . . . . . . . . . . . . . . 99 193 11.2. Roaming Behavior . . . . . . . . . . . . . . . . . . . . 102 194 11.3. Group Key Refresh . . . . . . . . . . . . . . . . . . . 103 195 11.4. BSSID to WLAN ID Mapping . . . . . . . . . . . . . . . . 103 196 11.5. Quality of Service for IEEE 802.11 Control Messages . . 104 197 11.6. IEEE 802.11 Specific CAPWAP Control Messages . . . . . . 104 198 11.6.1. IEEE 802.11 WLAN Configuration Request . . . . . . . 104 199 11.6.2. IEEE 802.11 WLAN Configuration Response . . . . . . 105 200 11.7. CAPWAP Data Message Bindings . . . . . . . . . . . . . . 106 201 11.8. CAPWAP Control Message bindings . . . . . . . . . . . . 107 202 11.8.1. Configuration Status Message . . . . . . . . . . . . 107 203 11.8.2. Configuration Status Response Message . . . . . . . 108 204 11.8.3. Configuration Update Request Message . . . . . . . . 108 205 11.8.4. Mobile Config Request . . . . . . . . . . . . . . . 109 206 11.8.5. WTP Event Request . . . . . . . . . . . . . . . . . 109 207 11.9. IEEE 802.11 Message Element Definitions . . . . . . . . 109 208 11.9.1. IEEE 802.11 Add WLAN . . . . . . . . . . . . . . . . 110 209 11.9.2. IEEE 802.11 Antenna . . . . . . . . . . . . . . . . 114 210 11.9.3. IEEE 802.11 Assigned WTP BSSID . . . . . . . . . . . 115 211 11.9.4. IEEE 802.11 Delete WLAN . . . . . . . . . . . . . . 115 212 11.9.5. IEEE 802.11 Direct Sequence Control . . . . . . . . 116 213 11.9.6. IEEE 802.11 Information Element . . . . . . . . . . 117 214 11.9.7. IEEE 802.11 MAC Operation . . . . . . . . . . . . . 117 215 11.9.8. IEEE 802.11 MIC Countermeasures . . . . . . . . . . 119 216 11.9.9. IEEE 802.11 Mobile . . . . . . . . . . . . . . . . . 120 217 11.9.10. IEEE 802.11 Mobile Session Key . . . . . . . . . . . 121 218 11.9.11. IEEE 802.11 Multi-Domain Capability . . . . . . . . 122 219 11.9.12. IEEE 802.11 OFDM Control . . . . . . . . . . . . . . 123 220 11.9.13. IEEE 802.11 Rate Set . . . . . . . . . . . . . . . . 124 221 11.9.14. IEEE 802.11 RSNA Error Report From Mobile . . . . . 125 222 11.9.15. IEEE 802.11 Station QoS Profile . . . . . . . . . . 126 223 11.9.16. IEEE 802.11 Statistics . . . . . . . . . . . . . . . 127 224 11.9.17. IEEE 802.11 Supported Rates . . . . . . . . . . . . 130 225 11.9.18. IEEE 802.11 Tx Power . . . . . . . . . . . . . . . . 131 226 11.9.19. IEEE 802.11 Tx Power Level . . . . . . . . . . . . . 131 227 11.9.20. IEEE 802.11 Update Mobile QoS . . . . . . . . . . . 132 228 11.9.21. IEEE 802.11 Update WLAN . . . . . . . . . . . . . . 133 229 11.9.22. IEEE 802.11 WTP Quality of Service . . . . . . . . . 134 230 11.9.23. IEEE 802.11 WTP Radio Configuration . . . . . . . . 136 231 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indication . . . . 137 232 11.10. Technology Specific Message Element Values . . . . . . . 138 233 12. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 139 234 13. Security Considerations . . . . . . . . . . . . . . . . . . . 141 235 13.1. CAPWAP Security . . . . . . . . . . . . . . . . . . . . 141 236 13.1.1. Converting Protected Data into Unprotected Data . . 142 237 13.1.2. Converting Unprotected Data into Protected Data 238 (Insertion) . . . . . . . . . . . . . . . . . . . . 142 239 13.1.3. Deletion of Protected Records . . . . . . . . . . . 142 240 13.1.4. Insertion of Unprotected Records . . . . . . . . . . 142 241 13.2. Use of Preshared Keys in CAPWAP . . . . . . . . . . . . 142 242 13.3. Use of Certificates in CAPWAP . . . . . . . . . . . . . 143 243 13.4. AAA Security . . . . . . . . . . . . . . . . . . . . . . 144 244 13.5. IEEE 802.11 Security . . . . . . . . . . . . . . . . . . 144 245 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 146 246 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 147 247 15.1. Normative References . . . . . . . . . . . . . . . . . . 147 248 15.2. Informational References . . . . . . . . . . . . . . . . 148 249 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 150 250 Intellectual Property and Copyright Statements . . . . . . . . . 151 252 1. Introduction 254 The emergence of centralized architectures, in which simple IEEE 255 802.11 WTPs are managed by an Access Controller (AC) suggests that a 256 standards based, interoperable protocol could radically simplify the 257 deployment and management of wireless networks. WTPs require a set 258 of dynamic management and control functions related to their primary 259 task of connecting the wireless and wired mediums. Traditional 260 protocols for managing WTPs are either manual static configuration 261 via HTTP, proprietary Layer 2 specific or non-existent (if the WTPs 262 are self-contained). This document describes the CAPWAP Protocol, a 263 standard, interoperable protocol which enables an AC to manage a 264 collection of WTPs. While the protocol is defined to be independent 265 of layer 2 technology, an IEEE 802.11 binding is provided to support 266 IEEE 802.11 wireless LAN networks. 268 CAPWAP assumes a network configuration consisting of multiple WTPs 269 communicating via the Internet Protocol (IP) to an AC. WTPs are 270 viewed as remote RF interfaces controlled by the AC. The CAPWAP 271 protocol supports two modes of operation: Split and Local MAC. In 272 Split MAC mode all L2 wireless data and management frames are 273 encapsulated via the CAPWAP protocol and exchanged between the AC and 274 the WTP. In the example of 802.11, as shown in Figure 1, the 802.11 275 frames received from a mobile node (STA) are directly encapsulated by 276 the WTP and forwarded to the AC. 278 +-+ 802.11 frames +-+ 279 | |--------------------------------| | 280 | | +-+ | | 281 | |--------------| |---------------| | 282 | | 802.11 PHY/ | | CAPWAP | | 283 | | MAC sublayer | | | | 284 +-+ +-+ +-+ 285 STA WTP AC 287 Figure 1: Representative CAPWAP Architecture for Split MAC 289 The Local MAC mode of operation allows for the data frames to be 290 either locally bridged, or tunneled as 802.3 frames. The latter 291 implies that the WTP performs the 802 bridging function. In either 292 case the L2 wireless management frames are processed locally by the 293 WTP, and then forwarded to the AC. Figure 2 provides an example 294 using the IEEE 802.11 binding, where a station transmits an 802.11 295 frame, which is encapsulated as 802.3 and forwarded to the AC. 297 +-+ 802.11 frames +-+ 802.3 frames +-+ 298 | |---------------| |--------------| | 299 | | | | | | 300 | |---------------| |--------------| | 301 | | 802.11 PHY/ | | CAPWAP | | 302 | | MAC sublayer | | | | 303 +-+ +-+ +-+ 304 STA WTP AC 306 Figure 2: Representative CAPWAP Architecture for Local MAC 308 Provisioning WTPs with security credentials, and managing which WTPs 309 are authorized to provide service are traditionally handled by 310 proprietary solutions. Allowing these functions to be performed from 311 a centralized AC in an interoperable fashion increases manageability 312 and allows network operators to more tightly control their wireless 313 network infrastructure. 315 1.1. Goals 317 The goals for the CAPWAP protocol are listed below: 319 1. To centralize the authentication and policy enforcement functions 320 for a wireless network. The AC may also provide centralized 321 bridging, forwarding, and encryption of user traffic. 322 Centralization of these functions will enable reduced cost and 323 higher efficiency by applying the capabilities of network 324 processing silicon to the wireless network, as in wired LANs. 326 2. To enable shifting of the higher level protocol processing from 327 the WTP. This leaves the time critical applications of wireless 328 control and access in the WTP, making efficient use of the 329 computing power available in WTPs which are the subject to severe 330 cost pressure. 332 3. To provide a generic encapsulation and transport mechanism, 333 enabling the CAPWAP protocol to be applied to other access point 334 types in the future, via a specific wireless binding. 336 The CAPWAP protocol concerns itself solely with the interface between 337 the WTP and the AC. Inter-AC, or mobile node (STA) to AC 338 communication is strictly outside the scope of this document. 340 1.2. Conventions used in this document 342 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 343 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 344 document are to be interpreted as described in RFC 2119 [1]. 346 1.3. Contributing Authors 348 This section lists and acknowledges the authors of significant text 349 and concepts included in this specification. [Note: This section 350 needs work to accurately reflect the contribution of each author and 351 this work will be done in revision 01 of this document.] 353 The CAPWAP Working Group selected the Lightweight Access Point 354 Protocol (LWAPP) [add reference, when available]to be used as the 355 basis of the CAPWAP protocol specification. The following people are 356 authors of the LWAPP document: 358 Bob O'Hara, Cisco Systems, Inc.,170 West Tasman Drive, San Jose, CA 95134 359 Phone: +1 408-853-5513, Email: bob.ohara@cisco.com 361 Pat Calhoun, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 362 Phone: +1 408-853-5269, Email: pcalhoun@cisco.com 364 Rohit Suri, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 365 Phone: +1 408-853-5548, Email: rsuri@cisco.com 367 Nancy Cam Winget, Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134 368 Phone: +1 408-853-0532, Email: ncamwing@cisco.com 370 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 371 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 373 Michael Glenn Williams, Nokia, Inc., 313 Fairchild Drive, Mountain View, CA 94043 374 Phone: +1 650-714-7758, Email: Michael.G.Williams@Nokia.com 376 Sue Hares, Nexthop Technologies, Inc., 825 Victors Way, Suite 100, Ann Arbor, MI 48108 377 Phone: +1 734 222 1610, Email: shares@nexthop.com 379 DTLS is used as the security solution for the CAPWAP protocol. The 380 following people are authors of significant DTLS-related text 381 included in this document: 383 Scott Kelly, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 384 Phone: +1 408-754-8408, Email: skelly@arubanetworks.com 386 Eric Rescorla, Network Resonance, 2483 El Camino Real, #212,Palo Alto CA, 94303 387 Email: ekr@networkresonance.com 389 The concept of using DTLS to secure the CAPWAP protocol was part of 390 the Secure Light Access Point Protocol (SLAPP) proposal [add 391 reference when available]. The following people are authors of the 392 SLAPP proposal: 394 Partha Narasimhan, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 395 Phone: +1 408-480-4716, Email: partha@arubanetworks.com 397 Dan Harkins, Tropos Networks, 555 Del Rey Avenue, Sunnyvale, CA, 95085 398 Phone: +1 408 470 7372, Email: dharkins@tropos.com 400 Subbu Ponnuswamy, Aruba Networks, 1322 Crossman Ave, Sunnyvale, CA 94089 401 Phone: +1 408-754-1213, Email: subbu@arubanetworks.com 403 1.4. Acknowledgements 405 The authors thank Michael Vakulenko for contributing text that 406 describes how CAPWAP can be used over a layer 3 (IP/UDP) network. 408 The authors thank Russ Housley and Charles Clancy for their 409 assistance in provide a security review of the LWAPP specification. 410 Charles' review can be found at [16]. 412 1.5. Terminology 414 Station (STA): A device that contains an IEEE 802.11 conformant 415 medium access control (MAC) and physical layer (PHY) interface to the 416 wireless medium (WM). 418 Basic Service Set (BSS): A set of stations controlled by a single 419 coordination function. 421 Portal: The logical point at which medium access control (MAC) 422 service data units (MSDUs) from a non-IEEE 802.11 local area network 423 (LAN) enter the distribution system (DS) of an extended service set 424 (ESS). 426 Distribution System Service (DSS): The set of services provided by 427 the distribution system (DS) that enable the medium access control 428 (MAC) layer to transport MAC service data units (MSDUs) between 429 stations that are not in direct communication with each other over a 430 single instance of the wireless medium (WM). These services include 431 the transport of MSDUs between the access points (APs) of basic 432 service sets (BSSs) within an extended service set (ESS), transport 433 of MSDUs between portals and BSSs within an ESS, and transport of 434 MSDUs between stations in the same BSS in cases where the MSDU has a 435 multicast or broadcast destination address, or where the destination 436 is an individual address, but the station sending the MSDU chooses to 437 involve DSS. DSSs are provided between pairs of IEEE 802.11 MACs. 439 Integration: The service that enables delivery of medium access 440 control (MAC) service data units (MSDUs) between the distribution 441 system (DS) and an existing, non-IEEE 802.11 local area network (via 442 a portal). 444 Distribution: The service that, by using association information, 445 delivers medium access control (MAC) service data units (MSDUs) 446 within the distribution system (DS). 448 2. Protocol Overview 450 The CAPWAP protocol is a generic protocol defining AC and WTP control 451 and data plane communication via a CAPWAP protocol transport 452 mechanism. CAPWAP control messages, and optionally CAPWAP data 453 messages, are secured using Datagram Transport Layer Security (DTLS) 454 [15]. DTLS is a standards-track IETF protocol based upon TLS. The 455 underlying security-related protocol mechanisms of TLS have been 456 successfully deployed for many years. 458 The CAPWAP protocol Transport layer carries two types of payload, 459 CAPWAP Data messages and CAPWAP Control messages. CAPWAP Data 460 messages encapsulate forwarded wireless frames. CAPWAP protocol 461 Control messages are management messages exchanged between a WTP and 462 an AC. The CAPWAP Data and Control packets are sent over separate 463 UDP ports. Since both data and control frames can exceed the PMTU, 464 the payload of a CAPWAP data or control message can be fragmented. 465 The fragmentation behavior is defined in Section 3. 467 The CAPWAP Protocol begins with a discovery phase. The WTPs send a 468 Discovery Request message, causing any Access Controller (AC) 469 receiving the message to respond with a Discovery Response message. 470 From the Discovery Response messages received, a WTP will select an 471 AC with which to establish a secure DTLS session. CAPWAP protocol 472 messages will be fragmented to the maximum length discovered to be 473 supported by the network. 475 Once the WTP and the AC have completed DTLS session establishment, a 476 configuration exchange occurs in which both devices to agree on 477 version information. During this exchange the WTP may receive 478 provisioning settings. For the IEEE 802.11 binding, this information 479 typically includes a name (IEEE 802.11 Service Set Identifier, SSID) 480 security parameters, the data rates to be advertised and the 481 associated radio channel(s) to be used. The WTP is then enabled for 482 operation. 484 When the WTP and AC have completed the version and provision exchange 485 and the WTP is enabled, the CAPWAP protocol is used to encapsulate 486 the wireless data frames sent between the WTP and AC. The CAPWAP 487 protocol will fragment the L2 frames if the size of the encapsulated 488 wireless user data (Data) or protocol control (Management) frames 489 causes the resulting CAPWAP protocol packet to exceed the MTU 490 supported between the WTP and AC. Fragmented CAPWAP packets are 491 reassembled to reconstitute the original encapsulated payload. 493 The CAPWAP protocol provides for the delivery of commands from the AC 494 to the WTP for the management of mobile units (STAs) that are 495 communicating with the WTP. This may include the creation of local 496 data structures in the WTP for the mobile units and the collection of 497 statistical information about the communication between the WTP and 498 the mobile units. The CAPWAP protocol provides a mechanism for the 499 AC to obtain statistical information collected by the WTP. 501 The CAPWAP protocol provides for a keep alive feature that preserves 502 the communication channel between the WTP and AC. If the AC fails to 503 appear alive, the WTP will try to discover a new AC. 505 2.1. Wireless Binding Definition 507 The CAPWAP protocol is independent of a specific WTP radio 508 technology. Elements of the CAPWAP protocol are designed to 509 accommodate the specific needs of each wireless technology in a 510 standard way. Implementation of the CAPWAP protocol for a particular 511 wireless technology must follow the binding requirements defined for 512 that technology. This specification includes a binding for the IEEE 513 802.11 standard(see Section 11). 515 When defining a binding for other wireless technologies, the authors 516 MUST include any necessary definitions for technology-specific 517 messages and all technology-specific message elements for those 518 messages. At a minimum, a binding MUST provide the definition for a 519 binding-specific Statistics message element, carried in the WTP Event 520 Request message, and a Mobile message element, carried in the Mobile 521 Configure Request. If technology specific message elements are 522 required for any of the existing CAPWAP messages defined in this 523 specification, they MUST also be defined in the technology binding 524 document. 526 The naming of binding-specific message elements MUST begin with the 527 name of the technology type, e.g., the binding for IEEE 802.11, 528 provided in this specification, begins with "IEEE 802.11"." 530 2.2. CAPWAP Session Establishment Overview 532 This section describes the session establishment process message 533 exchanges in the ideal case. The annotated ladder diagram shows the 534 AC on the right, the WTP on the left, and assumes the use of 535 certificates for DTLS authentication. The CAPWAP Protocol State 536 Machine is described in detail in Section 2.3. 538 ============ ============ 539 WTP AC 540 ============ ============ 541 [----------- begin optional discovery ------------] 543 Discover Request ------> 544 <------ Discover Response 546 [----------- end optional discovery ------------] 548 (--- begin dtls handshake ---) 550 ClientHello ------> 551 <------ HelloVerifyRequest 552 (with cookie) 554 ClientHello ------> 555 (with cookie) 556 <------ ServerHello 557 <------ Certificate 558 <------ ServerHelloDone 560 (WTP callout for AC authorization) 562 Certificate* 563 ClientKeyExchange 564 CertificateVerify* 565 [ChangeCipherSpec] 566 Finished ------> 568 (AC callout for WTP 569 authorization) 571 [ChangeCipherSpec] 572 <------ Finished 574 (--- DTLS session is established now ---) 576 Join Request ------> 577 <------ Join Response 579 ( ---assume image is up to date ---) 581 Configure Request -------> 582 <------ Configure Response 584 (--- enter RUN state ---) 586 : 587 : 589 Echo Request -------> 590 <------ Echo Response 591 : 592 : 594 EventRequest -------> 595 <------ Event Response 597 : 598 : 600 At the end of the illustrated CAPWAP message exchange, the AC and WTP 601 are securely exchanging CAPWAP control messages. This is an 602 idealized illustration, provided to clarify protocol operation. 603 Section 2.3 provides a detailed description of the corresponding 604 state machine. 606 2.3. CAPWAP State Machine Definition 608 The following state diagram represents the lifecycle of a WTP-AC 609 session. Use of DTLS by the CAPWAP protocol results in the 610 juxtaposition of two nominally separate yet tightly bound state 611 machines. The DTLS and CAPWAP state machines are coupled through an 612 API consisting of commands (from CAPWAP to DTLS) and notifications 613 (from (DTLS to CAPWAP). Certain transitions in the DTLS state 614 machine are triggered by commands from the CAPWAP state machine, 615 while certain transitions in the CAPWAP state machine are triggered 616 by notifications from the DTLS state machine. 618 This section defines the CAPWAP Integrated State Machine. In the 619 figure below, single lines (denoted with '-' and '|') are used to 620 illustrate state transitions. Double lines (denoted with '=' and 621 '"') are used to illustrate commands and notifications between DTLS 622 and CAPWAP. A line composed of '~' characters is used to delineate 623 the boundary between nominal CAPWAP and DTLS state machine 624 components. 626 /-------------<----------------+--------------------\ 627 v |d | 628 +------+ b+-----------+ +----------+ | 629 | Idle |-->| Discovery |--->| Sulking | | 630 +------+ a +-----------+ c +----------+ | 631 ^ |aa ^ |e /----------------------\ | 632 | V f| v k| | | 633 h +--------------+ +------------+ i +------------+j | | 634 /--| Join |->| Configure |-->| Image Data | | | 635 | +--------------+ g+------------+ +------------+ | | 636 | "c1, ^ ^ ^ m| ^ |l | | 637 | "c4 " " " | /-------/ | /----/ | 638 | " " " " V |s v V | 639 | " " " " +------------+ o+------------+ | 640 | " " " " | Run |->| Reset |-------/ 641 | " " " " n+------------+ +------------+ p 642 | " " " " "c2 ^ ^ c3" ^ 643 \---"-----"--"---"--------"----"-------/ " " CAPWAP 644 ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~ 645 " " " " " " " " DTLS 646 v " "n2 \"""""\ " " v "n6,n7 647 /-->+------+ " W+------+ " " " +------------+ 648 | /-| Idle | " C| Auth |--"~-"----"----->| Shutdown |-------\P 649 | | +------+ " +------+V " " " /--->| |<----\ | 650 | |X Z| " ^ U| " " n4 " | +------------+ | | 651 | | | " | | " " n5," | ^ | | 652 | | v "n1 |Y | n3" v n8" |R |Q | | 653 | | +--------+ | +------------+ S+------------+ | | 654 | | | Init | \->| Run |<--| Rekey | | | 655 | | +--------+ | |-->| | | | 656 | | +------------+T +------------+ | | 657 | \---------------------------------------------------------/ | 658 \-------------------------------------------------------------/ 660 Figure 3: CAPWAP Integrated State Machine 662 The CAPWAP protocol state machine, depicted above, is used by both 663 the AC and the WTP. In cases where states are not shared (i.e. not 664 implemented in one or the other of the AC or WTP), this is explicitly 665 called out in the transition descriptions below. For every state 666 defined, only certain messages are permitted to be sent and received. 667 The CAPWAP control messages definitions specify the state(s) in which 668 each message is valid. 670 2.3.1. CAPWAP Protocol State Transitions 672 The following text discusses the various state transitions, and the 673 events that cause them. This section does not discuss interactions 674 between DTLS- and CAPWAP-specific states. Those interactions, as 675 well as DTLS-specific states and transitions, are discussed in 676 subsequent sections. 678 Idle to Discovery (a): This transition occurs once device 679 initialization is complete. 681 WTP: The WTP enters the Discovery state prior to transmitting the 682 first Discovery Request message (see Section 5.1). Upon 683 entering this state, the WTP sets the DiscoveryInterval timer 684 (see Section 4.5). The WTP resets the DiscoveryCount counter 685 to zero (0) (see Section 4.6). The WTP also clears all 686 information from ACs it may have received during a previous 687 Discovery phase. 689 AC: The AC does not maintain state information for the WTP upon 690 reception of the Discovery Request message, but it SHOULD 691 respond with a Discovery Response message (see Section 5.2). 692 This transition is a no-op for the AC. 694 Idle to Join (aa): This transition occurs when the WTP presents a 695 DTLS ClientHello message containing a valid cookie to the AC. 697 WTP: This transition is a no-op for the WTP. 699 AC: The AC does not maintain state information until the WTP 700 presents a DTLS ClientHello message containing a valid cookie. 701 Upon receipt of a DTLS ClientHello message containing a valid 702 cookie, the AC creates session state and transitions to the 703 Join state. 705 Discovery to Discovery (b): In the Discovery state, the WTP 706 determines which AC to connect to. 708 WTP: This transition occurs when the DiscoveryInterval timer 709 expires. If the WTP is configured with a list of ACs, it 710 transmits a Discovery Request message to every AC from which it 711 has not received a Discovery Response message. For every 712 transition to this event, the WTP increments the DiscoveryCount 713 counter. See Section 5.1 for more information on how the WTP 714 knows the ACs to which it should transmit the Discovery Request 715 messages. The WTP restarts the DiscoveryInterval timer 716 whenever it transmits Discovery Request messages. 718 AC: This is a no-op. 720 Discovery to Sulking (c): This transition occurs on a WTP when 721 Discovery or connectivity to the AC fails. 723 WTP: The WTP enters this state when the DiscoveryInterval timer 724 expires and the DiscoveryCount variable is equal to the 725 MaxDiscoveries variable (see Section 4.6). Upon entering this 726 state, the WTP shall start the SilentInterval timer. While in 727 the Sulking state, all received CAPWAP protocol messages 728 received shall be ignored. 730 AC: This is a no-op. 732 Sulking to Idle (d): This transition occurs on a WTP when it must 733 restart the discovery phase. 735 WTP: The WTP enters this state when the SilentInterval timer (see 736 Section 4.5) expires. 738 AC: This is a no-op. 740 Discovery to Join (e): This transition occurs when the WTP sends a 741 ClientHello message to the AC, confirming that it wishes to be 742 provided services by the AC. 744 WTP: The WTP selects the best AC based either on information it 745 gathered during the Discovery Phase or on its configuration. 746 It then sends a JoinRequest message to its preferred AC, sets 747 the WaitJoin timer, and awaits the Join Response Message. 749 AC: This is a no-op for the AC. 751 Join to Discovery (f): This state transition is used to return the 752 WTP to the Discovery state when an unresponsive AC is encountered. 754 WTP: The WTP re-enters the Discovery state when the WaitJoin timer 755 expires. 757 AC: This is a no-op. 759 Join to Configure (g): This state transition is used by the WTP and 760 the AC to exchange configuration information. 762 WTP: The WTP enters the Configure state when it successfully 763 completes the Join operation. If it determines that its 764 version number and the version number advertised by the AC are 765 the same, the WTP transmits the Configuration Status message 766 (see Section 8.2) to the AC with a snapshot of its current 767 configuration. The WTP also starts the ResponseTimeout timer 768 (see ). (Section 4.5) If the version numbers are not the same, 769 the WTP will immediately transition to Image Data state (see 770 transition (i)). 772 AC: This state transition occurs immediately after the AC 773 transmits the Join Response message to the WTP. If the AC 774 receives the Configuration Status message from the WTP, the AC 775 must transmit a Configuration Status Response message(see 776 Section 8.3) to the WTP, and may include specific message 777 elements to override the WTP's configuration. If the AC 778 instead receives the Image Data Request from the WTP, it 779 immediately transitions to the Image Data state (see transition 780 (i)). 782 Join to Reset (h): This state transition occurs when the WaitJoin 783 Timer expires. 785 WTP: The state transition occurs when the WTP WaitJoin timer 786 expires, or upon DTLS negotiation failure. 788 AC: Thise state transition occurs when the AC WaitJoin timer 789 expires, or or upon DTLS negotiation failure. 791 Configure to Image Data (i): This state transition is used by the WTP 792 and the AC to download executable firmware. 794 WTP: The WTP enters the Image Data state when it successfully 795 comletes DTLS session establishment, and determines that its 796 version number and the version number advertised by the AC are 797 different. The WTP transmits the Image Data Request (see 798 Section 9.1) message requesting that a download of the AC's 799 latest firmware be initiated. 801 AC: This state transition occurs when the AC receives the Image 802 Data Request message from the WTP. The AC must transmit an 803 Image Data Response message (see Section 9.2) to the WTP, which 804 includes a portion of the firmware. 806 Image Data to Image Data (j): The Image Data state is used by WTP and 807 the AC during the firmware download phase. 809 WTP: The WTP enters the Image Data state when it receives an Image 810 Data Response message indicating that the AC has more data to 811 send. 813 AC: This state transition occurs when the AC receives the Image 814 Data Request message from the WTP while already in the Image 815 Data state, and it detects that the firmware download has not 816 completed. 818 Configure to Reset (k): This state transition is used to reset the 819 connection to the AC prior to restarting the WTP with a new 820 configuration. 822 WTP: The WTP enters the Reset state when it determines that a 823 reset of the WTP is required, due to the characteristics of a 824 new configuration. 826 AC: The AC transitions to the Reset state when it receives the 827 DTLSPeerDisconnect (n7) notification. 829 Image Data to Reset (l): This state transition is used to reset the 830 DTLS connection prior to restarting the WTP after an image 831 download. 833 WTP: When an image download completes, the WTP enters the Reset 834 state, and terminates the DTLS connection, sending a 835 DTLSShutdown command to the DTLS state machine. 837 AC: The AC enters the Reset state upon receipt of a DTLSIdle (n6) 838 notification. 840 Configure to Run (m): This state transition occurs when the WTP and 841 AC enter their normal state of operation. 843 WTP: The WTP enters this state when it receives a successful 844 Configuration Status Response message from the AC. The WTP 845 initializes the HeartBeat timer (see Section 4.5), and 846 transmits the Change State Event Request message (see 847 Section 8.6). 849 AC: This state transition occurs when the AC receives the Change 850 State Event Request message (see Section 8.6) from the WTP. 851 The AC responds with a Change State Event Response (see 852 Section 8.7) message. The AC must start the 853 NeighborDeadInterval timer (see Section 4.5). 855 Run to Run (n): This is the normal state of operation. 857 WTP: This is the WTP's normal state of operation. There are many 858 events that result this state transition: 860 Configuration Update: The WTP receives a Configuration Update 861 Request message(see Section 8.4). The WTP MUST respond with 862 a Configuration Update Response message (see Section 8.5). 864 Change State Event: The WTP receives a Change State Event 865 Response message, or determines that it must initiate a 866 Change State Event Request message, as a result of a failure 867 or change in the state of a radio. 869 Echo Request: The WTP receives an Echo Request message (see 870 Section 7.1), to which it MUST respond with an Echo Response 871 message(see Section 7.2). 873 Clear Config Request: The WTP receives a Clear Configuration 874 Request message (see Section 8.8). The WTP MUST reset its 875 configuration back to manufacturer defaults. 877 WTP Event: The WTP generates a WTP Event Request message to 878 send information to the AC (see Section 9.5). The WTP 879 receives a WTP Event Response message from the AC (see 880 Section 9.6). 882 Data Transfer: The WTP generates a Data Transfer Request 883 message to the AC (see Section 9.7). The WTP receives a 884 Data Transfer Response message from the AC (see 885 Section 9.8). 887 WLAN Configuration Request: The WTP receives a WLAN 888 Configuration Request message (see Section 11.6.1), to which 889 it MUST respond with a WLAN Configuration Response message 890 (see Section 11.6.2). 892 Mobile Configuration Request: The WTP receives a Mobile Config 893 Request message (see Section 10.1), to which it MUST respond 894 with a Mobile Config Response message (see Section 10.2). 896 AC: This is the AC's normal state of operation: 898 Configuration Update: The AC sends a Configuration Update 899 Request message (see Section 8.4) to the WTP to update its 900 configuration. The AC receives a Configuration Update 901 Response message (see Section 8.5) from the WTP. 903 Change State Event: The AC receives a Change State Event 904 Request message (see Section 8.6), to which it MUST respond 905 with the Change State Event Response message (see 906 Section 8.7). 908 Echo: The AC sends an Echo Request message Section 7.1 or 909 receives the corresponding Echo Response message, see 910 Section 7.2 from the WTP. 912 Clear Config Response: The AC receives a Clear Configuration 913 Response message (see Section 8.9). 915 WLAN Config: The AC sends a WLAN Configuration Request message 916 (see Section 11.6.1) or receives the corresponding WLAN 917 Configuration Response message (see Section 11.6.2) from the 918 WTP. 920 Mobile Config: The AC sends a Mobile Configuration Request 921 message (see Section 10.1) or receives the corresponding 922 Mobile Configuration Response message (see Section 10.2) 923 from the WTP. 925 Data Transfer: The AC receives a Data Transfer Request message 926 from the AC (see Section 9.7) and MUST generate a 927 corresponding Data Transfer Response message (see 928 Section 9.8). 930 WTP Event: The AC receives a WTP Event Request message from the 931 AC (see Section 9.5) and MUST generate a corresponding WTP 932 Event Response message (see Section 9.6). 934 Run to Reset(o): This state transition is used when the AC or WTP 935 wish to tear down the connection. This may occur as part of 936 normal operation, or due to error conditions. 938 WTP: The WTP enters the Reset state when it initiates orderly 939 termination of the DTLS connection, or when the underlying 940 reliable transport is unable to transmit a message within the 941 RetransmitInterval timer, see Section 4.5 The WTP also enters 942 the Reset state upon receiving a DTLS session termination 943 message (DTLS alert) from the AC. The WTP sends a DTLSReset 944 command to the DTLS state machine. 946 AC: The AC enters the Idle state when it initiates orderly 947 termination of the DTLS connection, or when the underlying 948 reliable transport is unable to transmit a message within the 949 RetransmitInterval timer (see Section 4.5), and the maximum 950 number of RetransmitCount counter has reached the MaxRetransmit 951 variable (see Section 4.6). The AC also enters the Reset state 952 upon receiving a DTLS session termination message from the WTP. 954 Reset to Idle (p): This state transition occurs when the state 955 machine is restarted following a system restart, an unrecoverable 956 error on the AC-WTP connection, or orderly session teardown. 958 WTP: The WTP clears any state associated with any AC and enters 959 the Idle state. 961 AC: The AC clears any state associated with the WTP and enters the 962 idle state. 964 Run to Image Data (s): This state transition occurs when the AC 965 transmits an Image Data Request to the WTP, with the Initiate 966 Download message element. The means by which the AC decides to 967 download firmware is undefined, but could occur through an 968 administrative action. 970 WTP: The WTP enters this state when it receives an an Image Data 971 Request to the WTP, with the Initiate Download message element. 972 The WTP responds by transmitting an Image Data Request with the 973 Image Filename message element included.. 975 AC: This state transition occurs when the AC decides that an WTP 976 is to update its firmware by sending an Image Data Request to 977 the WTP, with the Initiate Download message element. 979 2.3.2. CAPWAP to DTLS Commands 981 Four commands are defined for the CAPWAP to DTLS API. These 982 "commands" are conceptual, and may be implemented as one or more 983 function calls. This API definition is provided to clarify 984 interactions between the DTLS and CAPWAP components of the integrated 985 CAPWAP state machine. 987 Below is a list of the minimal command API: 989 o c1: DTLSStart is sent to the DTLS module to cause a DTLS session 990 to be established. 992 o c2: DTLSRehandshake is sent to the DTLS module to cause initiation 993 of a rehandshake (DTLS rekey). 995 o c3: DTLSShutdown is sent to the DTLS module to cause session 996 teardown. 998 o c4: DTLSAbort is sent to the DTLS module to cause session teardown 999 when the WaitJoin timer expires. 1001 2.3.3. DTLS to CAPWAP Notifications 1003 Eight notifications are defined for the DTLS to CAPWAP API. These 1004 "notifications" are conceptual, and may be implemented in numerous 1005 ways (e.g. as function return values). This API definition is 1006 provided to clarify interactions between the DTLS and CAPWAP 1007 components of the integrated CAPWAP state machine. 1009 Below is a list of the API notifications: 1011 o n1: DTLSInitFailure is sent to the CAPWAP module to indicate an 1012 initialization failure, which may be due to out of memory or other 1013 internal error condition. 1015 o n2: DTLSAuthenticateFail or DTLSAuthorizeFail is sent to the 1016 CAPWAP module to indicate peer authentication or authorization 1017 failures, respectively. 1019 o n3: DTLSEstablished is sent to the CAPWAP module to indicate that 1020 that a secure channel now exists. 1022 o n4: DTLSEncapFailure may be sent to CAPWAP to indicate an 1023 encapsulation failure. DTLSDecapFailure may be sent to CAPWAP to 1024 indicate an encryption/authentication failure 1026 o n5: DTLSRehandshake is sent to the CAPWAP module to indicate DTLS 1027 rehandshake initiation by peer. 1029 o n6: DTLSIdle is sent to the CAPWAP module to indicate that session 1030 abort (as requested by CAPWAP) is complete; this occurs when the 1031 WaitJoin timer expires, or when CAPWAP is executing an orderly 1032 session shutdown. 1034 o n7: DTLSPeerDisconnect is sent to the CAPWAP module to indicate 1035 DTLS session teardown by peer. Note that the n7 notification, can 1036 be received while in the Join, Configure, Image Data, Run and 1037 Reset states, and always causes a transition to the Reset state. 1039 o n8: DTLSReassemblyFailure may be sent to the CAPWAP module to 1040 indicate DTLS fragment reassembly failure. 1042 2.3.4. DTLS State Transitions 1044 This section describes the transitions in the DTLS-specific portion 1045 of the state machine. 1047 Idle to Init (Z): This transition indicates the begining of a DTLS 1048 session. 1050 WTP: The state ransition is triggered by receipt of the DTLSStart 1051 command from the CAPWAP state machine, and causes the WTP to 1052 send a DTLS ClientHello to the AC. 1054 AC: The state transition is triggered by receipt of the DTLSStart 1055 command from the CAPWAP state machine. The AC starts the 1056 WaitJoin timer and awaits reception of a DTLS ClientHello 1057 message 1059 Init to Authenticate/Authorize (Y) This transition indicates that the 1060 DTLS handshake is in progress. 1062 WTP: The WTP executes this state transition upon receipt of a 1063 valid ServerHello. 1065 AC: The AC executes this transition upon receipt of a certificate 1066 payload (if configured for public key authentication) or upon 1067 receipt of the ClientKeyExchange payload if configured for 1068 preshared keys. 1070 Init to Idle(X) This state transition occurs upon timeout of the 1071 WaitJoin Timer. 1073 WTP: Upon receiving a DTLSAbort command from the CAPWAP state 1074 machine, the WTP DTLS state machine transitions to Idle state. 1076 AC: Upon receiving a DTLSAbort command from the CAPWAP state 1077 machine, the AC DTLS state machine transitions to Idle state. 1079 Authenticate/Authorize to Authenticate/Authorize (W) This state 1080 transition is a Loopback state, representing execution of the TLS 1081 handshake protocol, including authorization callbacks to the 1082 CAPWAP architecture. 1084 WTP: Upon receiving AC credential, attempt to execute associated 1085 validation, authentication, and authorization callbacks. Note 1086 that credentials may span protocol messages, in which case the 1087 WTP will remain in this state pending receipt of all credential 1088 payloads. 1090 AC: Upon receipt of the WTP credential, attempt to execute 1091 associated validation, authentication, and authorization 1092 callbacks. Note that credentials may span protocol messages, 1093 in which case the AC will remain in this state pending receipt 1094 of all credential payloads. 1096 Authenticate/Authorize to Shutdown (V) This state transition 1097 indicates a failure of the DTLS handshake. 1099 WTP: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the 1100 CAPWAP state machine, depending on the exact cause of the 1101 error. May send a DTLS notification to the AC to indicate 1102 failure. 1104 AC: Send a DTLSAuthenticateFail or DTLSAuthorizeFail to the CAPWAP 1105 state machine, depending on the exact cause of the error. May 1106 send a DTLS Notification to the AC to indicate failure. 1108 Authenticate/Authorize to Run (U) This state transition occurs upon 1109 successful completion of the DTLS handshake. 1111 WTP: Send a DTLSEstablished notification to the CAPWAP state 1112 machine. 1114 AC: Send a DTLSEstablished notification to the CAPWAP state 1115 machine. 1117 Run to Rekey (T) This state transition occurs when a DTLS rehandshake 1118 is in progress; this is initiated when either (a) the DTLS state 1119 machine receives the DTLSRehandshake command from CAPWAP, or (b) a 1120 DTLS rehandshake message is received from the peer.. 1122 WTP: If CAPWAP issued a DTLSRehandshake command, initiate 1123 rehandshake with the peer; note that control traffic may 1124 continue to flow using existing secure association. If the 1125 rehandshake is initiated by the peer, send a DTLSRehandshake 1126 notification to CAPWAP. 1128 AC: If CAPWAP issued a DTLSRehandshake command, initiate 1129 rehandshake with the peer; note that control traffic may 1130 continue to flow using existing secure association. If the 1131 rehandshake is initiated by the peer, send a DTLSRehandshake 1132 notification to CAPWAP. 1134 Run to Shutdown (S) This state transition indicates a shutdown of the 1135 DTLS channel. 1137 WTP: This state transition occurs when the CAPWAP state machine 1138 sends a DTLSShutdown command, or when the the AC terminates the 1139 DTLS session. 1141 AC: This state transition occurs when CAPWAP state machine sends a 1142 DTLSShutdown command, or when the WTP terminates the DTLS 1143 session. 1145 Rekey to Run (R) This state transition indicates the successful 1146 completion of a DTLS rehandshake. 1148 WTP: This state transition occurs when the WTP receives the DTLS 1149 Finished message from the AC, completing the DTLS re-handshake. 1151 AC: This state transition occurs when the AC sends a DTLS Finished 1152 message to the WTP, completing the DTLS re-handshake. 1154 Rekey to Shutdown (Q) This state transition indicates the failure of 1155 the DTLS rekey operation. 1157 WTP: This state transition occurs when there is a failure in the 1158 rehandshake negotiation with the AC. 1160 AC: This state transition occurs when there is a failure in the 1161 rehandshake negotiation with the WTP. 1163 Shutdown to Idle (P) This state transition occurs upon transmission 1164 of a DTLS Session termination message, or upon receipt of a DTLS 1165 session termination message. 1167 WTP: This state transition occurs after the WTP transmits the DTLS 1168 session termination message. If the WTP receives a DTLS 1169 session termination message, it sends the DTLSPeerDisconnect 1170 notification to CAPWAP and moves to the Idle state. 1172 AC: This state transition occurs after the AC transmits the DTLS 1173 session termination message. If the AC receives a DTLS session 1174 termination message, it sends the DTLSPeerDisconnect 1175 notification to CAPWAP and moves to the Idle state. 1177 2.4. Use of DTLS in the CAPWAP Protocol 1179 DTLS is used as a tightly-integrated, secure wrapper for the CAPWAP 1180 protocol. In this document DTLS and CAPWAP are discussed as 1181 nominally distinct entitites; however they are very closely coupled, 1182 and may even be implemented inseparably. Since there are DTLS 1183 library implementations currently available, and since security 1184 protocols (e.g. IPsec, TLS) are often implemented in widely 1185 available acceleration hardware, it is both convenient and forward- 1186 looking to maintain a modular distinction in this document. 1188 This section describes a detailed walk-through of the interactions 1189 between the DTLS module and the CAPWAP module, via 'commands' (CAPWAP 1190 to DTLS) and 'notifications' (DTLS to CAPWAP) as they would be 1191 encountered during the normal course of operation. 1193 2.4.1. DTLS Handshake Processing 1195 Details of the DTLS handshake process are specified in [DTLS]. This 1196 section describes the interactions between the DTLS session 1197 establishment process and the CAPWAP protocol. In the normal case, 1198 the DTLS handshake will proceed as follows (NOTE: this example uses 1199 certificates, but preshared keys are also supported): 1201 ============ ============ 1202 WTP AC 1203 ============ ============ 1205 ClientHello ------> 1206 <------ HelloVerifyRequest 1207 (with cookie) 1209 ClientHello ------> 1210 (with cookie) 1211 <------ ServerHello 1212 <------ Certificate 1213 <------ ServerHelloDone 1215 (WTP callout for AC authorization) 1217 Certificate* 1218 ClientKeyExchange 1219 CertificateVerify* 1220 [ChangeCipherSpec] 1221 Finished ------> 1223 (AC callout for WTP 1224 authorization) 1226 [ChangeCipherSpec] 1227 <------ Finished 1229 DTLS, as specified, provides its own retransmit timers with an 1230 exponential back-off. However, it will never terminate the handshake 1231 due to non-responsiveness; rather, it will continue to increase its 1232 back-off timer period. Hence, timing out incomplete DTLS handshakes 1233 is entirely the responsiblity of the CAPWAP protocol. 1235 2.4.1.1. Join Operations 1237 The WTP, either through the Discovery process, or through pre- 1238 configuration, determines the AC to connect to. The WTP uses DTLS to 1239 establish a secure connection to the selected AC. Prior to 1240 initiation of the DTLS handshake, the WTP sets the WaitJoin timer. 1241 Upon receipt of a ClientHello message containing a valid cookie, the 1242 AC sets the WaitJoin timer. If the Join operation has not completed 1243 prior to timer expiration, the Join process is aborted, the WTP 1244 transitions back to Discovery state, and the AC transitions back to 1245 Idle state. Upon successful completion of the Join process the 1246 WaitJoin timer is deactivated. 1248 2.4.2. DTLS Error Handling 1250 If the AC does not respond to any DTLS messages sent by the WTP, the 1251 DTLS specification calls for the WTP to retransmit these messages. 1252 If the WaitJoin timer expires, CAPWAP will issue the DTLSAbort 1253 command, causing DTLS to terminate the handshake and remove any 1254 allocated session context. Note that DTLS MAY send a single TLS 1255 Alert message to the AC to indicate session termination. 1257 If the WTP does not respond to any DTLS messages sent by the AC, the 1258 CAPWAP protocol allows for three possiblities, listed below. Note 1259 that DTLS MAY send a single TLS Alert message to the AC to indicate 1260 session termination. 1262 o The message was lost in transit; in this case, the WTP will re- 1263 transmit its last outstanding message, since it did not receive 1264 the reply. 1266 o The WTP sent a DTLS Alert, which was lost in transit; in this 1267 case, the AC's WaitJoin timer will expire, and the session will be 1268 terminated. 1270 o Communication with the WTP has completely failed; in this case, 1271 the AC's WaitJoin timer will expire, and the session will be 1272 terminated. 1274 The DTLS specification provides for retransmission of unacknowledged 1275 requests. If retransmissions remain unacknowledged, the WaitJoin 1276 timer will eventually expire, at which time the CAPWAP module will 1277 terminate the session. 1279 If a cookie fails to validate, this could represent a WTP error, or 1280 it could represent a DoS attack. Hence, AC resource utilization 1281 SHOULD be minimized. The AC MAY log a message indicating the 1282 failure, but SHOULD NOT attempt to reply to the WTP. 1284 Since DTLS handshake messages are potentially larger than the maximum 1285 record size, DTLS supports fragmenting of handshake messages across 1286 multiple records. There are several potential causes of re-assembly 1287 errors, including overlapping and/or lost fragments. The DTLS module 1288 MUST send a DTLSReassemblyFailure notification to CAPWAP. Whether 1289 precise information is given along with notification is an 1290 implementation issue, and hence is beyond the scope of this document. 1291 Upon receipt of such an error, the CAPWAP protocol implementation 1292 SHOULD log an appropriate error message. Whether processing 1293 continues or the DTLS session is terminated is implementation 1294 dependent. 1296 DTLS decapsulation errors consist of three types: decryption errors, 1297 and authentication errors, and malformed DTLS record headers. Since 1298 DTLS authenticates the data prior to encapsulation, if decryption 1299 fails, it is difficult to detect this without first attempting to 1300 authenticate the packet. If authentication fails, a decryption error 1301 is also likely, but not guaranteed. Rather than attempt to derive 1302 (and require the implementation of) algorithms for detecting 1303 decryption failures, these are reported as authentication failures. 1304 The DTLS module MUST provide a DTLSDecapFailure notification to 1305 CAPWAP when such errors occur. If a malformed DTLS record header is 1306 detected, the packets SHOULD be silently discarded, and the receiver 1307 MAY log an error message. 1309 There is currently only one encapsulation error defined: MTU 1310 exceeeded. As part of DTLS session establishment, CAPWAP informs 1311 DTLS of the MTU size. This may be dynamically modified at any time 1312 when CAPWAP sends the DTLSMtuUpdate command to DTLS. DTLS returns 1313 this notification to CAPWAP whenever a transmission request will 1314 result in a packet which exceeds the MTU. 1316 2.4.3. DTLS Rehandshake Behavior 1318 DTLS rekeying (known in DTLS as "rehandshake") requires special 1319 attention, as the DTLS specification provides no rehandshake 1320 triggering mechanism. Rather, the application (in this case, CAPWAP) 1321 is expected to manage this for itself. This section addressed 1322 various aspects of rehandshake behavior. 1324 One simple way to think of a DTLS session is as a pair of 1325 unidirectional channels which are tightly bound together. A useful 1326 analogy is the twisted pair used for phone wiring, with one line per 1327 pair. Then, the rehandshake process can be thought of using the call 1328 over the existing pair to establish a call over a new pair - that is, 1329 an entirely new session is negotiated under the protection of the 1330 existing session. 1332 This sounds simple enough, yet there is operational complexity in 1333 changing over to the new session. In particular, how does each end 1334 know when it is safe to delete the "old" session, and switch over to 1335 the new one? If DTLS were not a datagram protocol, this would be 1336 simpler, but the fact that message delivery is unreliable 1337 significantly complicates things: when the AC (the "server") 1338 transmits its Finished message, it cannot be sure that the WTP 1339 received it until the WTP transmits data on the new channel. 1341 This fact constrains the way in which we transition to the new 1342 session, and delete the old one. The WTP, upon receipt of the AC's 1343 Finished message for the new session, immediately makes the new 1344 session active, and transmits no further data (e.g. echo requests, 1345 statistics, etc) on the old channel, and sends a TLS "user_cancelled" 1346 alert message on the old channel, after which the old session is 1347 immediately deleted. 1349 The AC, sets a DTLSSessionDelete timer, (see Section 4.5) and 1350 immediately makes the new session active, and transmits no further 1351 data (e.g. echo requests, statistics, etc) on the old channel. 1353 If a TLS "user_cancelled" alert message is received on the old 1354 channel, the session delete timer is deactivated, and the session is 1355 deleted. 1357 if the dtls-session-delete timer expires, a TLS "user_cancelled" 1358 alert message is transmitted on the old channel, and the session is 1359 deleted. 1361 Note that there is a slight possibility that some packets may be in 1362 flight when the session is deleted. However, since CAPWAP provides 1363 reliable delivery, these packets will be retransmitted over the new 1364 channel. 1366 2.4.3.1. Peer Initiated Rehandshake Triggers 1368 Since key lifetimes are not negotiable in DTLS, it is possible that a 1369 rehandshake from a peer may occur at any time, and implementations 1370 must be prepared for this eventuality. Presumably, communicating 1371 devices will be within the same domain of control. This being the 1372 case, overly-aggressive rekeying may be detected by simply monitoring 1373 logs, assuming such activity is indeed logged. Hence, 1374 implementations MUST log rekey attempts as they occur, reporting the 1375 time and identifying information for the peer. 1377 CAPWAP implementations MUST provide an administrative interface which 1378 permits specification of key lifetimes in seconds. Also, 1379 implementations which wait until this interval has expired to begin 1380 the rehandshake process are liable to encounter temporary service 1381 lapses on heavily loaded networks, so implementations SHOULD begin 1382 the rehandshake before the actual lifetime has elapsed. 1384 Given the relatively low bandwidth we might reasonably expect over a 1385 CAPWAP control channel and the strength of modern cryptographic 1386 algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume 1387 that lifetimes will typically be more than 8 hours. Given this 1388 assumption, a good rule of thumb for deciding when to rekey is this: 1389 deduct a random number of seconds from the lifetime (say, between 1% 1390 and 5% of the lifetime), and begin the rehandshake process at that 1391 point. Using a random value helps avert collisions, when both sides 1392 initiate a rehandshake at the same time (discussed further below). 1394 2.4.3.2. Time Based Rehandshake Triggers 1396 CAPWAP implementations MUST provide an administrative interface which 1397 permits specification of key lifetimes in seconds. Also, 1398 implementations which wait until this interval has expired to begin 1399 the rehandshake process are liable to encounter temporary service 1400 lapses on heavily loaded networks, so implementations SHOULD begin 1401 the rehandshake before the actual lifetime has elapsed. 1403 Given the relatively low bandwidth we might reasonably expect over a 1404 CAPWAP control channel and the strength of modern cryptographic 1405 algorithms (e.g. AES-128, 3DES, etc), it is reasonable to assume 1406 that key lifetimes will typically be more than 8 hours. Given this 1407 assumption, a good rule of thumb for deciding when to rekey is this: 1408 deduct a random number of seconds from the lifetime (say, between 1% 1409 and 5% of the lifetime), and begin the rehandshake process at that 1410 point. Using a random value helps avert collisions, when both sides 1411 initiate a rehandshake at the same time. 1413 2.4.3.3. Volume Based Rehandshake Triggers 1415 CAPWAP implementations MUST provide an administrative interface which 1416 permits specification of key lifetimes in packet count. Like time- 1417 based, lifetimes, implementations which wait until this interval has 1418 expired to begin the rehandshake process may encounter temporary 1419 service lapses on heavily loaded networks, so implementations SHOULD 1420 begin the rehandshake before the actual lifetime has elapsed. 1422 Volume-based lifetime estimation for purposes of rehandshake 1423 initiation is considerably more complex than time-based lifetime. In 1424 addition to avoiding collisions, the maximum burst rate must be 1425 known, and an extimate made, assuming rehandshake packets are lost, 1426 etc. Hence, we do not specify a one-size-fits-all approach here, and 1427 the specific algorithm used is implementation dependent. 1429 2.4.3.4. Rehandshake Collisions 1431 A collision occurs when both sides initiate a rehandshake 1432 simultaneously. No matter how much care is taken, rehandshake 1433 collisions are a distinct possibility. Hence, a contention 1434 resolution strategy is specified. 1436 A rehandshake collision is detected when a system receives a 1437 rehandshake initiation when it has one outstanding with the same 1438 peer. 1440 When this occurs, each side will compare its own address with that of 1441 its peer (in network byte order). 1443 The one with the lower of the two addresses will ignore the peer's 1444 rehandshake message, and continue with its own rehandshake process. 1446 The one with the higher message will immediately abort its current 1447 rehandshake, and set the DTLSRehandshake timer (see Section 4.5); if 1448 the peer with the lower address does not complete the rehandshake 1449 before the timer expires, the peer with the higher address will re- 1450 initiate. 1452 2.4.4. DTLS EndPoint Authentication 1454 DTLS supports endpoint authentication with certificates or preshared 1455 keys. The TLS algorithm suites for each endpoint authentication 1456 method are described below. 1458 2.4.4.1. Authenticating with Certificates 1460 Note that only block ciphers are currently recommended for use with 1461 DTLS. To understand the reasoning behind this, see [26]. However, 1462 support for AES counter mode encryption is currently progressing in 1463 the TLS working group, and once protocol identifiers are available, 1464 they will be added below. At present, the following algorithms MUST 1465 be supported when using certificates for CAPWAP authentication: 1467 o TLS_RSA_WITH_AES_128_CBC_SHA 1469 o TLS_RSA_WITH_3DES_EDE_CBC_SHA 1471 The following algorithms SHOULD be supported when using certificates: 1473 o TLS_DH_RSA_WITH_AES_128_CBC_SHA 1475 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA 1476 The following algorithms MAY be supported when using certificates: 1478 o TLS_RSA_WITH_AES_256_CBC_SHA 1480 o TLS_DH_RSA_WITH_AES_256_CBC_SHA 1482 2.4.4.2. Authenticating with Preshared Keys 1484 Pre-shared keys present significant challenges from a security 1485 perspective, and for that reason, their use is strongly discouraged. 1486 However, [14] defines several different methods for authenticating 1487 with preshared keys, and we focus on the following two: 1489 o PSK key exchange algorithm - simplest method, ciphersuites use 1490 only symmetric key algorithms 1492 o DHE_PSK key exchange algorithm - use a PSK to authenticate a 1493 Diffie-Hellman exchange. These ciphersuites give some additional 1494 protection against dictionary attacks and also provide Perfect 1495 Forward Secrecy (PFS). 1497 The first approach (plain PSK) is susceptible to passive dictionary 1498 attacks; hence, while this alorithm MUST be supported, special care 1499 should be taken when choosing that method. In particular, user- 1500 readable passphrases SHOULD NOT be used, and use of short PSKs SHOULD 1501 be strongly discouraged. 1503 The following cryptographic algorithms MUST be supported when using 1504 preshared keys: 1506 o TLS_PSK_WITH_AES_128_CBC_SHA 1508 o TLS_PSK_WITH_3DES_EDE_CBC_SHA 1510 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA 1512 o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA 1514 The following algorithms MAY be supported when using preshared keys: 1516 o TLS_PSK_WITH_AES_256_CBC_SHA 1518 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA 1520 2.4.4.3. Certificate Usage 1522 When using certificates, both authentication and authorization must 1523 be considered. Section 13.3 provides recommendations on how to 1524 authenticate a certificate and bind that to a CAPWAP entity. This 1525 section deals with certificate authorization. 1527 Certificate authorization by the AC and WTP is required so that only 1528 an AC may perform the functions of an AC and that only a WTP may 1529 perform the functions of a WTP. This restriction of functions to the 1530 AC or WTP requires that the certificates used by the AC MUST be 1531 distinguishable from the certificate used by the WTP. To accomplish 1532 this differentiation, the x.509 certificates MUST include the 1533 Extended Key Usage (EKU)certificate extension [11]. 1535 The EKU field indicates one or more purposes for which a certificate 1536 may be used. It is an essential part in authorization. Its syntax 1537 is as follows: 1539 ExtKeyUsageSyntax ::= SEQUENCE SIZE (1..MAX) OF KeyPurposeId 1541 KeyPurposeId ::= OBJECT IDENTIFIER 1543 Here we define two KeyPurposeId values, one for the WTP and one for 1544 the AC. Inclusion of one of those two values indicates a certificate 1545 is authorized for use by a WTP or AC, respectively. These values are 1546 formatted as id-kp fields. 1548 id-kp OBJECT IDENTIFIER ::= 1549 { iso(1) identified-organization(3) dod(6) internet(1) 1550 security(5) mechanisms(5) pkix(7) 3 } 1552 id-kp-capwapWTP OBJECT IDENTIFIER ::= { id-kp 19 } 1554 id-kp-capwapAC OBJECT IDENTIFIER ::= { id-kp 18 } 1556 For an AC, the id-kp-capwapAC EKU MUST be present in the certificate. 1557 For a WTP, the id-kp-capwapWTP EKU MUST be present in the 1558 certificate. 1560 Part of the CAPWAP certificate validation process includes ensuring 1561 that the proper EKU is included and only allowing the CAPWAP session 1562 to be established if the extension properly represents the device. 1564 3. CAPWAP Transport 1566 The CAPWAP protocol uses UDP as a transport, and can be used with 1567 IPv4 or IPv6. This section details the specifics of how the CAPWAP 1568 protocol works in conjunction with IP. 1570 3.1. UDP Transport 1572 Communication between a WTP and an AC is established according to the 1573 standard UDP client/server model. One of the CAPWAP requirements is 1574 to allow a WTP to reside behind a firewall and/or Network Address 1575 Translation (NAT) device. Since the connection is initiated by the 1576 WTP (client) to the well-known UDP port of the AC (server), the use 1577 of UDP is a logical choice. 1579 CAPWAP protocol control packets sent between the WTP and the AC use 1580 well known UDP port [to be IANA assigned]. CAPWAP protocol data 1581 packets sent between the WTP and the AC use UDP port [to be IANA 1582 assigned]. 1584 3.2. AC Discovery 1586 A WTP and an AC will frequently not reside in the same IP subnet 1587 (broadcast domain). When this occurs, the WTP must be capable of 1588 discovering the AC, without requiring that multicast services are 1589 enabled in the network. This section describes how AC discovery is 1590 performed by WTPs. 1592 As the WTP attempts to establish communication with an AC, it sends 1593 the Discovery Request message and receives the corresponding response 1594 message from the AC(s). The WTP must send the Discovery Request 1595 message to either the limited broadcast IP address (255.255.255.255), 1596 a well known multicast address or to the unicast IP address of the 1597 AC. Upon receipt of the Discovery Request message, the AC issues a 1598 Discovery Response message to the unicast IP address of the WTP, 1599 regardless of whether the Discovery Request message was sent as a 1600 broadcast, multicast or unicast message. 1602 WTP use of a limited IP broadcast, multicast or unicast IP address is 1603 implementation dependent. 1605 When a WTP transmits a Discovery Request message to a unicast 1606 address, the WTP must first obtain the IP address of the AC. Any 1607 static configuration of an AC's IP address on the WTP non-volatile 1608 storage is implementation dependent. However, additional dynamic 1609 schemes are possible, for example: 1611 DHCP: A comma delimited ASCII encoded list of AC IP addresses is 1612 embedded in the DHCP vendor specific option 43 extension. An 1613 example of the actual format of the vendor specific payload for 1614 IPv4 is of the form "10.1.1.1, 10.1.1.2". 1616 DNS: The DNS name "CAPWAP-AC-Address" MAY be resolvable to one or 1617 more AC addresses. 1619 3.3. Fragmentation/Reassembly 1621 While fragmentation and reassembly services are provided by IP, the 1622 CAPWAP protocol also provides such services. Environments where the 1623 CAPWAP protocol is used involve firewall, Network Address Translation 1624 (NAT) and "middle box" devices, which tend to drop IP fragments in 1625 order to minimize possible Denial of Service attacks. By providing 1626 fragmentation and reassembly at the application layer, any 1627 fragmentation required due to the tunneling component of the CAPWAP 1628 protocol becomes transparent to these intermediate devices. 1629 Consequently, the CAPWAP protocol is not impacted by any network 1630 configurations. 1632 4. CAPWAP Packet Formats 1634 This section contains the CAPWAP protocol packet formats. A CAPWAP 1635 protocol packet consists of a CAPWAP Transport Layer packet header 1636 followed by a CAPWAP message. The CAPWAP message can be either of 1637 type Control or Data, where Control packets carry signaling, and Data 1638 packets carry user payloads. The CAPWAP frame formats for CAPWAP 1639 Data packets, and for DTLS encapsulated CAPWAP Data and Control 1640 packets. are as shown below: 1642 CAPWAP Data Packet : 1643 +--------------------------------+ 1644 | IP |UDP | CAPWAP | Wireless | 1645 | Hdr |Hdr | Header | Payload | 1646 +--------------------------------+ 1648 CAPWAP + Optional DTLS Data Packet Security: 1649 +------------------------------------------------+ 1650 | IP |UDP | DTLS | CAPWAP | Wireless | DTLS | 1651 | Hdr |Hdr | Hdr | Hdr | Payload | Trailer| 1652 +------------------------------------------------+ 1653 \--authenticated-----------/ 1654 \--- encrypted-----------/ 1656 CAPWAP Control Packet (DTLS Security Required): 1657 +-----------------------------------------------------------+ 1658 | IP |UDP | DTLS | CAPWAP | Control | Message | DTLS | 1659 | Hdr |Hdr | Hdr | Header | Header | Element(s) | Trailer | 1660 +-----------------------------------------------------------+ 1661 \-------authenticated-----------------/ 1662 \------------encrypted-------------------/ 1664 UDP: All CAPWAP packets are encapsulated within UDP. Section 1665 Section 3.1 defines the specific UDP usage. 1667 CAPWAP Header: All CAPWAP protocol packets use a common header that 1668 immediately follows the UDP header. This header, is defined in 1669 Section 4.1. 1671 Wireless Payload: A CAPWAP protocol packet that contains a wireless 1672 payload is known as a data frame. The CAPWAP protocol does not 1673 dictate the format of the wireless payload, which is defined by 1674 the appropriate wireless standard. Additional information is in 1675 Section 4.2. 1677 Control Header: The CAPWAP protocol includes a signalling component, 1678 known as the CAPWAP control protocol. All CAPWAP control packets 1679 include a Control Header, which is defined in Section 4.3.1. 1681 Message Elements: A CAPWAP Control packet includes one or more 1682 message elements, which are found immediately following the 1683 control header. These message elements are in a Type/Length/value 1684 style header, defined in Section 4.4. 1686 4.1. CAPWAP Transport Header 1688 All CAPWAP protocol messages are encapsulated using a common header 1689 format, regardless of the CAPWAP control or CAPWAP Data transport 1690 used to carry the messages. However, certain flags are not 1691 applicable for a given transport. Refer to the specific transport 1692 section in order to determine which flags are valid. 1694 Note that the optional fields defined in this section MUST be present 1695 in the precise order shown below. 1697 0 1 2 3 1698 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 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 |Version| RID | HLEN | WBID |T|F|L|W|M| Flags | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Fragment ID | Frag Offset |Rsvd | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | (optional) Radio MAC Address | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | (optional) Wireless Specific Information | 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | Payload .... | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 Version: A 4 bit field which contains the version of CAPWAP used in 1712 this packet. The value for this draft is 0. 1714 RID: A 5 bit field which contains the Radio ID number for this 1715 packet. WTPs with multiple radios but a single MAC Address range 1716 use this field to indicate which radio is associated with the 1717 packet. 1719 HLEN: A 5 bit field containing the length of the CAPWAP transport 1720 header in 4 byte words (Similar to IP header length). This length 1721 includes the optional headers. 1723 WBID: A 5 bit field which is the wireless binding identifier. The 1724 identifier will indicate the type of wireless packet type 1725 associated with the radio. The following values are defined: 1727 1 - IEEE 802.11 1729 T: The Type 'T' bit indicates the format of the frame being 1730 transported in the payload (see Section 11.7). When this bit is 1731 set to one (1), the payload has the native frame format indicated 1732 by the WBID field. When this bit is zero (0) the payload is an 1733 IEEE 802.3 frame. 1735 F: The Fragment 'F' bit indicates whether this packet is a fragment. 1736 When this bit is one (1), the packet is a fragment and MUST be 1737 combined with the other corresponding fragments to reassemble the 1738 complete information exchanged between the WTP and AC. 1740 L: The Last 'L' bit is valid only if the 'F' bit is set and indicates 1741 whether the packet contains the last fragment of a fragmented 1742 exchange between WTP and AC. When this bit is 1, the packet is 1743 the last fragment. When this bit is 0, the packet is not the last 1744 fragment. 1746 W: The Wireless 'W' bit is used to specify whether the optional 1747 wireless specific information field is present in the header. A 1748 value of one (1) is used to represent the fact that the optional 1749 header is present. 1751 M: The M bit is used to indicate that the Radio MAC Address optional 1752 header is present. This is used to communicate the MAC address of 1753 the receiving radio when the native wireless packet. This field 1754 MUST NOT be set to one in packets sent by the AC to the WTP. 1756 Flags: A set of reserved bits for future flags in the CAPWAP header. 1757 All implementations complying with version zero of this protocol 1758 MUST set these bits to zero. 1760 Fragment ID: An 16 bit field whose value is assigned to each group of 1761 fragments making up a complete set. The fragment ID space is 1762 managed individually for every WTP/AC pair. The value of Fragment 1763 ID is incremented with each new set of fragments. The Fragment ID 1764 wraps to zero after the maximum value has been used to identify a 1765 set of fragments. 1767 Fragment Offset: A 13 bit field that indicates where in the payload 1768 will this fragment belong during re-assembly. This field is valid 1769 when the 'F' bit is set to 1. The fragment offset is measured in 1770 units of 8 octets (64 bits). The first fragment has offset zero. 1772 Note the CAPWAP protocol does not allow for overlapping fragments. 1773 For instance, fragment 0 would include offset 0 with a payload 1774 length of 1000, while fragment 1 include offset 900 with a payload 1775 length of 600. 1777 Reserved: The 3-bit Reserved field is reserved and set to 0 in this 1778 version of the CAPWAP protocol. 1780 Radio MAC Address: This optional field contains the MAC address of 1781 the radio receiving the packet. This is useful in packets sent 1782 from the WTP to the AC, when the native wireless frame format is 1783 converted to 802.3 by the WTP. This field is only present if the 1784 'M' bit is set. Given the HLEN field assumes 4 byte alignment, 1785 this field MUST be padded with zeroes (0x00) if it is not 4 byte 1786 aligned. 1788 The field contains the basic format: 1790 0 1 2 3 1791 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Length | MAC Address 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1796 Length: The number of bytes in the MAC Address field. The length 1797 field is present since new IEEE technologies (e.g., 802.16) are 1798 now using 64 bits MAC addresses. 1800 MAC Address: The MAC Address of the receiving radio. 1802 Wireless Specific Information: This optional field contains 1803 technology specific information that may be used to carry per 1804 packet wireless information. This field is only present if the 1805 'W' bit is set. Given the HLEN field assumes 4 byte alignment, 1806 this field MUST be padded with zeroes (0x00) if it is not 4 byte 1807 aligned. 1809 The field contains the basic format: 1811 0 1 2 3 1812 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 1813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1814 | Wireless ID | Length | Data 1815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 Wireless ID: The wireless binding identifier. The following 1818 values are defined: 1820 1 - : IEEE 802.11 1822 Length: The length of the data field 1824 Data: Wireless specific information, whose details are defined in 1825 the technology specific bindings section (see Section 11.7). 1827 Payload: This field contains the header for a CAPWAP Data Message or 1828 CAPWAP Control Message, followed by the data associated with that 1829 message. 1831 4.2. CAPWAP Data Messages 1833 A CAPWAP protocol data message encapsulates a forwarded wireless 1834 frame. The CAPWAP protocol defines two different modes of 1835 encapsulation; IEEE 802.3 and native wireless. IEEE 802.3 1836 encapsulation requires that the bridging function be performed in the 1837 WTP. An IEEE 802.3 encapsulated user payload frame has the following 1838 format: 1840 +------------------------------------------------------+ 1841 | IP Header | UDP Header | CAPWAP Header | 802.3 Frame | 1842 +------------------------------------------------------+ 1844 The CAPWAP protocol also defines the native wireless encapsulation 1845 mode. The actual format of the encapsulated CAPWAP data frame is 1846 subject to the rules defined under the specific wireless technology 1847 binding. As a consequence, each wireless technology binding MUST 1848 define a section entitled "Payload encapsulation", which defines the 1849 format of the wireless payload that is encapsulated within the CAPWAP 1850 Data messages. 1852 In the event that the encapsulated frame would exceed the transport 1853 layer's MTU, the sender is responsible for the fragmentation of the 1854 frame, as specified in Section 3.3. 1856 4.3. CAPWAP Control Messages 1858 The CAPWAP Control protocol provides a control channel between the 1859 WTP and the AC. Control messages are divided into the following 1860 distinct message types: 1862 Discovery: CAPWAP Discovery messages are used to identify potential 1863 ACs, their load and capabilities. 1865 WTP Configuration: The WTP Configuration messages are used by the AC 1866 to push a specific configuration to the WTP it has a control 1867 channel with. Messages that deal with the retrieval of statistics 1868 from the WTP also fall in this category. 1870 Mobile Session Management: Mobile session management messages are 1871 used by the AC to push specific mobile station policies to the 1872 WTP. 1874 Firmware Management: Messages in this category are used by the AC to 1875 push a new firmware image to the WTP. 1877 Binding Specific Management Frames: Messages in this category are 1878 used by the AC and the WTP to exchange protocol-specific 1879 management frame. These frames may or may not be used to change 1880 the link state of a Mobile device. 1882 Discovery, WTP Configuration and Mobile Session Management messages 1883 MUST be implemented. Firmware Management MAY be implemented. 1885 In addition, technology specific bindings (see Section 11.7 may 1886 introduce new control channel commands. 1888 4.3.1. Control Message Format 1890 All CAPWAP control messages are sent encapsulated within the CAPWAP 1891 header (see Section 4.1). Immediately following the CAPWAP header, 1892 is the control header, which has the following format: 1894 0 1 2 3 1895 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 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | Message Type | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Seq Num | Msg Element Length | Flags | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | Time Stamp | 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 | Msg Element [0..N] ... 1904 +-+-+-+-+-+-+-+-+-+-+-+-+ 1906 4.3.1.1. Message Type 1908 The Message Type field identifies the function of the CAPWAP control 1909 message. The Message Type field is comprised of an IANA Enterprise 1910 Number and an enterprise specific message type number. The first 1911 three octets is the enterprise number in network byte order, with 1912 zero being used for CAPWAP generic message types and the IEEE 802.11 1913 IANA assigned enterprise number 13277 being used for IEEE 802.11 1914 technology specific message types. The last octet is the enterprise 1915 specific message type number, which has a range from 0 to 255. The 1916 message type field can be expressed as: 1918 Message Type = IANA Enterprise Number * 256 + enterprise specific message type number 1920 The valid values for base CAPWAP Message Types are given in the table 1921 below: 1923 CAPWAP Control Message Message Type 1924 Value 1925 Discovery Request 1 1926 Discovery Response 2 1927 Join Request 3 1928 Join Response 4 1929 Configuration Status 5 1930 Configuration Status Response 6 1931 Configuration Update Request 7 1932 Configuration Update Response 8 1933 WTP Event Request 9 1934 WTP Event Response 10 1935 Change State Event Request 11 1936 Change State Event Response 12 1937 Echo Request 13 1938 Echo Response 14 1939 Image Data Request 15 1940 Image Data Response 16 1941 Reset Request 17 1942 Reset Response 18 1943 Primary Discovery Request 19 1944 Primary Discovery Response 20 1945 Data Transfer Request 21 1946 Data Transfer Response 22 1947 Clear Configuration Request 23 1948 Clear Configuration Response 24 1949 Mobile Configuration Request 25 1950 Mobile Configuration Response 26 1952 4.3.1.2. Sequence Number 1954 The Sequence Number Field is an identifier value to match request and 1955 response packet exchanges. When a CAPWAP packet with a request 1956 message type is received, the value of the sequence number field is 1957 copied into the corresponding response packet. 1959 When a CAPWAP control message is sent, its internal sequence number 1960 counter is monotonically incremented, ensuring that no two requests 1961 pending have the same sequence number. This field will wrap back to 1962 zero. 1964 4.3.1.3. Message Element Length 1966 The Length field indicates the number of bytes following the Sequence 1967 Num field. 1969 4.3.1.4. Flags 1971 The Flags field MUST be set to zero. 1973 4.3.1.5. Time Stamp 1975 The Timestamp contains the timestamp. PRC-TODO: Details need to be 1976 added here, and I am waiting for info from Dave Perkins. 1978 4.3.1.6. Message Element[0..N] 1980 The message element(s) carry the information pertinent to each of the 1981 control message types. Every control message in this specification 1982 specifies which message elements are permitted. 1984 4.3.2. Control Message Quality of Service 1986 It is recommended that CAPWAP control messages be sent by both the AC 1987 and the WTP with an appropriate Quality of Service precedence value, 1988 ensuring that congestion in the network minimizes occurrences of 1989 CAPWAP control channel disconnects. Therefore, a Quality of Service 1990 enabled CAPWAP device should use the following values: 1992 802.1P: The precedence value of 7 SHOULD be used. 1994 DSCP: The DSCP tag value of 46 SHOULD be used. 1996 4.4. CAPWAP Protocol Message Elements 1998 This section defines the CAPWAP Protocol message elements which are 1999 included in CAPWAP protocol control messages. 2001 Message elements are used to carry information needed in control 2002 messages. Every message element is identified by the Type field, 2003 whose numbering space is defined below. The total length of the 2004 message elements is indicated in the Message Element Length field. 2006 All of the message element definitions in this document use a diagram 2007 similar to the one below in order to depict its format. Note that in 2008 order to simplify this specification, these diagrams do not include 2009 the header fields (Type and Length). The header field values are 2010 defined in the Message element descriptions. 2012 Additional message elements may be defined in separate IETF 2013 documents. 2015 The format of a message element uses the TLV format shown here: 2017 0 1 2 3 2018 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 2019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2020 | Type | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Length | Value ... 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 2025 Where Type (16 bit) identifies the character of the information 2026 carried in the Value field and Length (16 bits) indicates the number 2027 of bytes in the Value field. Type field values are allocated as 2028 follows: 2030 Usage Type Values 2032 CAPWAP Protocol Message Elements 1-1023 2033 IEEE 802.11 Message Elements 1024-2047 2034 Reserved for Future Use 2048 - 65024 2036 The table below lists the CAPWAP protocol Message Elements and their 2037 Type values. 2039 CAPWAP Message Element Type Value 2041 AC Descriptor 1 2042 AC IPv4 List 2 2043 AC IPv6 List 3 2044 AC Name 4 2045 AC Name with Index 5 2046 AC Timestamp 6 2047 Add MAC ACL Entry 7 2048 Add Mobile Station 8 2049 Add Static MAC ACL Entry 9 2050 CAPWAP Timers 10 2051 Data Transfer Data 11 2052 Data Transfer Mode 12 2053 Decryption Error Report 13 2054 Decryption Error Report Period 14 2055 Delete MAC ACL Entry 15 2056 Delete Mobile Station 16 2057 Delete Static MAC ACL Entry 17 2058 Discovery Type 18 2059 Duplicate IPv4 Address 19 2060 Duplicate IPv6 Address 20 2061 Idle Timeout 21 2062 Image Data 22 2063 Image Filename 23 2064 Initiate Download 24 2065 Location Data 25 2066 MTU Discovery Padding 26 2067 Radio Administrative State 27 2068 Result Code 28 2069 Session ID 29 2070 Statistics Timer 30 2071 Vendor Specific Payload 31 2072 WTP Board Data 32 2073 WTP Descriptor 33 2074 WTP Fallback 34 2075 WTP Frame Tunnel Mode 35 2076 WTP IPv4 IP Address 36 2077 WTP MAC Type 37 2078 WTP Manager Control IPv4 Address 38 2079 WTP Manager Control IPv6 Address 39 2080 WTP Name 40 2081 WTP Operational Statistics 41 2082 WTP Radio Information 42 2083 WTP Radio Statistics 43 2084 WTP Reboot Statistics 44 2085 WTP Static IP Address Information 45 2087 4.4.1. AC Descriptor 2089 The AC payload message element is used by the AC to communicate it's 2090 current state. The value contains the following fields. 2092 0 1 2 3 2093 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 2094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2095 | Stations | Limit | 2096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2097 | Active WTPs | Max WTPs | 2098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2099 | Security | R-MAC Field |Wireless Field | Reserved | 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 | Vendor Identifier | 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Type=4 | Length | 2104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2105 | Value... 2106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 | Vendor Identifier | 2108 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2109 | Type=5 | Length | 2110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2111 | Value... 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2114 Type: 1 for AC Descriptor 2116 Length: 18 2118 Stations: The number of mobile stations currently associated with 2119 the AC 2121 Limit: The maximum number of stations supported by the AC 2123 Active WTPs: The number of WTPs currently attached to the AC 2125 Max WTPs: The maximum number of WTPs supported by the AC 2127 Security: A 8 bit bit mask specifying the authentication credential 2128 type supported by the AC. The following values are supported (see 2129 Section 2.4.4): 2131 1 - X.509 Certificate Based 2133 2 - Pre-Shared Secret 2135 R-MAC Field: The AC supports the optional Radio MAC Address field in 2136 the CAPWAP transport Header (see Section 4.1). 2138 Wireless Field: The AC supports the optional Wireless Specific 2139 Information field in the CAPWAP transport Header (see 2140 Section 4.1). 2142 Reserved: MUST be set to zero 2144 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2145 Network Management Private Enterprise Codes" 2147 Type: Vendor specific encoding of AC information. The following 2148 values are supported. The Hardware and Software Version values 2149 MUST be included. 2151 4 - Hardware Version: The AC's hardware version number. 2153 5 - Software Version: The AC's Firmware version number. 2155 Length: Length of vendor specific encoding of AC information. 2157 Value: Vendor specific encoding of AC information. 2159 4.4.2. AC IPv4 List 2161 The AC List message element is used to configure a WTP with the 2162 latest list of ACs in a cluster. 2164 0 1 2 3 2165 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 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | AC IP Address[] | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2170 Type: 2 for AC List 2172 Length: 4 2174 The AC IP Address: An array of 32-bit integers containing an AC's 2175 IPv4 Address. 2177 4.4.3. AC IPv6 List 2179 The AC List message element is used to configure a WTP with the 2180 latest list of ACs in a cluster. 2182 0 1 2 3 2183 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 2184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2185 | AC IP Address[] | 2186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2187 | AC IP Address[] | 2188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2189 | AC IP Address[] | 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | AC IP Address[] | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2194 Type: 3 for AC IPV6 List 2196 Length: 16 2198 The AC IP Address: An array of 32-bit integers containing an AC's 2199 IPv6 Address. 2201 4.4.4. AC Name 2203 The AC name message element contains an ASCII representation of the 2204 AC's identity. The value is a variable length byte string. The 2205 string is NOT zero terminated. 2207 0 2208 0 1 2 3 4 5 6 7 2209 +-+-+-+-+-+-+-+-+ 2210 | Name ... 2211 +-+-+-+-+-+-+-+-+ 2213 Type: 4 for AC Name 2215 Length: > 0 2217 Name: A variable length ASCII string containing the AC's name 2219 4.4.5. AC Name with Index 2221 The AC Name with Index message element is sent by the AC to the WTP 2222 to configure preferred ACs. The number of instances where this 2223 message element would be present is equal to the number of ACs 2224 configured on the WTP. 2226 0 1 2227 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 | Index | AC Name... 2230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2232 Type: 5 for AC Name with Index 2234 Length: > 2 2236 Index: The index of the preferred server (e.g., 1=primary, 2237 2=secondary). 2239 AC Name: A variable length ASCII string containing the AC's name. 2241 4.4.6. AC Timestamp 2243 The AC Timestamp message element is sent by the AC to synchronize the 2244 WTP's clock. 2246 0 1 2 3 2247 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 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2249 | Timestamp | 2250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2252 Type: 6 for AC Timestamp 2254 Length: 4 2256 Timestamp: The AC's current time, allowing all of the WTPs to be 2257 time synchronized in the format defined by Network Time Protocol 2258 (NTP) in RFC 1305 [10]. 2260 4.4.7. Add MAC ACL Entry 2262 The Add MAC Access Control List (ACL) Entry message element is used 2263 by an AC to add a MAC ACL list entry on a WTP, ensuring that the WTP 2264 no longer provides any service to the MAC addresses provided in the 2265 message. The MAC Addresses provided in this message element are not 2266 expected to be saved in non-volatile memory on the WTP. 2268 0 1 2 3 2269 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 2270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2271 | Num of Entries| MAC Address[] | 2272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2273 | MAC Address[] | 2274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 Type: 7 for Add MAC ACL Entry 2278 Length: >= 7 2280 Num of Entries: The number of MAC Addresses in the array. 2282 MAC Address: An array of MAC Addresses to add to the ACL. 2284 4.4.8. Add Mobile Station 2286 The Add Mobile Station message element is used by the AC to inform a 2287 WTP that it should forward traffic for a particular mobile station. 2288 The Add Mobile Station message element will be accompanied by 2289 technology specific binding information element which may include 2290 security parameters. Consequently, the security parameters must be 2291 applied by the WTP for the particular mobile. 2293 Once a mobile station's policy has been pushed to the WTP through 2294 this message element, an AC may change any policies by simply sending 2295 a modified Add Mobile Station message element. When a WTP receives 2296 an Add Mobile Station message element for an existing mobile station, 2297 it must override any existing state it may have for the mobile 2298 station in question. The latest Add Mobile Station message element 2299 data overrides any previously received messages. 2301 0 1 2 3 2302 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 2303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2304 | Radio ID | MAC Address | 2305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2306 | MAC Address | VLAN Name... 2307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2309 Type: 8 for Add Mobile 2311 Length: >= 7 2312 Radio ID: An 8-bit value representing the radio 2314 MAC Address: The mobile station's MAC Address 2316 VLAN Name: An optional variable string containing the VLAN Name on 2317 which the WTP is to locally bridge user data. Note this field is 2318 only valid with WTPs configured in Local MAC mode. 2320 4.4.9. Add Static MAC ACL Entry 2322 The Add Static MAC ACL Entry message element is used by an AC to add 2323 a permanent ACL entry on a WTP, ensuring that the WTP no longer 2324 provides any service to the MAC addresses provided in the message. 2325 The MAC Addresses provided in this message element are expected to be 2326 saved in non-volative memory on the WTP. 2328 0 1 2 3 2329 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 2330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2331 | Num of Entries| MAC Address[] | 2332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2333 | MAC Address[] | 2334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 Type: 9 for Add Static MAC ACL Entry 2338 Length: >= 7 2340 Num of Entries: The number of MAC Addresses in the array. 2342 MAC Address: An array of MAC Addresses to add to the permanent ACL. 2344 4.4.10. CAPWAP Timers 2346 The CAPWAP Timers message element is used by an AC to configure 2347 CAPWAP timers on a WTP. 2349 0 1 2350 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Discovery | Echo Request | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2355 Type: 10 for CAPWAP Timers 2356 Length: 2 2358 Discovery: The number of seconds between CAPWAP Discovery packets, 2359 when the WTP is in the discovery mode. 2361 Echo Request: The number of seconds between WTP Echo Request CAPWAP 2362 messages. 2364 4.4.11. Data Transfer Data 2366 The Data Transfer Data message element is used by the WTP to provide 2367 information to the AC for debugging purposes. 2369 0 1 2 2370 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2372 | Data Type | Data Length | Data .... 2373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2375 Type: 11 for Data Transfer Data 2377 Length: >= 3 2379 Data Type: An 8-bit value the type of information being sent. The 2380 following values are supported: 2382 1 - WTP Crash Data 2384 2 - WTP Memory Dump 2386 Data Length: Length of data field. 2388 Data: Debug information. 2390 4.4.12. Data Transfer Mode 2392 The Data Transfer Mode message element is used by the WTP to indicate 2393 the type of data transfer information it is sending to the AC for 2394 debugging purposes. 2396 0 2397 0 1 2 3 4 5 6 7 2398 +-+-+-+-+-+-+-+-+ 2399 | Data Type | 2400 +-+-+-+-+-+-+-+-+ 2402 Type: 12 for Data Transfer Mode 2404 Length: 1 2406 Data Type: An 8-bit value the type of information being requested. 2407 The following values are supported: 2409 1 - WTP Crash Data 2411 2 - WTP Memory Dump 2413 4.4.13. Decryption Error Report 2415 The Decryption Error Report message element value is used by the WTP 2416 to inform the AC of decryption errors that have occurred since the 2417 last report. Note that this error reporting mechanism is not used if 2418 encryption and decryption services are provided via the AC. 2420 0 1 2 2421 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2423 | Radio ID |Num Of Entries | Mobile MAC Address | 2424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 | Mobile MAC Address[] | 2426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 Type: 13 for Decryption Error Report 2430 Length: >= 8 2432 Radio ID: The Radio Identifier, which typically refers to an 2433 interface index on the WTP 2435 Num Of Entries: An 8-bit unsigned integer indicating the number of 2436 mobile MAC addresses. 2438 Mobile MAC Address: An array of mobile station MAC addresses that 2439 have caused decryption errors. 2441 4.4.14. Decryption Error Report Period 2443 The Decryption Error Report Period message element value is used by 2444 the AC to inform the WTP how frequently it should send decryption 2445 error report messages. 2447 0 1 2 2448 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2450 | Radio ID | Report Interval | 2451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2453 Type: 14 for Decryption Error Report Period 2455 Length: 3 2457 Radio ID: The Radio Identifier, typically refers to some interface 2458 index on the WTP 2460 Report Interval: A 16-bit unsigned integer indicating the time, in 2461 seconds 2463 4.4.15. Delete MAC ACL Entry 2465 The Delete MAC ACL Entry message element is used by an AC to delete a 2466 MAC ACL entry on a WTP, ensuring that the WTP provides service to the 2467 MAC addresses provided in the message. 2469 0 1 2 3 2470 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 2471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2472 | Num of Entries| MAC Address[] | 2473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2474 | MAC Address[] | 2475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2477 Type: 15 for Delete MAC ACL Entry 2479 Length: >= 7 2481 Num of Entries: The number of MAC Addresses in the array. 2483 MAC Address: An array of MAC Addresses to delete from the ACL. 2485 4.4.16. Delete Mobile Station 2487 The Delete Mobile station message element is used by the AC to inform 2488 an WTP that it should no longer provide service to a particular 2489 mobile station. The WTP must terminate service immediately upon 2490 receiving this message element. 2492 The transmission of a Delete Mobile Station message element could 2493 occur for various reasons, including for administrative reasons, as a 2494 result of the fact that the mobile has roamed to another WTP, etc. 2496 Once access has been terminated for a given station, any future 2497 packets received from the mobile station must result in a 2498 deauthenticate message, as specified in [6]. 2500 0 1 2 3 2501 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 2502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2503 | Radio ID | MAC Address | 2504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2505 | MAC Address | 2506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2508 Type: 16 for Delete Mobile Station 2510 Length: 7 2512 Radio ID: An 8-bit value representing the radio 2514 MAC Address: The mobile station's MAC Address 2516 4.4.17. Delete Static MAC ACL Entry 2518 The Delete Static MAC ACL Entry message element is used by an AC to 2519 delete a previously added static MAC ACL entry on a WTP, ensuring 2520 that the WTP provides service to the MAC addresses provided in the 2521 message. 2523 0 1 2 3 2524 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 2525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2526 | Num of Entries| MAC Address[] | 2527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2528 | MAC Address[] | 2529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2531 Type: 17 for Delete Static MAC ACL Entry 2533 Length: >= 7 2535 Num of Entries: The number of MAC Addresses in the array. 2537 MAC Address: An array of MAC Addresses to delete from the static MAC 2538 ACL entry. 2540 4.4.18. Discovery Type 2542 The Discovery Type message element is used by the WTP to indicate how 2543 it has come to know about the existence of the AC, to which it is 2544 sending the Discovery Request message. 2546 0 2547 0 1 2 3 4 5 6 7 2548 +-+-+-+-+-+-+-+-+ 2549 | Discovery Type| 2550 +-+-+-+-+-+-+-+-+ 2552 Type: 18 for Discovery Type 2554 Length: 1 2556 Discovery Type: An 8-bit value indicating how the WTP discovered the 2557 AC . The following values are supported: 2559 0 - Unknown 2561 1 - Static Configuration 2563 2 - DHCP 2565 3 - DNS 2567 4 - AC Referral 2569 4.4.19. Duplicate IPv4 Address 2571 The Duplicate IPv4 Address message element is used by a WTP to inform 2572 an AC that it has detected another IP device using the same IP 2573 address it is currently using. 2575 0 1 2 3 2576 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 2577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2578 | IP Address | 2579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2580 | MAC Address | 2581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2582 | MAC Address | 2583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2585 Type: 19 for Duplicate IPv4 Address 2587 Length: 10 2588 IP Address: The IP Address currently used by the WTP. 2590 MAC Address: The MAC Address of the offending device. 2592 4.4.20. Duplicate IPv6 Address 2594 The Duplicate IPv6 Address message element is used by a WTP to inform 2595 an AC that it has detected another host using the same IP address it 2596 is currently using. 2598 0 1 2 3 2599 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 2600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2601 | IP Address | 2602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2603 | IP Address | 2604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2605 | IP Address | 2606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2607 | IP Address | 2608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2609 | MAC Address | 2610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2611 | MAC Address | 2612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2614 Type: 20 for Duplicate IPv6 Address 2616 Length: 22 2618 IP Address: The IP Address currently used by the WTP. 2620 MAC Address: The MAC Address of the offending device. 2622 4.4.21. Idle Timeout 2624 The Idle Timeout message element is sent by the AC to the WTP to 2625 provide it with the idle timeout that it should enforce on its active 2626 mobile station entries. 2628 0 1 2 3 2629 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 2630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2631 | Timeout | 2632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2634 Type: 20 for Idle Timeout 2636 Length: 4 2638 Timeout: The current idle timeout to be enforced by the WTP. 2640 4.4.22. Image Data 2642 The image data message element is present in the Image Data Request 2643 message sent by the AC and contains the following fields. 2645 0 1 2 3 2646 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 2647 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2648 | Opcode | Checksum | Image Data | 2649 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2650 | Image Data ... | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 Type: 22 for Image Data 2655 Length: >= 4 (allows 0 length element if last data unit is 1024 2656 bytes) 2658 Opcode: An 8-bit value representing the transfer opcode. The 2659 following values are supported: 2661 3 - Image data is included 2663 5 - An error occurred. Transfer is aborted 2665 Checksum: A 16-bit value containing a checksum of the image data 2666 that follows 2668 Image Data: The Image Data field contains 1024 characters, unless 2669 the payload being sent is the last one (end of file). If the last 2670 block was 1024 in length, an Image Data with a zero length payload 2671 is sent. 2673 4.4.23. Image Filename 2675 The image filename message element is sent by the WTP to the AC and 2676 is used to initiate the firmware download process. This message 2677 element contains the image filename, which the AC subsequently 2678 transfers to the WTP via the Image Data message element. The value 2679 is a variable length byte string, which is NOT zero terminated. 2681 0 1 2 3 2682 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 2683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2684 | Filename ... | 2685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2687 Type: 23 for Image Filename 2689 Length: >= 1 2691 Filename: A variable length string containing the filename to 2692 download. 2694 4.4.24. Initiate Download 2696 The Initiate Download message element is used by the AC to inform the 2697 WTP that it should initiate a firmware upgrade. This is performed by 2698 having the WTP initiate its own Image Data Request, with the Image 2699 Download message element. This message element does not contain any 2700 data. 2702 Type: 24 for Initiate Download 2704 Length: 0 2706 4.4.25. Location Data 2708 The Location Data message elementis a variable length byte string 2709 containing user defined location information (e.g. "Next to 2710 Fridge"). This information is configurable by the network 2711 administrator, and allows for the WTP location to be determined 2712 through this field. The string is not zero terminated. 2714 0 2715 0 1 2 3 4 5 6 7 2716 +-+-+-+-+-+-+-+-+- 2717 | Location ... 2718 +-+-+-+-+-+-+-+-+- 2720 Type: 25 for Location Data 2722 Length: > 0 2724 Timeout: A non-zero terminated string containing the WTP location. 2726 4.4.26. MTU Discovery Padding 2728 The MTU Discovery Padding message element is used as padding to 2729 perform MTU discovery, and MUST contain octets of value 0xFF, of any 2730 length 2732 0 2733 0 1 2 3 4 5 6 7 2734 +-+-+-+-+-+-+-+-+ 2735 | Padding... 2736 +-+-+-+-+-+-+-+- 2738 Type: 26 for MTU Discovery Padding 2740 Length: variable 2742 Timeout: A variable length pad. 2744 4.4.27. Radio Administrative State 2746 The radio administrative state message element is used to communicate 2747 the state of a particular radio. The value contains the following 2748 fields. 2750 0 1 2 2751 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 2752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 | Radio ID | Admin State | Cause | 2754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 Type: 27 for Administrative State 2758 Length: 2 2760 Radio ID: An 8-bit value representing the radio to configure. The 2761 Radio ID field may also include the value of 0xff, which is used 2762 to identify the WTP itself. Therefore, if an AC wishes to change 2763 the administrative state of a WTP, it would include 0xff in the 2764 Radio ID field. 2766 Admin State: An 8-bit value representing the administrative state of 2767 the radio. The following values are supported: 2769 1 - Enabled 2770 2 - Disabled 2772 Cause: In the event of a radio being inoperable, the cause field 2773 would contain the reason the radio is out of service. The 2774 following values are supported: 2776 0 - Normal 2778 1 - Radio Failure 2780 2 - Software Failure 2782 3 - Radar Detection 2784 4.4.28. Result Code 2786 The Result Code message element value is a 32-bit integer value, 2787 indicating the result of the request operation corresponding to the 2788 sequence number in the message. 2790 0 1 2 3 2791 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 2792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 | Result Code | 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2796 Type: 28 for Result Code 2798 Length: 4 2800 Result Code: The following values are defined: 2802 0 Success 2804 1 Failure (AC List message element MUST be present) 2806 2 Success (NAT detected) 2808 3 Failure (unspecified) 2810 4 Failure (Join Failure, Resource Depletion) 2812 5 Failure (Join Failure, Unknown Source) 2814 6 Failure (Join Failure, Incorrect Data) 2815 7 Failure (Join Failure, Session ID already in use) 2817 4.4.29. Session ID 2819 The session ID message element value contains a randomly generated 2820 unsigned 32-bit integer. 2822 0 1 2 3 2823 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 2 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | Session ID | 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2828 Type: 29 for Session ID 2830 Length: 4 2832 Session ID: A 32-bit random session identifier 2834 4.4.30. Statistics Timer 2836 The statistics timer message element value is used by the AC to 2837 inform the WTP of the frequency which it expects to receive updated 2838 statistics. 2840 0 1 2841 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 2842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2843 | Statistics Timer | 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 Type: 30 for Statistics Timer 2848 Length: 2 2850 Statistics Timer: A 16-bit unsigned integer indicating the time, in 2851 seconds 2853 4.4.31. Vendor Specific Payload 2855 The Vendor Specific Payload is used to communicate vendor specific 2856 information between the WTP and the AC. The value contains the 2857 following format: 2859 0 1 2 3 2860 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 2861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2862 | Vendor Identifier | 2863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2864 | Element ID | Value... | 2865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2867 Type: 31 for Vendor Specific 2869 Length: >= 7 2871 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2872 Network Management Private Enterprise Codes" [19] 2874 Element ID: A 16-bit Element Identifier which is managed by the 2875 vendor. 2877 Value: The value associated with the vendor specific element. 2879 4.4.32. WTP Board Data 2881 The WTP Board Data message element is sent by the WTP to the AC and 2882 contains information about the hardware present. 2884 0 1 2 3 2885 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 2886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2887 | Vendor Identifier | 2888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2889 | Type=0 | Length | 2890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2891 | Value... 2892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2893 | Type=1 | Length | 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | Value... 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 | Optional additional vendor specific WTP board data TLVs 2899 Type: 32 for WTP Board Data 2901 Length: >=14 2902 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2903 Network Management Private Enterprise Codes" 2905 Type: The following values are supported: 2907 0 - WTP Model Number: The WTP Model Number MUST be included in 2908 the WTP Board Data message element. 2910 1 - WTP Serial Number: The WTP Serial Number MUST be included in 2911 the WTP Board Data message element. 2913 2 - Board ID: A hardware identifier, which MAY be included in the 2914 WTP Board Data mesage element. 2916 3 - Board Revision A revision number of the board, which MAY be 2917 included in the WTP Board Data message element. 2919 4.4.33. WTP Descriptor 2921 The WTP descriptor message element is used by a WTP to communicate 2922 it's current hardware/firmware configuration. The value contains the 2923 following fields. 2925 0 1 2 3 2926 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 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | Max Radios | Radios in use | Encryption Capabilities | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 | Vendor Identifier | 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2932 | Type=0 | Length | 2933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2934 | Value... 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2936 | Vendor Identifier | 2937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2938 | Type=1 | Length | 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 | Value... 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2942 | Vendor Identifier | 2943 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2944 | Type=0 | Length | 2945 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2946 | Value... 2947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2949 Type: 33 for WTP Descriptor 2951 Length: >= 31 2953 Max Radios: An 8-bit value representing the number of radios (where 2954 each radio is identified via the RID field) supported by the WTP 2956 Radios in use: An 8-bit value representing the number of radios 2957 present in the WTP 2959 Encryption Capabilities: This 16-bit field is used by the WTP to 2960 communicate it's capabilities to the AC. Since most WTP's support 2961 link layer encryption, the AC may make use of these services. 2962 There are binding dependent encryption capabilities. A WTP that 2963 does not have any encryption capabilities would set this field to 2964 zero (0). Refer to the specific binding for further specification 2965 of the Encryption Capabilities field. 2967 Vendor Identifier: A 32-bit value containing the IANA assigned "SMI 2968 Network Management Private Enterprise Codes" 2970 Type: The following values are supported. The Hardware Version, 2971 Software Version, and Boot Version values MUST be included. 2973 0 - WTP Model Number: The WTP Model Number MUST be included in 2974 the WTP Board Data message element. 2976 1 - WTP Serial Number: The WTP Serial Number MUST be included in 2977 the WTP Board Data message element. 2979 2 - Board ID: A hardware identifier, which MAY be included in the 2980 WTP Board Data mesage element. 2982 3 - Board Revision A revision number of the board, which MAY be 2983 included in the WTP Board Data message element. 2985 4 - Hardware Version: The WTP's hardware version number. 2987 5 - Software Version: The WTP's Firmware version number. 2989 6 - Boot Version: The WTP's boot loader's version number. 2991 Length: Length of vendor specific encoding of WTP information. 2993 Value: Vendor specific encoding of WTP information. 2995 4.4.34. WTP Fallback 2997 The WTP Fallback message element is sent by the AC to the WTP to 2998 enable or disable automatic CAPWAP fallback in the event that a WTP 2999 detects its preferred AC, and is not currently connected to it. 3001 0 3002 0 1 2 3 4 5 6 7 3003 +-+-+-+-+-+-+-+-+ 3004 | Mode | 3005 +-+-+-+-+-+-+-+-+ 3007 Type: 34 for WTP Fallback 3009 Length: 1 3011 Mode: The 8-bit value indicates the status of automatic CAPWAP 3012 fallback on the WTP. A value of zero disables fallback, while a 3013 value of one enables it. When enabled, if the WTP detects that 3014 its primary AC is available, and it is not connected to it, it 3015 SHOULD automatically disconnect from its current AC and reconnect 3016 to its primary. If disabled, the WTP will only reconnect to its 3017 primary through manual intervention (e.g., through the Reset 3018 Request command). 3020 4.4.35. WTP Frame Tunnel Mode 3022 The WTP Frame Tunnel Mode message element allows the WTP to 3023 communicate the tunneling modes of operation which it supports to the 3024 AC. A WTP that advertises support for all types allows the AC to 3025 select which type will be used, based on its local policy. 3027 0 3028 0 1 2 3 4 5 6 7 3029 +-+-+-+-+-+-+-+-+ 3030 | Tunnel Mode | 3031 +-+-+-+-+-+-+-+-+ 3033 Type: 35 for WTP Frame Tunnel Mode 3035 Length: 1 3037 Frame Tunnel Mode: The Frame Tunnel mode specifies the tunneling 3038 modes for mobile station data which are supported by the WTP. The 3039 following values are supported: 3041 1 - Local Bridging: When Local Bridging is used, the WTP does not 3042 tunnel user traffic to the AC; all user traffic is locally 3043 bridged. This value MUST NOT be used when the WTP MAC Type is 3044 set to Split-MAC. 3046 2 - 802.3 Frame Tunnel Mode: The 802.3 Frame Tunnel Mode requires 3047 the WTP and AC to encapsulate all user payload as native IEEE 3048 802.3 frames (see Section 4.2). All user traffic is tunneled 3049 to the AC. This value MUST NOT be used when the WTP MAC Type 3050 is set to Split-MAC. 3052 4 - Native Frame Tunnel Mode: Native Frame Tunnel mode requires 3053 the WTP and AC to encapsulate all user payloads as native 3054 wireless frames, as defined by the wireless binding (see for 3055 example Section 4.2). 3057 7 - All: The WTP is capable of supporting all frame tunnel modes. 3059 4.4.36. WTP IPv4 IP Address 3061 The WTP IPv4 address is used to perform NAT detection. 3063 0 1 2 3 3064 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 3065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3066 | WTP IPv4 IP Address | 3067 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3069 Type: 36 for WTP IPv4 IP Address 3071 Length: 4 3073 WTP IPv4 IP Address: The IPv4 address from which the WTP is sending 3074 packets. This field is used for NAT detection. 3076 4.4.37. WTP MAC Type 3078 The WTP MAC-Type message element allows the WTP to communicate its 3079 mode of operation to the AC. A WTP that advertises support for both 3080 modes allows the AC to select the mode to use, based on local policy. 3082 0 3083 0 1 2 3 4 5 6 7 3084 +-+-+-+-+-+-+-+-+ 3085 | MAC Type | 3086 +-+-+-+-+-+-+-+-+ 3088 Type: 37 for WTP MAC Type 3090 Length: 1 3092 MAC Type: The MAC mode of operation supported by the WTP. The 3093 following values are supported 3095 0 - Local-MAC: Local-MAC is the default mode that MUST be 3096 supported by all WTPs. 3098 1 - Split-MAC: Split-MAC support is optional, and allows the AC 3099 to receive and process native wireless frames. 3101 2 - Both: WTP is capable of supporting both Local-MAC and Split- 3102 MAC. 3104 4.4.38. WTP Radio Information 3106 The WTP radios information message element is used to communicate the 3107 radio information in a specific slot. The Discovery Request MUST 3108 include one such message element per radio in the WTP. The Radio- 3109 Type field is used by the AC in order to determine which technology 3110 specific binding is to be used with the WTP. 3112 The value contains two fields, as shown. 3114 0 1 2 3 3115 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 3116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3117 | Radio ID | Radio Type | 3118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3119 | Radio Type | 3120 +-+-+-+-+-+-+-+-+ 3122 Type: 38 for WTP Radio Information 3124 Length: 5 3126 Radio ID: The Radio Identifier, which typically refers to an 3127 interface index on the WTP 3129 Radio Type: The type of radio present. Note this bitfield can be 3130 used to specify support for more than a single type of PHY/MAC. 3131 The following values are supported: 3133 1 - 802.11b: An IEEE 802.11b radio. 3135 2 - 802.11a: An IEEE 802.11a radio. 3137 4 - 802.11g: An IEEE 802.11g radio. 3139 8 - 802.11n: An IEEE 802.11n radio. 3141 0xOF - 802.11b, 802.11a, 802.11g and 802.11n: The 4 radio types 3142 indicated are supported in the WTP. 3144 4.4.39. WTP Manager Control IPv4 Address 3146 The WTP Manager Control IPv4 Address message element is sent by the 3147 AC to the WTP during the discovery process and is used by the AC to 3148 provide the interfaces available on the AC, and the current number of 3149 WTPs connected. In the event that multiple WTP Manager Control IPV4 3150 Address message elements are returned, the WTP is expected to perform 3151 load balancing across the multiple interfaces. 3153 0 1 2 3 3154 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 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 | IP Address | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | WTP Count | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 Type: 39 for WTP Manager Control IPv4 Address 3163 Length: 6 3165 IP Address: The IP Address of an interface. 3167 WTP Count: The number of WTPs currently connected to the interface. 3169 4.4.40. WTP Manager Control IPv6 Address 3171 The WTP Manager Control IPv6 Address message element is sent by the 3172 AC to the WTP during the discovery process and is used by the AC to 3173 provide the interfaces available on the AC, and the current number of 3174 WTPs connected. This message element is useful for the WTP to 3175 perform load balancing across multiple interfaces. 3177 0 1 2 3 3178 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 3179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3180 | IP Address | 3181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3182 | IP Address | 3183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3184 | IP Address | 3185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3186 | IP Address | 3187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3188 | WTP Count | 3189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3191 Type: 40 for WTP Manager Control IPv6 Address 3193 Length: 18 3195 IP Address: The IP Address of an interface. 3197 WTP Count: The number of WTPs currently connected to the interface. 3199 4.4.41. WTP Name 3201 The WTP Name message element is a variable length bye string. The 3202 string is not zero terminated. 3204 0 3205 0 1 2 3 4 5 6 7 3206 +-+-+-+-+-+-+-+-+- 3207 | WTP Name ... 3208 +-+-+-+-+-+-+-+-+- 3210 Type: 41 for WTP Name 3212 Length: variable 3214 WTP Name: A non-zero terminated string containing the WTP name. 3216 4.4.42. WTP Operational Statistics 3218 The WTP Operational Statistics message element is sent by the WTP to 3219 the AC to provide statistics related to the operation of the WTP. 3221 0 1 2 3 3222 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 3223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3224 | Radio ID | Tx Queue Level | Wireless Link Frames per Sec | 3225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3227 Type: 42 for WTP Operational Statistics 3229 Length: 4 3231 Radio ID: The radio ID of the radio to which the statistics apply. 3233 Wireless Transmit Queue Level: The percentage of Wireless Transmit 3234 queue utilization, calaculated as the sum of utilized transmit 3235 queue lengths divided by the sum of maximum transmit queue 3236 lengths, multiplied by 100. The Wireless Transmit Queue Level is 3237 representative of congestion conditions over wireless interfaces 3238 between the WTP and wireless terminals. 3240 Wireless Link Frames per Sec: The number of frames transmitted or 3241 received per second by the WTP over the sir interface. 3243 4.4.43. WTP Radio Statistics 3245 The WTP Radio Statistics message element is sent by the WTP to the AC 3246 to communicate statistics on radio behavior and reasons why the WTP 3247 radio has been reset. 3249 0 1 2 3 3250 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 3251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3252 | Radio ID | Last Fail Type| Reset Count | 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 | SW Failure Count | HW Failure Count | 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3256 | Other Failure Count | Unknown Failure Count | 3257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3258 | Config Update Count | Channel Change Count | 3259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3260 | Band Change Count | Current Noise Floor | 3261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3263 Type: 43 for WTP Radio Statistics 3265 Length: 20 3267 Radio ID: The radio ID of the radio to which the statistics apply. 3269 Last Failure Type: The last WTP failure. The following values are 3270 supported: 3272 0 - Statistic Not Supported 3274 1 - Software Failure 3276 2 - Hardware Failure 3278 3 - Other Failure 3280 255 - Unknown (e.g., WTP doesn't keep track of info) 3282 Reset Count: The number of times that that the radio has been reset. 3284 SW Failure Count: The number of times that the radio has failed due 3285 to software related reasons. 3287 HW Failure Count: The number of times that the radio has failed due 3288 to hardware related reasons. 3290 Other Failure Count: The number of times that the radio has failed 3291 due to known reasons, other than software or hardware failure. 3293 Unknown Failure Count: The number of times that the radio has failed 3294 for unknown reasons. 3296 Config Update Count: The number of times that the radio 3297 configuration has been updated. 3299 Channel Change Count: The number of times that the radio channel has 3300 been changed. 3302 Band Change Count: The number of times that the radio has changed 3303 frequency bands. 3305 Current Noise Floor: A signed integer which indicates the noise 3306 floor of the radio receiver in units of dBm. 3308 4.4.44. WTP Reboot Statistics 3310 The WTP Reboot Statistics message element is sent by the WTP to the 3311 AC to communicate reasons why WTP reboots have occurred. 3313 0 1 2 3 3314 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 3315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3316 | Reboot Count | AC Initiated Count | 3317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3318 | Link Failure Count | SW Failure Count | 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | HW Failure Count | Other Failure Count | 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | Unknown Failure Count |Last Failure Type| 3323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3325 Type: 44 for WTP Reboot Statistics 3327 Length: 15 3329 Reboot Count: The number of reboots that have occurred due to a WTP 3330 crash. A value of 65535 implies that this information is not 3331 available on the WTP. 3333 AC Initiated Count: The number of reboots that have occurred at the 3334 request of a CAPWAP protocol message, such as a change in 3335 configuration that required a reboot or an explicit CAPWAP 3336 protocol reset request. A value of 65535 implies that this 3337 information is not available on the WTP. 3339 Link Failure Count: The number of times that a CAPWAP protocol 3340 connection with an AC has failed due to link failure. 3342 SW Failure Count: The number of times that a CAPWAP protocol 3343 connection with an AC has failed due to software related reasons. 3345 HW Failure Count: The number of times that a CAPWAP protocol 3346 connection with an AC has failed due to hardware related reasons. 3348 Other Failure Count: The number of times that a CAPWAP protocol 3349 connection with an AC has failed due to known reasons, other than 3350 AC initiated, link, SW or HW failure. 3352 Unknown Failure Count: The number of times that a CAPWAP protocol 3353 connection with an AC has failed for unknown reasons. 3355 Last Failure Type: The failure type of the most recent WTP failure. 3356 The following values are supported: 3358 0 - Not Supported 3360 1 - AC Initiated (see Section 9.3) 3362 2 - Link Failure 3364 3 - Software Failure 3366 4 - Hardware Failure 3368 5 - Other Failure 3370 255 - Unknown (e.g., WTP doesn't keep track of info) 3372 4.4.45. WTP Static IP Address Information 3374 The WTP Static IP Address Information message element is used by an 3375 AC to configure or clear a previously configured static IP address on 3376 a WTP. 3378 0 1 2 3 3379 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 3380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3381 | IP Address | 3382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3383 | Netmask | 3384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3385 | Gateway | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3387 | Static | 3388 +-+-+-+-+-+-+-+-+ 3390 Type: 45 for WTP Static IP Address Information 3392 Length: 13 3394 IP Address: The IP Address to assign to the WTP. This field is only 3395 valid if the static field is set to one. 3397 Netmask: The IP Netmask. This field is only valid if the static 3398 field is set to one. 3400 Gateway: The IP address of the gateway. This field is only valid if 3401 the static field is set to one. 3403 Netmask: The IP Netmask. This field is only valid if the static 3404 field is set to one. 3406 Static: An 8-bit boolean stating whether the WTP should use a static 3407 IP address or not. A value of zero disables the static IP 3408 address, while a value of one enables it. 3410 4.5. CAPWAP Protocol Timers 3412 A WTP or AC that implements CAPWAP discovery MUST implement the 3413 following timers. 3415 4.5.1. DiscoveryInterval 3417 The minimum time, in seconds, that a WTP MUST wait after receiving a 3418 Discovery Response, before initiating a DTLS handshake. 3420 Default: 5 3422 4.5.2. DTLSRehandshake 3424 The minimum time, in seconds, a WTP MUST wait for DTLS rehandshake to 3425 complete. 3427 Default: 10 3429 4.5.3. DTLSSessionDelete 3431 The minimum time, in seconds, a WTP MUST wait for DTLS session 3432 deletion. 3434 Default: 5 3436 4.5.4. EchoInterval 3438 The minimum time, in seconds, between sending echo requests to the AC 3439 with which the WTP has joined. 3441 Default: 30 3443 4.5.5. KeyLifetime 3445 The maximum time, in seconds, which a CAPWAP DTLS session key is 3446 valid. 3448 Default: 28800 3450 4.5.6. MaxDiscoveryInterval 3452 The maximum time allowed between sending discovery requests from the 3453 interface, in seconds. Must be no less than 2 seconds and no greater 3454 than 180 seconds. 3456 Default: 20 seconds. 3458 4.5.7. NeighborDeadInterval 3460 The minimum time, in seconds, a WTP MUST wait without having received 3461 Echo Responses to its Echo Requests, before the destination for the 3462 Echo Request may be considered dead. Must be no less than 3463 2*EchoInterval seconds and no greater than 240 seconds. 3465 Default: 60 3467 4.5.8. ResponseTimeout 3469 The minimum time, in seconds, which the WTP or AC must respond to a 3470 CAPWAP Request message. 3472 Default: 1 3474 4.5.9. RetransmitInterval 3476 The minimum time, in seconds, which a non-acknowledged CAPWAP packet 3477 will be retransmitted. 3479 Default: 3 3481 4.5.10. SilentInterval 3483 The minimum time, in seconds, a WTP MUST wait after failing to 3484 receive any responses to its discovery requests, before it MAY again 3485 send discovery requests. 3487 Default: 30 3489 4.5.11. WaitJoin 3491 The maximum time, in seconds, a WTP MUST wait without having received 3492 a DTLS Handshake message from an AC. This timer must be greater than 3493 30 seconds. 3495 Default: 60 3497 4.6. CAPWAP Protocol Variables 3499 A WTP or AC that implements CAPWAP discovery MUST allow for the 3500 following variables to be configured by system management; default 3501 values are specified so as to make it unnecessary to configure any of 3502 these variables in many cases. 3504 4.6.1. DiscoveryCount 3506 The number of discoveries transmitted by a WTP to a single AC. This 3507 is a monotonically increasing counter. 3509 4.6.2. MaxDiscoveries 3511 The maximum number of discovery requests that will be sent after a 3512 WTP boots. 3514 Default: 10 3516 4.6.3. MaxRetransmit 3518 The maximum number of retransmissions for a given CAPWAP packet 3519 before the link layer considers the peer dead. 3521 Default: 5 3523 4.6.4. RetransmitCount 3525 The number of retransmissions for a given CAPWAP packet. This is a 3526 monotonically increasing counter. 3528 5. CAPWAP Discovery Operations 3530 The Discovery messages are used by a WTP to determine which ACs are 3531 available to provide service, and the capabilities and load of the 3532 ACs. 3534 5.1. Discovery Request Message 3536 The Discovery Request message is used by the WTP to automatically 3537 discover potential ACs available in the network. The Discovery 3538 Request message provides ACs with the primary capabilities of the 3539 WTP. A WTP must exchange this information to ensure subsequent 3540 exchanges with the ACs are consistent with the WTP's functional 3541 characteristics. A WTP must transmit this command even if it has a 3542 statically configured AC. 3544 Discovery Request messages MUST be sent by a WTP in the Discover 3545 state after waiting for a random delay less than 3546 MaxDiscoveryInterval, after a WTP first comes up or is 3547 (re)initialized. A WTP MUST send no more than the maximum of 3548 MaxDiscoveries Discovery Request messages, waiting for a random delay 3549 less than MaxDiscoveryInterval between each successive message. 3551 This is to prevent an explosion of WTP Discovery Request messages. 3552 An example of this occurring is when many WTPs are powered on at the 3553 same time. 3555 Discovery Request messages MUST be sent by a WTP when no Echo 3556 Response messages are received for NeighborDeadInterval and the WTP 3557 returns to the Idle state. Discovery Request messages are sent after 3558 NeighborDeadInterval. They MUST be sent after waiting for a random 3559 delay less than MaxDiscoveryInterval. A WTP MAY send up to a maximum 3560 of MaxDiscoveries Discovery Request messages, waiting for a random 3561 delay less than MaxDiscoveryInterval between each successive message. 3563 If a Discovery Response message is not received after sending the 3564 maximum number of Discovery Request messages, the WTP enters the 3565 Sulking state and MUST wait for an interval equal to SilentInterval 3566 before sending further Discovery Request messages. 3568 The Discovery Request message may be sent as a unicast, broadcast or 3569 multicast message. 3571 Upon receiving a Discovery Request message, the AC will respond with 3572 a Discovery Response message sent to the address in the source 3573 address of the received discovery request message. 3575 The following message elements MUST be included in the Discovery 3576 Request message: 3578 o Discovery Type, see Section 4.4.18 3580 o WTP Descriptor, see Section 4.4.33 3582 o WTP Frame Tunnel Mode, see Section 4.4.35 3584 o WTP MAC Type, see Section 4.4.37 3586 o WTP Radio Information, see Section 4.4.38 3588 5.2. Discovery Response Message 3590 The Discovery Response message provides a mechanism for an AC to 3591 advertise its services to requesting WTPs. 3593 The Discovery Response message is sent by an AC after receiving a 3594 Discovery Request message from a WTP. 3596 When a WTP receives a Discovery Response message, it MUST wait for an 3597 interval not less than DiscoveryInterval for receipt of additional 3598 Discovery Response messages. After the DiscoveryInterval elapses, 3599 the WTP enters the DTLS-Init state and selects one of the ACs that 3600 sent a Discovery Response message and send a DTLS Handshake to that 3601 AC. 3603 The following message elements MUST be included in the Discovery 3604 Response Message: 3606 o AC Descriptor, see Section 4.4.1 3608 o AC Name, see Section 4.4.4 3610 o WTP Manager Control IPv4 Address, see Section 4.4.39 3612 o WTP Manager Control IPv6 Address, see Section 4.4.40 3614 5.3. Primary Discovery Request Message 3616 The Primary Discovery Request message is sent by the WTP to determine 3617 whether its preferred (or primary) AC is available. 3619 A Primary Discovery Request message is sent by a WTP when it has a 3620 primary AC configured, and is connected to another AC. This 3621 generally occurs as a result of a failover, and is used by the WTP as 3622 a means to discover when its primary AC becomes available. As a 3623 consequence, this message is only sent by a WTP when it is in the Run 3624 state. 3626 The frequency of the Primary Discovery Request messages should be no 3627 more often than the sending of the Echo Request message. 3629 Upon receipt of a Discovery Request message, the AC responds with a 3630 Primary Discovery Response message sent to the address in the source 3631 address of the received Primary Discovery Request message. 3633 The following message elements MUST be included in the Primary 3634 Discovery Request message. 3636 o Discovery Type, see Section 4.4.18 3638 o WTP Descriptor, see Section 4.4.33 3640 o WTP Frame Tunnel Mode, see Section 4.4.35 3642 o WTP MAC Type, see Section 4.4.37 3644 o WTP Radio Information, see Section 4.4.38 A WTP Radio Information 3645 message element MUST be present for every radio in the WTP. 3647 5.4. Primary Discovery Response 3649 The Primary Discovery Response message enables an AC to advertise its 3650 availability and services to requesting WTPs that are configured to 3651 have the AC as its primary AC. 3653 The Primary Discovery Response message is sent by an AC after 3654 receiving a Primary Discovery Request message. 3656 When a WTP receives a Primary Discovery Response message, it may 3657 establish a CAPWAP protocol connection to its primary AC, based on 3658 the configuration of the WTP Fallback Status message element on the 3659 WTP. 3661 The following message elements MUST be included in the Primary 3662 Discovery Response message. 3664 o AC Descriptor, see Section 4.4.1 3666 o AC Name, see Section 4.4.4 3668 o WTP Manager Control IPv4 Address, see Section 4.4.39 3670 o WTP Manager Control IPv6 Address, see Section 4.4.40 3672 6. CAPWAP Join Operations 3674 The Join Request message is used by a WTP to request service from an 3675 AC after a DTLS connection is established to that AC. The Join 3676 Response message is used by the the AC to indicate that it will or 3677 will not provide service. 3679 6.1. Join Request 3681 The Join Request message is used by a WTP to inform an AC that it 3682 wishes to provide services through the AC. A Join Request message is 3683 sent by a WTP after receiving one or more Discovery Responses, and 3684 completion of DTLS session establishment. When an AC receives a Join 3685 Request message it responds with a Join Response message. 3687 Upon completion of the DTLS handshake (synonymous with DTLS "session 3688 establishment"), the WTP sends the Join Request message to the AC. 3689 Upon receipt of the Join Request Message, the AC generates a Join 3690 Response message and sends it to the WTP, indicating success or 3691 failure. 3693 Upon transmission of the Join Request message, the WTP sets the 3694 WaitJoin timer. If the Join Response message has not been received 3695 prior to expiration, the WTP aborts the Join process and transitions 3696 back to the Discovery state, see Section 2.3.1). Upon receipt of the 3697 Join Response message, the WaitJoin timer is deactivated. 3699 If the AC rejects the Join Request, it sends a Join Response with a 3700 failure indication then enters the CAPWAP reset state, resulting in 3701 shutdown of the DTLS session. 3703 Upon determining which AC to join, the WTP creates session state 3704 containing the AC address and session ID, creates the Join Request 3705 message, sets the WaitJoin timer for the session and sends the Join 3706 Request message to the AC. 3708 If an invalid (i.e. malformed) Join Request message is received, the 3709 message MUST be silently discarded by the AC. No response is sent to 3710 the WTP. The AC SHOULD log this event. 3712 The following message elements MUST be included in the Join Request 3713 message. 3715 o Location Data, see Section 4.4.25 3717 o Session ID, see Section 4.4.29 3718 o WTP Descriptor, see Section 4.4.33 3720 o WTP IPv4 IP Address, see Section 4.4.36 3722 o WTP Name, see Section 4.4.41 3724 o WTP Radio Information, see Section 4.4.38 A WTP Radio Information 3725 message element MUST be present for every radio in the WTP. 3727 6.2. Join Response 3729 The Join Response message is sent by the AC to indicate to a WTP that 3730 it is capable and willing to provide service to it. 3732 After determining that a WTP should join the AC, the AC creates 3733 session state containing the WTP address, port and session ID, sets 3734 the WaitJoin timer for the session, sends the Join Response message 3735 to the WTP. 3737 The WTP, receiving a Join Response message checks for success or 3738 failure. If the message indicates success, the WTP clears the 3739 WaitJoin timer for the session and proceeds to the Configure or Image 3740 Data state. Otherwise, the WTP enters the CAPWAP reset state, 3741 resulting in shutdown of the DTLS session. 3743 If the WaitJoin Timer expires prior to reception of the Join Response 3744 message, the WTP MUST terminate the handshake, deallocate associated 3745 session state and transition to the Discover state. 3747 If an invalid (malformed) Join Response message is received, the WTP 3748 SHOULD log an informative message detailing the error. This error 3749 MUST be treated in the same manner as AC non-responsiveness. In this 3750 way, the WaitJoin timer will eventually expire, in which case the WTP 3751 may (if it is so configured) attempt to join with an alternative AC. 3753 The following message elements MAY be included in the Join Response 3754 message. 3756 o AC IPv4 List, see Section 4.4.2 3758 o AC IPv6 List, see Section 4.4.3 3760 o Result Code, see Section 4.4.28 3762 o Session ID, see Section 4.4.29 3764 7. Control Channel Management 3766 The Control Channel Management messages are used by the WTP and AC to 3767 maintain a control communication channel. CAPWAP control messages, 3768 such as the WTP Event Request message sent from the WTP to the AC 3769 indicate to the AC that the WTP is operational. When such control 3770 messages are not being sent, the Echo Request and Echo Response 3771 messages are used to maintain the control communication channel. 3773 7.1. Echo Request 3775 The Echo Request message is a keep alive mechanism for CAPWAP control 3776 messages. 3778 Echo Request messages are sent periodically by a WTP in the Run state 3779 (see Section 2.3) to determine the state of the connection between 3780 the WTP and the AC. The Echo Request message is sent by the WTP when 3781 the Heartbeat timer expires. The WTP MUST start its 3782 NeighborDeadInterval timer when the Heartbeat timer expires. 3784 The Echo Request message carries no message elements. 3786 When an AC receives an Echo Request message it responds with an Echo 3787 Response message. 3789 7.2. Echo Response 3791 The Echo Response message acknowledges the Echo Request message, and 3792 is only processed while in the Run state (see Section 2.3). 3794 An Echo Response message is sent by an AC after receiving an Echo 3795 Request message. After transmitting the Echo Response message, the 3796 AC SHOULD reset its Heartbeat timer to expire in the value configured 3797 for EchoInterval. If another Echo Request message or other control 3798 message is not received by the AC when the timer expires, the AC 3799 SHOULD consider the WTP to be no longer be reachable. 3801 The Echo Response message carries no message elements. 3803 When a WTP receives an Echo Response message it stops the 3804 NeighborDeadInterval timer, and initializes the Heartbeat timer to 3805 the EchoInterval. 3807 If the NeighborDeadInterval timer expires prior to receiving an Echo 3808 Response message, or other control message, the WTP enters the Idle 3809 state. 3811 8. WTP Configuration Management 3813 Wireless Termination Point Configuration messages are used to 3814 exchange configuration information between the AC and the WTP. 3816 8.1. Configuration Consistency 3818 The CAPWAP protocol provides flexibility in how WTP configuration is 3819 managed. A WTP has two options: 3821 1. The WTP retains no configuration and accepts the configuration 3822 provided by the AC. 3824 2. The WTP retains the configuration of parameters provided by the AC 3825 that are non-default values. 3827 If the WTP opts to save configuration locally, the CAPWAP protocol 3828 state machine defines the Configure state, which allows for 3829 configuration exchange. In the Configure state, the WTP sends its 3830 current configuration overrides to the AC via the Configuration 3831 Status message. A configuration override is a parameter that is non- 3832 default. One example is that in the CAPWAP protocol, the default 3833 antenna configuration is internal omni antenna. A WTP that either 3834 has no internal antennas, or has been explicitly configured by the AC 3835 to use external antennas, sends its antenna configuration during the 3836 configure phase, allowing the AC to become aware of the WTP's current 3837 configuration. 3839 Once the WTP has provided its configuration to the AC, the AC sends 3840 its own configuration. This allows the WTP to inherit the 3841 configuration and policies from the AC. 3843 An AC maintains a copy of each active WTP's configuration. There is 3844 no need for versioning or other means to identify configuration 3845 changes. If a WTP becomes inactive, the AC MAY delete the 3846 configuration associated with it. If a WTP fails, and connects to a 3847 new AC, it provides its overridden configuration parameters, allowing 3848 the new AC to be aware of the WTP's configuration. 3850 This model allows for resiliency in case of an AC failure, that 3851 another AC can provide service to the WTP. In this scenario, the new 3852 AC would be automatically updated with WTP configuration changes, 3853 eliminating the need for inter-AC communication or the need for all 3854 ACs to be aware of the configuration of all WTPs in the network. 3856 Once the CAPWAP protocol enters the Run state, the WTPs begin to 3857 provide service. It is quite common for administrators to require 3858 that configuration changes be made while the network is operational. 3860 Therefore, the Configuration Update Request is sent by the AC to the 3861 WTP to make these changes at run-time. 3863 8.1.1. Configuration Flexibility 3865 The CAPWAP protocol provides the flexibility to configure and manage 3866 WTPs of varying design and functional characteristics. When a WTP 3867 first discovers an AC, it provides primary functional information 3868 relating to its type of MAC and to the nature of frames to be 3869 exchanged. The AC configures the WTP appropriately. The AC also 3870 establishes corresponding internal operations to deal with the WTP 3871 according to its functionalities. 3873 8.2. Configuration Status 3875 The Configuration Status message is sent by a WTP to deliver its 3876 current configuration to its AC. 3878 Configuration Status messages are sent by a WTP while in the 3879 Configure state. 3881 The Configuration Status message carries binding specific message 3882 elements. Refer to the appropriate binding for the definition of 3883 this structure. 3885 When an AC receives a Configuration Status message it will act upon 3886 the content of the packet and respond to the WTP with a Configuration 3887 Status Response message. 3889 The Configuration Status message includes multiple Radio 3890 Administrative State message Elements. There is one such message 3891 element for the WTP, and one message element per radio in the WTP. 3893 The following message elements MUST be included in the Configuration 3894 Status message. 3896 o AC Name, see Section 4.4.4 3898 o AC Name with Index, see Section 4.4.5 3900 o Radio Administrative State, see Section 4.4.27 3902 o Statistics Timer, see Section 4.4.30 3904 o WTP Board Data, see Section 4.4.32 3906 o WTP Radio Information, see Section 4.4.38 A WTP Radio Information 3907 message element MUST be present for every radio in the WTP. 3909 o WTP Reboot Statistics, see Section 4.4.44 3911 o WTP Static IP Address Information, see Section 4.4.45 3913 8.3. Configuration Status Response 3915 The Configuration Status Response message is sent by an AC and 3916 provides a mechanism for the AC to override a WTP's requested 3917 configuration. 3919 Configuration Status Response messages are sent by an AC after 3920 receiving a Configure Request message. 3922 The Configuration Status Response message carries binding specific 3923 message elements. Refer to the appropriate binding for the 3924 definition of this structure. 3926 When a WTP receives a Configuration Status Response message it acts 3927 upon the content of the message, as appropriate. If the 3928 Configuration Status Response message includes a Radio Administrative 3929 State message element that causes a change in the operational state 3930 of one of the Radio, the WTP will transmit a Change State Event to 3931 the AC, as an acknowledgement of the change in state. 3933 The following message elements MUST be included in the Configuration 3934 Status Response message. 3936 o AC IPv4 List, see Section 4.4.2 3938 o AC IPv6 List, see Section 4.4.3 3940 o CAPWAP Timers, see Section 4.4.10 3942 o Radio Administrative Event, see Section 4.4.27 3944 o Decryption Error Report Period, see Section 4.4.14 3946 o Idle Timeout, see Section 4.4.21 3948 o WTP Fallback, see Section 4.4.34 3950 8.4. Configuration Update Request 3952 Configuration Update Request messages are sent by the AC to provision 3953 the WTP while in the Run state. This is used to modify the 3954 configuration of the WTP while it is operational. 3956 When an AC receives a Configuration Update Request message it will 3957 respond with a Configuration Update Response message, with the 3958 appropriate Result Code. 3960 One or more of the following message elements MAY be included in the 3961 Configuration Update message. 3963 o AC Name with Index, see Section 4.4.5 3965 o AC Timestamp, see Section 4.4.6 3967 o Add MAC ACL Entry, see Section 4.4.7 3969 o Add Static MAC ACL Entry, see Section 4.4.9 3971 o CAPWAP Timers, see Section 4.4.10 3973 o Decryption Error Report Period, see Section 4.4.14 3975 o Delete MAC ACL Entry, see Section 4.4.15 3977 o Delete Static MAC ACL Entry, see Section 4.4.17 3979 o Idle Timeout, see Section 4.4.21 3981 o Location Data, see Section 4.4.25 3983 o Radio Administrative State, see Section 4.4.27 3985 o Statistics Timer, see Section 4.4.30 3987 o WTP Fallback, see Section 4.4.34 3989 o WTP Name, see Section 4.4.41 3991 8.5. Configuration Update Response 3993 The Configuration Update Response message is the acknowledgement 3994 message for the Configuration Update Request message. 3996 The Configuration Update Response message is sent by a WTP after 3997 receiving a Configuration Update Request message. 3999 When an AC receives a Configuration Update Response message the 4000 result code indicates if the WTP successfully accepted the 4001 configuration. 4003 The following message element MUST be present in the Configuration 4004 Update message. 4006 Result Code, see Section 4.4.28 4008 8.6. Change State Event Request 4010 The Change State Event Request message is used by the WTP to inform 4011 the AC of a change in the operational state. 4013 The Change State Event Request message is sent by the WTP when it 4014 receives a Configuration Response message that includes a Change 4015 State Event message element. It is also sent when the WTP detects an 4016 operational failure with a radio. The Change State Event Request 4017 message may be sent in either the Configure or Run state (see 4018 Section 2.3. 4020 When an AC receives a Change State Event Request message it will 4021 respond with a Change State Event Response message and make any 4022 necessary modifications to internal WTP data structures. 4024 The following message elements MUST be present in the Change State 4025 Event Request message. 4027 o Radio Administrative State message element, see Section 4.4.27 4029 8.7. Change State Event Response 4031 The Change State Event Response message acknowledges the Change State 4032 Event Request message. 4034 A Change State Event Response message is sent by an AC in response to 4035 a Change State Event Request message. 4037 The Change State Event Response message carries no message elements. 4038 Its purpose is to acknowledge the receipt of the Change State Event 4039 Request message. 4041 The WTP does not need to perform any special processing of the Change 4042 State Event Response message. 4044 8.8. Clear Configuration Request 4046 The Clear Configuration Request message is used to reset a WTP's 4047 configuration. 4049 The Clear Configuration Request message is sent by an AC to request 4050 that a WTP reset its configuration to the manufacturing default 4051 configuration. The Clear Config Request message is sent while in the 4052 Run CAPWAP state. 4054 The Clear Configuration Request message carries no message elements. 4056 When a WTP receives a Clear Configuration Request message it resets 4057 its configuration to the manufacturing default configuration. 4059 8.9. Clear Configuration Response 4061 The Clear Configuration Response message is sent by the WTP after 4062 receiving a Clear Configuration Request message and resetting its 4063 configuration parameters back to the manufacturing default values. 4065 The Clear Configuration Request message carries the message elements. 4067 o Result Code, see Section 4.4.28 4069 9. Device Management Operations 4071 This section defines CAPWAP operations responsible for debugging, 4072 gathering statistics, logging, and firmware management. 4074 9.1. Image Data Request 4076 The Image Data Request message is used to update firmware on the WTP. 4077 This message and its companion response message are used by the AC to 4078 ensure that the image being run on each WTP is appropriate. 4080 Image Data Request messages are exchanged between the WTP and the AC 4081 to download a new firmware image to the WTP. When a WTP or AC 4082 receives an Image Data Request message it will respond with an Image 4083 Data Response message. The message elements contained within the 4084 Image Data Request is required in order to determine the intent of 4085 the request. Note that only one message element may be present in 4086 any given Image Data Request message. 4088 The decision that new firmware is to downloaded to the WTP can occur 4089 in one of two methods: 4091 When the WTP joins the AC, and each exchange their software 4092 revision, the WTP may opt to initiate a firmware download by 4093 sending an Image Data Request, which contains an Image Filename 4094 message element. 4096 Once the WTP is in the CAPWAP state, it is possible for the AC to 4097 cause the WTP to initiate a firmware download by initiating an 4098 Image Data Request, with the Initiate Download message element. 4099 The WTP would then transmit the Image Filename message element to 4100 start the download process. 4102 Regardless of how the download was initiated, once the AC receives an 4103 Image Data Request with the Image Filename message element, it begins 4104 the transfer process by transmitting its own request with the Image 4105 Data message element. This continues until the whole firmware image 4106 has been transfered. 4108 The following message elements MAY be included in the Image Data 4109 Request Message. 4111 o Image Data, see Section 4.4.22 4113 o Image Filename, see Section 4.4.23 4115 o Initiate Download, see Section 4.4.24 4117 9.2. Image Data Response 4119 The Image Data Response message acknowledges the Image Data Request 4120 message. 4122 An Image Data Response message is sent in response to a received 4123 Image Data Request message. Its purpose is to acknowledge the 4124 receipt of the Image Data Request message. 4126 The Image Data Response message carries no message elements. 4128 No action is necessary on receipt. 4130 9.3. Reset Request 4132 The Reset Request message is used to cause a WTP to reboot. 4134 A Reset Request message is sent by an AC to cause a WTP to 4135 reinitialize its operation. 4137 The Reset Request carries no message elements. 4139 When a WTP receives a Reset Request it will respond with a Reset 4140 Response and then reinitialize itself. 4142 9.4. Reset Response 4144 The Reset Response message acknowledges the Reset Request message. 4146 A Reset Response message is sent by the WTP after receiving a Reset 4147 Request message. 4149 The Reset Response message carries no message elements. Its purpose 4150 is to acknowledge the receipt of the Reset Request message. 4152 When an AC receives a Reset Response message, it is notified that the 4153 WTP will reinitialize its operation. 4155 9.5. WTP Event Request 4157 WTP Event Request message is used by a WTP to send information to its 4158 AC. The WTP Event Request message may be sent periodically, or sent 4159 in response to an asynchronous event on the WTP. For example, a WTP 4160 MAY collect statistics and use the WTP Event Request message to 4161 transmit the statistics to the AC. 4163 When an AC receives a WTP Event Request message it will respond with 4164 a WTP Event Response message. 4166 The WTP Event Request message MUST contain one of the message 4167 elements listed below, or a message element that is defined for a 4168 specific wireless technology. 4170 o Decryption Error Report, see Section 4.4.13 4172 o Duplicate IPv4 Address, see Section 4.4.19 4174 o Duplicate IPv6 Address, see Section 4.4.20 4176 o WTP Operational Statistics, see Section 4.4.42 4178 o WTP Radio Statistics, see Section 4.4.43 4180 o WTP Reboot Statistics, see Section 4.4.44 4182 9.6. WTP Event Response 4184 The WTP Event Response message acknowledges receipt of the WTP Event 4185 Request message. 4187 A WTP Event Response message issent by an AC after receiving a WTP 4188 Event Request message. 4190 The WTP Event Response message carries no message elements. 4192 9.7. Data Transfer Request 4194 The Data Transfer Request message is used to deliver debug 4195 information from the WTP to the AC. 4197 Data Transfer Request messages are sent by the WTP to the AC when the 4198 WTP determines that it has important information to send to the AC. 4199 For instance, if the WTP detects that its previous reboot was caused 4200 by a system crash, it can send the crash file to the AC. The remote 4201 debugger function in the WTP also uses the Data Transfer Request 4202 message to send console output to the AC for debugging purposes. 4204 When the AC receives a Data Transfer Request message it responds to 4205 the WTP ith a Data Transfer Response message. The AC MAY log the 4206 information received. 4208 The Data Transfer Request message MUST contain one of the message 4209 elements listed below. 4211 o Data Transfer Data, see Section 4.4.11 4212 o Data Transfer Mode, see Section 4.4.12 4214 9.8. Data Transfer Response 4216 The Data Transfer Response message acknowledges the Data Transfer 4217 Request message. 4219 A Data Transfer Response message is sent in response to a received 4220 Data Transfer Request message. Its purpose is to acknowledge receipt 4221 of the Data Transfer Request message. 4223 The Data Transfer Response message carries no message elements. 4225 Upon receipt of a Data Transfer Response message, the WTP transmits 4226 more information, if more information is available. 4228 10. Mobile Session Management 4230 Messages in this section are used by the AC to create, modify or 4231 delete mobile station session state on the WTPs. 4233 10.1. Mobile Configuration Request 4235 The Mobile Configuration Request message is used to create, modify or 4236 delete mobile session state on a WTP. The message is sent by the AC 4237 to the WTP, and may contain one or more message elements. The 4238 message elements for this CAPWAP control message include information 4239 that is generally highly technology specific. Refer to the 4240 appropriate binding section or document for the definitions of the 4241 messages elements that may be used in this control message. 4243 The following CAPWAP Control message elements MAY be included in the 4244 Mobile Configuration Request message. 4246 o Add Mobile Station, see Section 4.4.8 4248 o Delete Mobile Station, see Section 4.4.16 4250 10.2. Mobile Configuration Response 4252 The Mobile Configuration Response message is used to acknowledge a 4253 previously received Mobile Configuration Request message. The 4254 following message element MUST be present in the Mobile Configuration 4255 Response message. 4257 o Result Code, see Section 4.4.28 4259 The Result Code message element indicates that the requested 4260 configuration was successfully applied, or that an error related to 4261 processing of the Mobile Configuration Request message occurred on 4262 the WTP. 4264 11. IEEE 802.11 Binding 4266 This section defines the extensions required for the CAPWAP protocol 4267 to be used with the IEEE 802.11 protocol. 4269 11.1. Split MAC and Local MAC Functionality 4271 The CAPWAP protocol, when used with IEEE 802.11 devices, requires a 4272 specific behavior from the WTP and the AC, to support the required 4273 IEEE 802.11 protocol functions. 4275 For both the Split and Local MAC approaches, the CAPWAP functions, as 4276 defined in the taxonomy specification [Add reference], reside in the 4277 AC. 4279 11.1.1. Split MAC 4281 This section shows the division of labor between the WTP and the AC 4282 in a Split MAC architecture. Figure 4 shows the clear separation of 4283 functionality among CAPWAP components. 4285 Function Location 4286 Distribution Service AC 4287 Integration Service AC 4288 Beacon Generation WTP 4289 Probe Response Generation WTP 4290 Power Mgmt/Packet Buffering WTP 4291 Fragmentation/Defragmentation WTP/AC 4292 Assoc/Disassoc/Reassoc AC 4294 802.11e 4295 Classifying AC 4296 Scheduling WTP/AC 4297 Queuing WTP 4299 802.11i 4300 802.1X/EAP AC 4301 RSNA Key Management AC 4302 802.11 Encryption/Decryption WTP/AC 4304 Figure 4: Mapping of 802.11 Functions for Split MAC Architecture 4306 The Distribution and Integration services reside on the AC, and 4307 therefore all user data is tunneled between the WTP and the AC. As 4308 noted above, all real-time IEEE 802.11 services, including the beacon 4309 and probe response frames, are handled on the WTP. 4311 All remaining IEEE 802.11 MAC management frames are supported on the 4312 AC, including the Association Request which allows the AC to be 4313 involved in the access policy enforcement portion of the IEEE 802.11 4314 protocol. The IEEE 802.1X and IEEE 802.11i key management function 4315 are also located on the AC. This implies that the AAA client also 4316 resides on the AC. 4318 While the admission control component of IEEE 802.11e resides on the 4319 AC, the real time scheduling and queuing functions are on the WTP. 4320 Note this does not exclude the AC from providing additional policing 4321 and scheduling functionality. 4323 Note that in the following figure, the use of '( - )' indicates that 4324 processing of the frames is done on the WTP. 4326 Client WTP AC 4328 Beacon 4329 <----------------------------- 4330 Probe Request 4331 ----------------------------( - )-------------------------> 4332 Probe Response 4333 <----------------------------- 4334 802.11 AUTH/Association 4335 <---------------------------------------------------------> 4336 Mobile Config Request[Add Mobile (Clear Text, 802.1X)] 4337 <-------------------------> 4338 802.1X Authentication & 802.11i Key Exchange 4339 <---------------------------------------------------------> 4340 Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] 4341 <-------------------------> 4342 802.11 Action Frames 4343 <---------------------------------------------------------> 4344 802.11 DATA (1) 4345 <---------------------------( - )-------------------------> 4347 Figure 5: Split MAC Message Flow 4349 Figure 5 provides an illustration of the division of labor in a Split 4350 MAC architecture. In this example, a WLAN has been created that is 4351 configured for IEEE 802.11i, using AES-CCMP for privacy. The 4352 following process occurs: 4354 o The WTP generates the IEEE 802.11 beacon frames, using information 4355 provided to it through the Add WLAN (see Section Section 11.9.1) 4356 message element. 4358 o The WTP processes the probe request and responds with a 4359 corresponding probe response. The probe request is then forwarded 4360 to the AC for optional processing. 4362 o The WTP forwards the IEEEE 802.11 Authentication and Association 4363 frames to the AC, which is responsible for responding to the 4364 client. 4366 o Once the association is complete, the AC transmits an CAPWAP Add 4367 Mobile Station request to the WTP (see Section Section 4.4.8. In 4368 the above example, the WLAN is configured for IEEE 802.1X, and 4369 therefore the '802.1X only' policy bit is enabled. 4371 o If the WTP is providing encryption/decryption services, once the 4372 client has completed the IEEE 802.11i key exchange, the AC 4373 transmits another Add Mobile request to the WTP, stating the 4374 security policy to enforce for the client (in this case AES-CCMP), 4375 as well as the encryption key to use. If encryption/decryption is 4376 handled in the AC, the IEEE 802.11 Add Mobile Station request 4377 would not include the RSN Information Element. 4379 o The WTP forwards any 802.11 Action frames received to the AC. 4381 o All client data frames are tunneled between the WTP and the AC. 4382 Note that the WTP is responsible for encrypting and decrypting 4383 frames, if it was indicated in the Add Mobile request. 4385 11.1.2. Local MAC 4387 This section shows the division of labor between the WTP and the AC 4388 in a Local MAC architecture. Figure 6 shows the clear separation of 4389 functionality among CAPWAP components. 4391 Function Location 4392 Distribution Service WTP 4393 Integration Service WTP 4394 Beacon Generation WTP 4395 Probe Response Generation WTP 4396 Power Mgmt/Packet Buffering WTP 4397 Fragmentation/Defragmentation WTP 4398 Assoc/Disassoc/Reassoc WTP 4400 802.11e 4401 Classifying WTP 4402 Scheduling WTP 4403 Queuing WTP 4405 802.11i 4406 802.1X/EAP AC 4407 RSNA Key Management AC 4408 802.11 Encryption/Decryption WTP 4410 Figure 6: Mapping of 802.11 Functions for Local AP Architecture 4412 Given the Distribution and Integration Services exist on the WTP, 4413 client data frames are not forwarded to the AC, with the exception 4414 listed in the following paragraphs. 4416 While the MAC is terminated on the WTP, it is necessary for the AC to 4417 be aware of mobility events within the WTPs. As a consequence, the 4418 WTP MUST forward the IEEE 802.11 Association Requests to the AC. The 4419 AC MAY reply with a failed Association Response if it deems it 4420 necessary, and upon receipt of a failed Association Response from the 4421 AC, the WTP must send a Disassociation frame to the mobile station. 4423 The IEEE 802.1X and RSNA Key Management function resides in the AC. 4424 Therefore, the WTP MUST forward all IEEE 802.1X/RSNA Key Management 4425 frames to the AC and forward the associated responses to the station. 4426 This implies that the AAA client also resides on the AC. 4428 Note that in the following figure, the use of '( - )' indicates that 4429 processing of the frames is done on the WTP. 4431 Client WTP AC 4433 Beacon 4434 <----------------------------- 4435 Probe 4436 <----------------------------> 4437 802.11 AUTH 4438 <----------------------------- 4439 802.11 Association 4440 <---------------------------( - )-------------------------> 4441 Mobile Config Request[Add Mobile (Clear Text, 802.1X)] 4442 <-------------------------> 4443 802.1X Authentication & 802.11i Key Exchange 4444 <---------------------------------------------------------> 4445 802.11 Action Frames 4446 <---------------------------------------------------------> 4447 Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] 4448 <-------------------------> 4449 802.11 DATA 4450 <-----------------------------> 4452 Figure 7: Local MAC Message Flow 4454 Figure 7 provides an illustration of the division of labor in a Local 4455 MAC architecture. In this example, a WLAN has been created that is 4456 configured for IEEE 802.11i, using AES-CCMP for privacy. The 4457 following process occurs: 4459 o The WTP generates the IEEE 802.11 beacon frames, using information 4460 provided to it through the Add WLAN (see Section 11.9.1) message 4461 element. 4463 o The WTP processes the probe request and responds with a 4464 corresponding probe response. 4466 o The WTP forwards the IEEE 802.11 Authentication and Association 4467 frames to the AC. 4469 o Once the association is complete, the AC transmits an CAPWAP Add 4470 Mobile Station message element to the WTP (see Section 4471 Section 4.4.8. In the above example, the WLAN is configured for 4472 IEEE 802.1X, and therefore the '802.1X only' policy bit is 4473 enabled. 4475 o The WTP forwards all IEEE 802.1X and IEEE 802.11i key exchange 4476 messages to the AC for processing. 4478 o The AC transmits another Add Mobile Station message element to the 4479 WTP, stating the security policy to enforce for the client (in 4480 this case AES-CCMP), as well as the encryption key to use. The 4481 Add Mobile Station message element MAY include a VLAN name, which 4482 when present is used by the WTP to identify the VLAN on which the 4483 user's data frames are to be bridged. 4485 o The WTP forwards any IEEE 802.11 Action frames received to the AC. 4487 o The WTP may locally bridge client data frames (and provide the 4488 necessary encryption and decryption services). The WTP may also 4489 tunnel client data frames to the AC, using 802.3 frame tunnel mode 4490 or 802.11 frame tunnel mode. 4492 11.2. Roaming Behavior 4494 It is important that CAPWAP implementations react properly to mobile 4495 devices associating to the networks in how they generate Add Mobile 4496 and Delete Mobile messages. This section expands upon the examples 4497 provided in the previous section, and describes how the CAPWAP 4498 control protocol is used in order to provide secure roaming. 4500 Once a client has successfully associated with the network in a 4501 secure fashion, it is likely to attempt to roam to another WTP. 4502 Figure 8 shows an example of a currently associated station moving 4503 from its "Old WTP" to a "new WTP". The figure is useful for multiple 4504 different security policies, including IEEE 802.1X and dynamic WEP 4505 keys, WPA or even WPA2 both with key caching (where the IEEE 802.1x 4506 exchange would be bypassed) and without. 4508 Client Old WTP WTP AC 4510 Association Request/Response 4511 <--------------------------------------( - )--------------> 4512 Mobile Config Request[Add Mobile (Clear Text, 802.1X)] 4513 <----------------> 4514 802.1X Authentication (if no key cache entry exists) 4515 <--------------------------------------( - )--------------> 4516 802.11i 4-way Key Exchange 4517 <--------------------------------------( - )--------------> 4518 Mobile Config Request[Delete Mobile] 4519 <----------------------------------> 4520 Mobile Config Request[Add Mobile (AES-CCMP, PTK=x)] 4521 <----------------> 4523 Figure 8: Client Roaming Example 4525 11.3. Group Key Refresh 4527 Periodically, the Group Key (GTK)for the BSS needs to be updated. 4528 The AC uses an EAPoL frame to update the group key for each STA in 4529 the BSS. While the AC is updating the GTK, each L2 broadcast frame 4530 transmitted to the BSS needs to be duplicated and transmitted using 4531 both the current GTK and the new GTK. Once the GTK update process 4532 has completed, broadcast frames transmitted to the BSS will be 4533 encrypted using the new GTK. 4535 In the case of Split MAC, the AC needs to duplicate all broadcast 4536 packets and update the key index so that the packet is transmitted 4537 using both the current and new GTK to ensure that all STA's in the 4538 BSS receive the broadcast frames. In the case of local MAC, the WTP 4539 needs to duplicate and transmit broadcast frames using the 4540 appropriate index to ensure that all STA's in the BSS continue to 4541 receive broadcast frames. 4543 The Group Key update procedure is given in the following figure. The 4544 AC will signal the update to the GTK using an 802.11 Configuration 4545 Request frame with the new GTK, its index, the TSC for the Group Key 4546 and the Key Status set to 3 (begin GTK update). The AC will then 4547 begin updating the GTK for each STA. During this time, the AC (for 4548 Split MAC) or WTP (for Local MAC) must duplicate broadcast packets 4549 and transmit them encrypted with both the current and new GTK. When 4550 the AC has completed the GTK update to all STA's in the BSS, the AC 4551 must transmit an 802.11 Configuration Request frame containing the 4552 new GTK, its index, and the Key Status set to 4 (GTK update 4553 complete). 4555 Client WTP AC 4557 802.11 Config Request ( Update WLAN (GTK, GTK Index, GTK Start, Group TSC) ) 4558 <---------------------------------------------- 4559 802.1X EAPoL (GTK Message 1) 4560 <-------------( - )------------------------------------------- 4561 802.1X EAPoL (GTK Message 2) 4562 -------------( - )-------------------------------------------> 4563 802.11 Config Request ( Update WLAN (GTK Index, GTK Complete) ) 4564 <--------------------------------------------- 4566 Figure 9: Group Key Update Procedure 4568 11.4. BSSID to WLAN ID Mapping 4570 The CAPWAP protocol allows the WTP to assign BSSIDs upon creation of 4571 a WLAN (see Section 11.9.1). While manufacturers are free to assign 4572 BSSIDs using any arbitrary mechanism, it is advised that where 4573 possible the BSSIDs are assigned as a contiguous block. 4575 When assigned as a block, implementations can still assign any of the 4576 available BSSIDs to any WLAN. One possible method is for the WTP to 4577 assign the address using the following algorithm: base BSSID address 4578 + WLAN ID. 4580 The WTP communicates the maximum number of BSSIDs that it supports 4581 during the Config Request within the IEEE 802.11 WTP WLAN Radio 4582 Configuration message element (see Section 11.9.23). 4584 11.5. Quality of Service for IEEE 802.11 Control Messages 4586 It is recommended that IEEE 802.11 MAC management frames be sent by 4587 both the AC and the WTP with appropriate Quality of Service values, 4588 ensuring that congestion in the network minimizes occurrences of 4589 packet loss. Therefore, a Quality of Service enabled CAPWAP device 4590 should use: 4592 802.1P: The precedence value of 7 SHOULD be used for all IEEE 802.11 4593 MAC management frames, except for Probe Requests which SHOULD use 4594 4. 4596 DSCP: The DSCP tag value of 46 SHOULD be used for all IEEE 802.11 4597 MAC management frames, except for Probe Requests which SHOULD use 4598 34. 4600 11.6. IEEE 802.11 Specific CAPWAP Control Messages 4602 This section defines CAPWAP Control Messages that are specific to the 4603 IEEE 802.11 binding. The two messages are defined, the IEEE 802.11 4604 WLAN Config Request and IEEE 802.11 WLAN Config Response messages. 4605 See Section 4.3.1.1 4607 The valid message types for IEEE 802.11 specific control messages are 4608 listed below. The IANA Enterprise number used with these messages is 4609 13277. 4611 CAPWAP Control Message Message Type 4612 Value 4614 IEEE 802.11 WLAN Configuration Request 3398912 4615 IEEE 802.11 WLAN Configuration Response 3398913 4617 11.6.1. IEEE 802.11 WLAN Configuration Request 4619 The IEEE 802.11 WLAN Configuration Request is sent by the AC to the 4620 WTP in order to change services provided by the WTP. This control 4621 message is used to either create, update or delete a WLAN on the WTP. 4623 The IEEE 802.11 WLAN Configuration Request is sent as a result of 4624 either some manual admistrative process (e.g., deleting a WLAN), or 4625 automatically to create a WLAN on a WTP. When sent automatically to 4626 create a WLAN, this control message is sent after the CAPWAP 4627 Configure Update Request message has been received by the WTP. 4629 Upon receiving this control message, the WTP will modify the 4630 necessary services, and transmit an IEEE 802.11 WLAN Configuration 4631 Response. 4633 A WTP MAY provide service for more than one WLAN, therefore every 4634 WLAN is identified through a numerical index. For instance, a WTP 4635 that is capable of supporting up to 16 SSIDs, could accept up to 16 4636 IEEE 802.11 WLAN Configuration Request messages that include the Add 4637 WLAN message element. 4639 Since the index is the primary identifier for a WLAN, an AC MAY 4640 attempt to ensure that the same WLAN is identified through the same 4641 index number on all of its WTPs. An AC that does not follow this 4642 approach MUST find some other means of maintaining a WLAN Identifier 4643 to SSID mapping table. 4645 The following message elements may be included in the IEEE 802.11 4646 WLAN Configuration Request message. Only one message element MUST be 4647 present. 4649 o IEEE 802.11 Add WLAN, see Section 11.9.1 4651 o IEEE 802.11 Delete WLAN, see Section 11.9.4 4653 o IEEE 802.11 Information Element, see Section 11.9.6 4655 o IEEE 802.11 Update WLAN, see Section 11.9.21 4657 11.6.2. IEEE 802.11 WLAN Configuration Response 4659 The IEEE 802.11 WLAN Configuration Response message is sent by the 4660 WTP to the AC. It is used to acknowledge receipt of an IEEE 802.11 4661 WLAN Configuration Request message, and to indicate if the requested 4662 configuration was successfully applied, or if an error related to the 4663 processing of the IEEE 802.11 WLAN Configuration Request message 4664 occurred on the WTP. 4666 The following message element MAY be included in the IEEE 802.11 WLAN 4667 Configuration Response message. 4669 o IEEE 802.11 Assigned WTP BSSID, see Section 11.9.3 4671 The following message element MUST be included in the IEEE 802.11 4672 WLAN Configuration Response message. Only one message element MUST 4673 be present. 4675 o Result Code, see Section 4.4.28 4677 11.7. CAPWAP Data Message Bindings 4679 This section describes the CAPWAP Data Message bindings to support 4680 IEEE 802.11 frames. 4682 Payload encapsulation: The CAPWAP protocol defines the CAPWAP data 4683 message, which is used to encapsulate a wireless payload. For 4684 IEEE 802.11, the IEEE 802.11 header and payload are encapsulated 4685 (excluding the IEEE 802.11 FCS checksum). The IEEE 802.11 FCS 4686 checksum is handled by the WTP. This allows the WTP to validate 4687 an IEEE 802.11 frame prior to sending it to the AC. Similarly, 4688 when an AC wishes to transmit a frame towards a station, the WTP 4689 computes and adds the FCS checksum. 4691 Optional Wireless Specific Information: The optional CAPWAP header 4692 field (see Section 4.1) is only used with CAPWAP data messages, 4693 and it serves two purposes, depending upon the direction of the 4694 message. For messages from the WTP to the AC, the field uses the 4695 format described in the "IEEE 802.11 Frame Info" field (see 4696 below). However, for messages sent by the AC to the WTP, the 4697 format used is described in described in the "Destination WLANs" 4698 field (also defined below). 4700 IEEE 802.11 Frame Info: When an IEEE 802.11 frame is received from a 4701 station over the air, it is encapsulated and this field is used to 4702 include radio and PHY specific information associated with the 4703 frame. 4705 The IEEE 802.11 Frame Info field has the following format: 4707 0 1 2 3 4708 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 4709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4710 | RSSI | SNR | Data Rate | 4711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4712 RSSI: RSSI is a signed, 8-bit value. It is the received signal 4713 strength indication, in dBm. 4715 SNR: SNR is a signed, 8-bit value. It is the signal to noise 4716 ratio of the received IEEE 802.11 frame, in dB. 4718 Data Rate: The data rate field is a 16 bit unsigned value. The 4719 contents of the field is set to 1/10th of the data rate of the 4720 packet received by the WTP. For instance, a packet received at 4721 5.5Mbps would be set to 55, while 11Mbps would be set to 110. 4723 Destination WLANs The Destination WLAN field is used to specify the 4724 target WLANs for a given frame, and is only used with broadcast 4725 and multicast frames. This field allows the AC to transmit a 4726 single broadcast or multicast frame to the WTP, and allows the WTP 4727 to perform the necessary frame replication services. The field 4728 uses the following format: 4730 0 1 2 3 4731 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 4732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4733 | WLAN | Reserved | 4734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4736 WLAN: This bit field indicates the WLAN ID (see section 4737 Section 11.9.1) which the WTP will transmit the associated 4738 frame on. For instance, if a multicast packet is to be 4739 transmitted on WLANs 1 and 3, bits 1 and 3 of this field would 4740 be enabled. Note this field is to be set to zero for unicast 4741 packets and is unused if the WTP is not providing encryption 4742 services. 4744 Reserved: This field MUST be set to zero. 4746 11.8. CAPWAP Control Message bindings 4748 This section describes the IEEE 802.11 specific message elements 4749 included in CAPWAP Control Messages. 4751 11.8.1. Configuration Status Message 4753 The following IEEE 802.11 specific message elements may be included 4754 in the CAPWAP Configuration Status Message. 4756 o IEEE 802.11 Antenna, see Section 11.9.2 4758 o IEEE 802.11 Direct Sequence Control, see Section 11.9.5 4759 o IEEE 802.11 MAC Operation, see Section 11.9.7 4761 o IEEE 802.11 Multi Domain Capability, see Section 11.9.11 4763 o IEEE 802.11 OFDM Control, see Section 11.9.12 4765 o IEEE 802.11 Supported Rates, see Section 11.9.17 4767 o IEEE 802.11 Tx Power, see Section 11.9.18 4769 o IEEE 802.11 TX Power Level, see Section 11.9.19 4771 o IEEE 802.11 WTP Radio Configuration, see Section 11.9.23 4773 11.8.2. Configuration Status Response Message 4775 The following IEEE 802.11 specific message elements may be included 4776 in the CAPWAP Configuration Status Response Message. 4778 o IEEE 802.11 Antenna, see Section 11.9.2 4780 o IEEE 802.11 Direct Sequence Control, see Section 11.9.5 4782 o IEEE 802.11 MAC Operation, see Section 11.9.7 4784 o IEEE 802.11 Multi Domain Capability, see Section 11.9.11 4786 o IEEE 802.11 OFDM Control, see Section 11.9.12 4788 o IEEE 802.11 Rate Set, see Section 11.9.13 4790 o IEEE 802.11 Supported Rates, see Section 11.9.17 4792 o IEEE 802.11 Tx Power, see Section 11.9.18 4794 o IEEE 802.11 WTP Quality of Service, see Section 11.9.22 4796 o IEEE 802.11 WTP Radio Configuration, see Section 11.9.23 4798 11.8.3. Configuration Update Request Message 4800 The following IEEE 802.11 specific message elements may be included 4801 in the CAPWAP Configuration Update Request Message. 4803 o IEEE 802.11 Antenna, see Section 11.9.2 4805 o IEEE 802.11 Direct Sequence Control, see Section 11.9.5 4806 o IEEE 802.11 MAC Operation, see Section 11.9.7 4808 o IEEE 802.11 Multi Domain Capability, see Section 11.9.11 4810 o IEEE 802.11 OFDM Control, see Section 11.9.12 4812 o IEEE 802.11 Rate Set, see Section 11.9.13 4814 o IEEE 802.11 RSNA Error Report From Mobile, see Section 11.9.14 4816 o IEEE 802.11 Tx Power, see Section 11.9.18 4818 o IEEE 802.11 WTP Quality of Service, see Section 11.9.22 4820 o IEEE 802.11 WTP Radio Configuration, see Section 11.9.23 4822 11.8.4. Mobile Config Request 4824 The following IEEE 802.11 specific message elements MAY included in 4825 the CAPWAP Mobile Config Request message. 4827 o IEEE 802.11 Mobile, see Section 11.9.9 4829 o IEEE 802.11 Mobile Session Key, see Section 11.9.10 4831 o Station QoS Profile, see Section 11.9.15 4833 11.8.5. WTP Event Request 4835 The following IEEE 802.11 specific message elements may be included 4836 in the CAPWAP WTP Event Request message. 4838 o IEEE 802.11 MIC Countermeasures, see Section 11.9.8 4840 o IEEE 802.11 Statistics, see Section 11.9.16 4842 o IEEE 802.11 WTP Radio Fail Alarm Indication, see Section 11.9.24 4844 11.9. IEEE 802.11 Message Element Definitions 4846 The following IEEE 802.11 specific message elements are defined in 4847 this section. 4849 IEEE 802.11 Message Element Type Value 4851 IEEE 802.11 Add WLAN 1024 4852 IEEE 802.11 Antenna 1025 4853 IEEE 802.11 Assigned WTP BSSID 1026 4854 IEEE 802.11 Delete WLAN 1027 4855 IEEE 802.11 Direct Sequence Control 1028 4856 IEEE 802.11 Information Element 1029 4857 IEEE 802.11 MAC Operation 1030 4858 IEEE 802.11 MIC Countermeasures 1031 4859 IEEE 802.11 Mobile 1032 4860 IEEE 802.11 Mobile Session Key 1033 4861 IEEE 802.11 Multi-Domain Capability 1034 4862 IEEE 802.11 OFDM Control 1035 4863 IEEE 802.11 Rate Set 1036 4864 IEEE 802.11 RSNA Error Report From Mobile 1037 4865 IEEE 802.11 Station QoS Profile 1038 4866 IEEE 802.11 Statistics 1039 4867 IEEE 802.11 Supported Rates 1040 4868 IEEE 802.11 Tx Power 1041 4869 IEEE 802.11 Tx Power Level 1042 4870 IEEE 802.11 Update Mobile QoS 1043 4871 IEEE 802.11 Update WLAN 1044 4872 IEEE 802.11 WTP Quality of Service 1045 4873 IEEE 802.11 WTP Radio Configuration 1046 4874 IEEE 802.11 WTP Radio Fail Alarm Indication 1047 4876 11.9.1. IEEE 802.11 Add WLAN 4878 The Add WLAN message element is used by the AC to define a wireless 4879 LAN on the WTP. The inclusion of this message element MUST also 4880 include IEEE 802.11 Information Element message elements, containing 4881 the following 802.11 IEs: 4883 Power Capability information element 4885 WPA information element 4887 RSN information element 4889 EDCA Parameter Set information element 4891 QoS Capability information element 4892 WMM information element 4894 If present, the RSN information element is sent along with the IEEE 4895 802.11 Add WLAN in order to instruct the WTP on the usage of the Key 4896 field. 4898 Note that ACs MAY include additional information elements as they see 4899 fit. The message element uses the following format: 4901 0 1 2 3 4902 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 4903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4904 | Radio ID | WLAN ID | Capabilities | 4905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4906 | Key Index | Key Status | Key Length | 4907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4908 | Key... | 4909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4910 | Group TSC | 4911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4912 | Group TSC | QoS | Auth Type | 4913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4914 | MAC Mode | Tunnel Mode | Suppress SSID | SSID ... 4915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4917 Type: 1024 for IEEE 802.11 Add WLAN 4919 Length: >= 49 4921 Radio ID: An 8-bit value representing the radio. 4923 WLAN ID: An 8-bit value specifying the WLAN Identifier. 4925 Capability: A 16-bit value containing the capabilities information 4926 field to be advertised by the WTP within the Probe and Beacon 4927 messages. 4929 Key-Index: The Key Index associated with the key. 4931 Key Status: A 1 byte value that specifies the state and usage of the 4932 key that has been included. The following values describe the key 4933 usage and its status: 4935 0 - A value of zero, with the inclusion of the RSN Information 4936 Element means that the WLAN uses per-station encryption keys, and 4937 therefore the key in the 'Key' field is only used for multicast 4938 traffic. 4940 1 - When set to one, the WLAN employs a shared WEP key, also known as 4941 a static WEP key, and uses the encryption key for both unicast and 4942 multicast traffic for all stations. 4944 2 - The value of 2 indicates that the AC will begin rekeying the GTK 4945 with the STA's in the BSS. It is only valid when IEEE 802.11i is 4946 enabled as the security policy for the BSS. 4948 3 - The value of 3 indicates that the AC has completed rekeying the 4949 GTK and broadcast packets no longer need to be duplicated and 4950 transmitted with both GTK's. 4952 Key Length: A 16-bit value representing the length of the Key field. 4954 Key: A 32 byte Session Key to use to provide data privacy. For 4955 static WEP keys, which is true when the 'Key Status' bit is set to 4956 one, this key is used for both unicast and multicast traffic. For 4957 encryption schemes that employ a separate encryption key for 4958 unicast and multicast traffic, the key included hereonly applies 4959 to multicast data, and the cipher suite is specified in an 4960 accompanied RSN Information Element. In these scenarios, the key, 4961 and cipher information, is communicated via the Add Mobile Station 4962 (Section 4.4.8). 4964 Group TSC A 48-bit value containing the Transmit Sequence Counter 4965 for the updated group key. The WTP will set the TSC for 4966 broadcast/multicast frames to this value for the updated group 4967 key. 4969 QOS: An 8-bit value specifying the default QoS policy to enforce for 4970 station's traffic on this WLAN. 4972 The following values are supported: 4974 0 - Best Effort 4976 1 - Video 4978 2 - Voice 4980 3 - Background 4982 Auth Type: An 8-bit value specifying the supported authentication 4983 type. 4985 The following values are supported: 4987 0 - Open System 4989 1 - WEP Shared Key 4991 2 - WPA/WPA2 802.1X 4993 3 - WPA/WPA2 PSK 4995 MAC Mode: This field specifies whether the WTP should support the 4996 WLAN in Local or Split MAC modes. Note that the AC MUST NOT 4997 request a mode of operation that was not advertised by the WTP 4998 during the discovery process (see section Section 4.4.37). The 4999 following values are supported: 5001 0 - Local-MAC: Service for the WLAN is to be provided in Local 5002 MAC mode. 5004 1 - Split-MAC: Service for the WLAN is to be provided in Split 5005 MAC mode. 5007 Tunnel Mode: This field specifies the frame tunneling type to be 5008 used for user traffic from all stations associated with the WLAN. 5009 The AC MUST NOT request a mode of operation that was not 5010 advertised by the WTP during the discovery process (see section 5011 Section 4.4.35). IEEE 802.11 managment and control frames SHALL 5012 be tunneled using 802.11 Tunnel mode. The following values are 5013 supported: 5015 0 - Local Bridging: All user traffic is to be locally bridged. 5017 1 - 802.3 Tunnel: All user traffic is to be tunneled to the AC in 5018 802.3 format (see section Section 4.2). 5020 2 - 802.11 Tunnel: All user traffic is to be tunneled to the AC 5021 in 802.11 format. 5023 Supress SSID: A boolean indicating whether the SSID is to be 5024 advertised by the WTP. A value of zero supresses the SSID in the 5025 802.11 Beacon and Probe Response frames, while a value of one will 5026 cause the WTP to populate the field. 5028 SSID: The SSID attribute is the service set identifier that will be 5029 advertised by the WTP for this WLAN. 5031 11.9.2. IEEE 802.11 Antenna 5033 The antenna message element is communicated by the WTP to the AC to 5034 provide information on the antennas available. The AC MAY use this 5035 element to reconfigure the WTP's antennas. The value contains the 5036 following fields: 5038 0 1 2 3 5039 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 5040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5041 | Radio ID | Diversity | Combiner | Antenna Cnt | 5042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5043 | Antenna Selection [0..N] | 5044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5046 Type: 1025 for IEEE 802.11 Antenna 5048 Length: >= 5 5050 Radio ID: An 8-bit value representing the radio to configure. 5052 Diversity: An 8-bit value specifying whether the antenna is to 5053 provide receive diversity. The value of this field is the same as 5054 the IEEE 802.11 dot11DiversitySelectionRx MIB element (see [6]). 5055 The following values are supported: 5057 0 - Disabled 5059 1 - Enabled (may only be true if the antenna can be used as a 5060 receive antenna) 5062 Combiner: An 8-bit value specifying the combiner selection. The 5063 following values are supported: 5065 1 - Sectorized (Left) 5067 2 - Sectorized (Right) 5069 3 - Omni 5071 4 - MIMO 5073 Antenna Count: An 8-bit value specifying the number of Antenna 5074 Selection fields. This value should be the same as the one found 5075 in the IEEE 802.11 dot11CurrentTxAntenna MIB element (see [6]). 5077 Antenna Selection: One 8-bit antenna configuration value per antenna 5078 in the WTP. The following values are supported: 5080 1 - Internal Antenna 5082 2 - External Antenna 5084 11.9.3. IEEE 802.11 Assigned WTP BSSID 5086 The IEEE 802.11 Assigned WTP BSSID is only included by the WTP when 5087 the IEEE 802.11 WLAN Config Request included the IEEE 802.11 Add WLAN 5088 message element. The value field of this message element contains 5089 the BSSID that has been assigned by the WTP, which allows the WTP to 5090 perform its own BSSID assignment. 5092 The WTP is free to assign the BSSIDs the way it sees fit, but it is 5093 highly recommended that the WTP assign the BSSID using the following 5094 algorithm: BSSID = {base BSSID} + WLAN ID. 5096 0 1 2 3 5097 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 5098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5099 | Radio ID | WLAN ID | BSSID 5100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5101 | BSSID | 5102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5104 Type: 1026 for IEEE 802.11 Assigned WTP BSSID 5106 Length: 6 5108 Radio ID: An 8-bit value representing the radio. 5110 WLAN ID: An 8-bit value specifying the WLAN Identifier. 5112 BSSID: The BSSID assigned by the WTP for the WLAN created as a 5113 result of receiving an IEEE 802.11 Add WLAN. 5115 11.9.4. IEEE 802.11 Delete WLAN 5117 The delete WLAN message element is used to inform the WTP that a 5118 previously created WLAN is to be deleted. The value contains the 5119 following fields: 5121 0 1 5122 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5124 | Radio ID | WLAN ID | 5125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5127 Type: 1027 for IEEE 802.11 Delete WLAN 5129 Length: 3 5131 Radio ID: An 8-bit value representing the radio 5133 WLAN ID: An 8-bit value specifying the WLAN Identifier 5135 11.9.5. IEEE 802.11 Direct Sequence Control 5137 The direct sequence control message element is a bi-directional 5138 element. When sent by the WTP, it contains the current state. When 5139 sent by the AC, the WTP MUST adhere to the values. This element is 5140 only used for 802.11b radios. The value has the following fields. 5142 0 1 2 3 5143 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 5144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5145 | Radio ID | Reserved | Current Chan | Current CCA | 5146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5147 | Energy Detect Threshold | 5148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5150 Type: 1028 for IEEE 802.11 Direct Sequence Control 5152 Length: 8 5154 Radio ID: An 8-bit value representing the radio to configure. 5156 Reserved: MUST be set to zero 5158 Current Channel: This attribute contains the current operating 5159 frequency channel of the DSSS PHY. This value comes from the IEEE 5160 802.11 dot11CurrentChannel MIB element (see [6]). 5162 Current CCA: The current CCA method in operation, whose value can be 5163 found in the IEEE 802.11 dot11CCAModeSupported MIB element (see 5164 [6]). Valid values are: 5166 1 - energy detect only (edonly) 5168 2 - carrier sense only (csonly) 5169 4 - carrier sense and energy detect (edandcs) 5171 8 - carrier sense with timer (cswithtimer) 5173 16 - high rate carrier sense and energy detect (hrcsanded) 5175 Energy Detect Threshold: The current Energy Detect Threshold being 5176 used by the DSSS PHY. The value can be found in the IEEE 802.11 5177 dot11EDThreshold MIB element (see [6]). 5179 11.9.6. IEEE 802.11 Information Element 5181 The IEEE 802.11 Information Element is used to communicate any IE 5182 defined in the IEEE 802.11 protocol. The data field contains the raw 5183 IE as it would be included within an IEEE 802.11 MAC management 5184 message. 5186 0 1 2 3 5187 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 5188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5189 | Radio ID | WLAN ID |B|P| Flags |Info Element... 5190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5192 Type: 1029 for IEEE 802.11 Information Element 5194 Length: >= 2 5196 Radio ID: An 8-bit value representing the radio. 5198 WLAN ID: An 8-bit value specifying the WLAN Identifier. 5200 B: When set, the WTP is to include the information element in 5201 beacons associated with the WLAN. 5203 P: When set, the WTP is to include the information element in probe 5204 responses associated with the WLAN. 5206 Flags: Reserved field and MUST be set to zero. 5208 Info Element: The IEEE 802.11 Information Element, which includes 5209 the type, length and value field. 5211 11.9.7. IEEE 802.11 MAC Operation 5213 The MAC operation message element is sent by the AC to set the 802.11 5214 MAC parameters on the WTP. The value contains the following fields. 5216 0 1 2 3 5217 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 5218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5219 | Radio ID | Reserved | RTS Threshold | 5220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5221 | Short Retry | Long Retry | Fragmentation Threshold | 5222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5223 | Tx MSDU Lifetime | 5224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5225 | Rx MSDU Lifetime | 5226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5228 Type: 1030 for IEEE 802.11 MAC Operation 5230 Length: 16 5232 Radio ID: An 8-bit value representing the radio to configure. 5234 Reserved: MUST be set to zero 5236 RTS Threshold: This attribute indicates the number of octets in an 5237 MPDU, below which an RTS/CTS handshake MUST NOT be performed. An 5238 RTS/CTS handshake MUST be performed at the beginning of any frame 5239 exchange sequence where the MPDU is of type Data or Management, 5240 the MPDU has an individual address in the Address1 field, and the 5241 length of the MPDU is greater than this threshold. Setting this 5242 attribute to be larger than the maximum MSDU size MUST have the 5243 effect of turning off the RTS/CTS handshake for frames of Data or 5244 Management type transmitted by this STA. Setting this attribute 5245 to zero MUST have the effect of turning on the RTS/CTS handshake 5246 for all frames of Data or Management type transmitted by this STA. 5247 The default value of this attribute MUST be 2347. The value of 5248 this field comes from the IEEE 802.11 dot11RTSThreshold MIB 5249 element (see [6]). 5251 Short Retry: This attribute indicates the maximum number of 5252 transmission attempts of a frame, the length of which is less than 5253 or equal to RTSThreshold, that MUST be made before a failure 5254 condition is indicated. The default value of this attribute MUST 5255 be 7. The value of this field comes from the IEEE 802.11 5256 dot11ShortRetryLimit MIB element (see [6]). 5258 Long Retry: This attribute indicates the maximum number of 5259 transmission attempts of a frame, the length of which is greater 5260 than dot11RTSThreshold, that MUST be made before a failure 5261 condition is indicated. The default value of this attribute MUST 5262 be 4. The value of this field comes from the IEEE 802.11 5263 dot11LongRetryLimit MIB element (see [6]). 5265 Fragmentation Threshold: This attribute specifies the current 5266 maximum size, in octets, of the MPDU that MAY be delivered to the 5267 PHY. An MSDU MUST be broken into fragments if its size exceeds 5268 the value of this attribute after adding MAC headers and trailers. 5269 An MSDU or MMPDU MUST be fragmented when the resulting frame has 5270 an individual address in the Address1 field, and the length of the 5271 frame is larger than this threshold. The default value for this 5272 attribute MUST be the lesser of 2346 or the aMPDUMaxLength of the 5273 attached PHY and MUST never exceed the lesser of 2346 or the 5274 aMPDUMaxLength of the attached PHY. The value of this attribute 5275 MUST never be less than 256. The value of this field comes from 5276 the IEEE 802.11 dot11FragmentationThreshold MIB element (see [6]). 5278 Tx MSDU Lifetime: This attribute speficies the elapsed time in TU, 5279 after the initial transmission of an MSDU, after which further 5280 attempts to transmit the MSDU MUST be terminated. The default 5281 value of this attribute MUST be 512. The value of this field 5282 comes from the IEEE 802.11 dot11MaxTransmitMSDULifetime MIB 5283 element (see [6]). 5285 Rx MSDU Lifetime: This attribute specifies the elapsed time in TU, 5286 after the initial reception of a fragmented MMPDU or MSDU, after 5287 which further attempts to reassemble the MMPDU or MSDU MUST be 5288 terminated. The default value MUST be 512. The value of this 5289 field comes from the IEEE 802.11 dot11MaxReceiveLifetime MIB 5290 element (see [6]). 5292 11.9.8. IEEE 802.11 MIC Countermeasures 5294 The MIC Countermeasures message element is sent by the WTP to the AC 5295 to indicate the occurrence of a MIC failure. See the IEEE 802.11 5296 dot11RSNATKIPCounterMeasuresInvoked MIB element (see [6]) for more 5297 info. 5299 0 1 2 3 5300 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 5301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5302 | Radio ID | WLAN ID | MAC Address | 5303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5304 | MAC Address | 5305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5307 Type: 1031 for IEEE 802.11 MIC Countermeasures 5309 Length: 8 5310 Radio ID: The Radio Identifier, typically refers to some interface 5311 index on the WTP. 5313 WLAN ID: This 8-bit unsigned integer includes the WLAN Identifier, 5314 on which the MIC failure occurred. 5316 MAC Address: The MAC Address of the mobile station that caused the 5317 MIC failure. 5319 11.9.9. IEEE 802.11 Mobile 5321 The IEEE 802.11 Mobile message element accompanies the Add Mobile 5322 message element, and is used to deliver IEEE 802.11 station policy 5323 from the AC to the WTP. 5325 The latest IEEE 802.11 Mobile message element overrides any 5326 previously received message elements. 5328 If the QoS field is set, the WTP MUST observe and provide policing of 5329 the 802.11e priority tag to ensure that it does not exceed the value 5330 provided by the AC. 5332 0 1 2 3 5333 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 5334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5335 | Radio ID | Association ID | Flags | 5336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5337 | Capabilities | WLAN ID |Supported Rates 5338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5340 Type: 1032 for IEEE 802.11 Mobile 5342 Length: >= 8 5344 Radio ID: An 8-bit value representing the radio 5346 Association ID: A 16-bit value specifying the IEEE 802.11 5347 Association Identifier 5349 Flags: The Flags field MUST be set to zero 5351 Capabilities: A 16-bit field containing the IEEE 802.11 Capabilities 5352 Information Field to use with the mobile. 5354 WLAN ID: An 8-bit value specifying the WLAN Identifier 5355 Supported Rates: The variable length field containing the supported 5356 rates to be used with the mobile station, as found in the IEEE 5357 802.11 dot11OperationalRateSet MIB element (see [6]). 5359 11.9.10. IEEE 802.11 Mobile Session Key 5361 The Mobile Session Key Payload message element is sent when the AC 5362 determines that encryption of a mobile station must be performed in 5363 the WTP. This message element MUST NOT be present without the IEEE 5364 802.11 Mobile (see Section 11.9.9) message element, and MUST NOT be 5365 sent if the WTP had not specifically advertised support for the 5366 requested encryption scheme. 5368 The RSN information element MUST sent along with the IEEE 802.11 5369 Mobile Session Key in order to instruct the WTP on the usage of the 5370 Key field. The AKM field of the RSM information element is used by 5371 the WTP to identify the authentication protocol. 5373 If the IEEE 802.11 Mobile Session Key message element's AKM-Only bit 5374 is set, the WTP MUST drop all IEEE 802.11 packets that are not part 5375 of the AKM (e.g., EAP). Note that AKM-Only is MAY be set while an 5376 encryption key is in force, requiring that the AKM packets be 5377 encrypted. Once the mobile station has successfully completed 5378 authentication via the AKM, the AC must send a new Add Mobile message 5379 element to remove the AKM-Only restriction, and optionally push the 5380 session key down to the WTP. 5382 0 1 2 3 5383 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 5384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5385 | MAC Address | 5386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5387 | MAC Address |A|C| Flags | 5388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5389 | Pairwise TSC | 5390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5391 | Pairwise TSC | Pairwise RSC | 5392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5393 | Pairwise RSC | 5394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5395 | Key... 5396 +-+-+-+-+-+-+-+- 5398 Type: 1033 for IEEE 802.11 Mobile Session Key 5399 Length: >= 25 5401 MAC Address: The mobile station's MAC Address 5403 Flags: A 16 bit field, whose unused bits MUST be set to zero. The 5404 following bits are defined: 5406 A: The one bit AKM-Only field is set by the AC to inform the WTP 5407 that is MUST NOT accept any 802.11 data frames, other than AKM 5408 frames. This is the equivalent of the WTP's IEEE 802.1X port 5409 for the mobile station to be in the closed state. When set, 5410 the WTP MUST drop any non-IEEE 802.1X packets it receives from 5411 the mobile station. 5413 C: The one bit field is set by the AC to inform the WTP that 5414 encryption services will be provided by the AC. When set, the 5415 WTP SHOULD police frames received from stations to ensure that 5416 are properly encrypted as specified in the RSN Information 5417 Element, but does not need to take specific cryptographic 5418 action on the frame. Similarly, for transmitted frames, the 5419 WTP only needs to forward already encrypted frames. 5421 Pairwise TSC: The 6 byte Transmit Sequence Counter (TSC) field to 5422 use for unicast packets transmitted to the mobile. 5424 Pairwise RSC: The 6 byte Receive Sequence Counter (RSC) to use for 5425 unicast packets received from the mobile. 5427 Key: The key the WTP is to use when encrypting traffic to/from the 5428 mobile station. For dynamically created keys, this is commonly 5429 known as a Pairwise Transient Key (PTK). 5431 11.9.11. IEEE 802.11 Multi-Domain Capability 5433 The multi-domain capability message element is used by the AC to 5434 inform the WTP of regulatory limits. The AC will transmit one 5435 message element per frequency band to indicate the regulatory 5436 constraints in that domain. The value contains the following fields. 5438 0 1 2 3 5439 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 5440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5441 | Radio ID | Reserved | First Channel # | 5442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5443 | Number of Channels | Max Tx Power Level | 5444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5446 Type: 1034 for IEEE 802.11 Multi-Domain Capability 5448 Length: 8 5450 Radio ID: An 8-bit value representing the radio to configure. 5452 Reserved: MUST be set to zero 5454 First Channnel #: This attribute indicates the value of the lowest 5455 channel number in the subband for the associated domain country 5456 string. The value of this field comes from the IEEE 802.11 5457 dot11FirstChannelNumber MIB element (see [6]). 5459 Number of Channels: This attribute indicates the value of the total 5460 number of channels allowed in the subband for the associated 5461 domain country string. The value of this field comes from the 5462 IEEE 802.11 dot11NumberofChannels MIB element (see [6]). 5464 Max Tx Power Level: This attribute indicates the maximum transmit 5465 power, in dBm, allowed in the subband for the associated domain 5466 country string. The value of this field comes from the IEEE 5467 802.11 dot11MaximumTransmitPowerLevel MIB element (see [6]). 5469 11.9.12. IEEE 802.11 OFDM Control 5471 The OFDM control message element is a bi-directional element. When 5472 sent by the WTP, it contains the current state. When sent by the AC, 5473 the WTP MUST adhere to the values. This element is only used for 5474 802.11a radios. The value contains the following fields: 5476 0 1 2 3 5477 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 5478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5479 | Radio ID | Reserved | Current Chan | Band Support | 5480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5481 | TI Threshold | 5482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5484 Type: 1035 for IEEE 802.11 OFDM Control 5486 Length: 8 5488 Radio ID: An 8-bit value representing the radio to configure. 5490 Reserved: MUST be set to zero 5491 Current Channel: This attribute contains the current operating 5492 frequency channel of the OFDM PHY. The value of this field comes 5493 from the IEEE 802.11 dot11CurrentFrequency MIB element (see [6]). 5495 Band Supported: The capability of the OFDM PHY implementation to 5496 operate in the three U-NII bands. The value of this field comes 5497 from the IEEE 802.11 dot11FrequencyBandsSupported MIB element (see 5498 [6]), coded as an integer value of a three bit field as follows: 5500 capable of operating in the lower (5.15-5.25 GHz) U-NII band 5502 capable of operating in the middle (5.25-5.35 GHz) U-NII band 5504 capable of operating in the upper (5.725-5.825 GHz) U-NII band 5506 For example, for an implementation capable of operating in the 5507 lower and mid bands this attribute would take the value 3. 5509 TI Threshold: The Threshold being used to detect a busy medium 5510 (frequency). CCA MUST report a busy medium upon detecting the 5511 RSSI above this threshold. The value of this field comes from the 5512 IEEE 802.11 dot11TIThreshold MIB element (see [6]). 5514 11.9.13. IEEE 802.11 Rate Set 5516 The rate set message element value is sent by the AC and contains the 5517 supported operational rates. It contains the following fields. 5519 0 1 2 3 5520 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 5521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5522 | Radio ID | Rate Set... 5523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5525 Type: 1036 for IEEE 802.11 Rate Set 5527 Length: >= 3 5529 Radio ID: An 8-bit value representing the radio to configure. 5531 Rate Set: The AC generates the Rate Set that the WTP is to include 5532 in it's Beacon and Probe messages. The length of this field is 5533 between 2 and 8 bytes. The value of this field comes from the 5534 IEEE 802.11 dot11OperationalRateSet MIB element (see [6]). 5536 11.9.14. IEEE 802.11 RSNA Error Report From Mobile 5538 The RSN Error Report From Mobile message element is sent by an AC to 5539 an WTP to send RSN error reports to the AC. The WTP does not need to 5540 transmit any reports that do not include any failures. The fields 5541 from this message element comes from the IEEE 802.11 5542 Dot11RSNAStatsEntry table (see [6]). 5544 0 1 2 3 5545 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 5546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5547 | Client MAC Address | 5548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5549 | Client MAC Address | BSSID | 5550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5551 | BSSID | 5552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5553 | Radio ID | WLAN ID | Reserved | 5554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5555 | TKIP ICV Errors | 5556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5557 | TKIP Local MIC Failures | 5558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5559 | TKIP Remote MIC Failures | 5560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5561 | CCMP Replays | 5562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5563 | CCMP Decrypt Errors | 5564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5565 | TKIP Replays | 5566 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5568 Type: 1037 for IEEE 802.11 RSNA Error Report From Mobile 5570 Length: 14 5572 Client MAC Address: The Client MAC Address of the station. 5574 BSSID: The BSSID on which the failures are being reported on. 5576 Radio ID: The Radio Identifier, typically refers to some interface 5577 index on the WTP 5579 WLAN ID: The WLAN ID on which the RSNA failures are being reported. 5581 TKIP ICV Errors: A 32-bit value representing the number of TKIP ICV 5582 errors encountered when decrypting packets from the station. The 5583 value of this field comes from the IEEE 802.11 5584 dot11RSNAStatsTKIPICVErrors MIB element (see [6]). 5586 TKIP Local MIC Failures: A 32-bit value representing the number of 5587 MIC failures encountered when checking the integrity of packets 5588 received from the station. The value of this field comes from the 5589 IEEE 802.11 dot11RSNAStatsTKIPLocalMICFailures MIB element (see 5590 [6]). 5592 TKIP Remote MIC Failures: A 32-bit value representing the number of 5593 MIC failures reported by the station encountered (possibly via the 5594 EAPOL-Key frame). The value of this field comes from the IEEE 5595 802.11 dot11RSNAStatsTKIPRemoteMICFailures MIB element (see [6]). 5597 CCMP Replays: A 32-bit value representing the number of CCMP MPDUs 5598 discarded by the replay detection mechanism. The value of this 5599 field comes from the IEEE 802.11 dot11RSNACCMPReplays MIB element 5600 (see [6]). 5602 CCMP Decrypt Errors: A 32-bit value representing the number of CCMP 5603 MDPUs discarded by the decryption algorithm. The value of this 5604 field comes from the IEEE 802.11 dot11RSNACCMPDecryptErrors MIB 5605 element (see [6]). 5607 TKIP Replays: A 32-bit value representing the number of TKIP Replays 5608 detected in frames received from the station. The value of this 5609 field comes from the IEEE 802.11 dot11RSNAStatsTKIPReplays MIB 5610 element (see [6]). 5612 11.9.15. IEEE 802.11 Station QoS Profile 5614 The Station QoS Profile Payload message element contains the maximum 5615 IEEE 802.11e priority tag that may be used by the station. Any 5616 packet received that exceeds the value encoded in this message 5617 element must either be dropped or tagged using the maximum value 5618 permitted by to the user. The priority tag must be between zero (0) 5619 and seven (7). 5621 0 1 2 3 5622 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 5623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5624 | MAC Address | 5625 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5626 | MAC Address | 802.1P Precedence Tag | 5627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5629 Type: 1038 for IEEE 802.11 Station QOS Profile 5631 Length: 8 5633 MAC Address: The mobile station's MAC Address 5635 802.1P Precedence Tag: The maximum 802.1P precedence value that the 5636 WTP will allow in the TID field in the extended 802.11e QOS Data 5637 header. 5639 11.9.16. IEEE 802.11 Statistics 5641 The statistics message element is sent by the WTP to transmit it's 5642 current statistics. The value contains the following fields. 5644 0 1 2 3 5645 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 5646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5647 | Radio ID | Reserved | 5648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5649 | Tx Fragment Count | 5650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5651 | Multicast Tx Count | 5652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5653 | Failed Count | 5654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5655 | Retry Count | 5656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5657 | Multiple Retry Count | 5658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5659 | Frame Duplicate Count | 5660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5661 | RTS Success Count | 5662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5663 | RTS Failure Count | 5664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5665 | ACK Failure Count | 5666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5667 | Rx Fragment Count | 5668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5669 | Multicast RX Count | 5670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5671 | FCS Error Count | 5672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5673 | Tx Frame Count | 5674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5675 | Decryption Errors | 5676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5677 | Discarded QoS Fragment Count | 5678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5679 | Associated Station Count | 5680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5681 | QoS CF Polls Received Count | 5682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5683 | QoS CF Polls Unused Count | 5684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5685 | QoS CF Polls Unusable Count | 5686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5688 Type: 1039 for IEEE 802.11 Statistics 5690 Length: 60 5692 Radio ID: An 8-bit value representing the radio. 5694 Tx Fragment Count: A 32-bit value representing the number of 5695 fragmented frames transmitted. The value of this field comes from 5696 the IEEE 802.11 dot11TransmittedFragmentCount MIB element (see 5697 [6]). 5699 Multicast Tx Count: A 32-bit value representing the number of 5700 multicast frames transmitted. The value of this field comes from 5701 the IEEE 802.11 dot11MulticastTransmittedFrameCount MIB element 5702 (see [6]). 5704 Failed Count: A 32-bit value representing the transmit excessive 5705 retries. The value of this field comes from the IEEE 802.11 5706 dot11FailedCount MIB element (see [6]). 5708 Retry Count: A 32-bit value representing the number of transmit 5709 retries. The value of this field comes from the IEEE 802.11 5710 dot11RetryCount MIB element (see [6]). 5712 Multiple Retry Count: A 32-bit value representing the number of 5713 transmits that required more than one retry. The value of this 5714 field comes from the IEEE 802.11 dot11MultipleRetryCount MIB 5715 element (see [6]). 5717 Frame Duplicate Count: A 32-bit value representing the duplicate 5718 frames received. The value of this field comes from the IEEE 5719 802.11 dot11FrameDuplicateCount MIB element (see [6]). 5721 RTS Success Count: A 32-bit value representing the number of 5722 successfully transmitted Ready To Send (RTS). The value of this 5723 field comes from the IEEE 802.11 dot11RTSSuccessCount MIB element 5724 (see [6]). 5726 RTS Failure Count: A 32-bit value representing the failed 5727 transmitted RTS. The value of this field comes from the IEEE 5728 802.11 dot11RTSFailureCount MIB element (see [6]). 5730 ACK Failure Count: A 32-bit value representing the number of failed 5731 acknowledgements. The value of this field comes from the IEEE 5732 802.11 dot11ACKFailureCount MIB element (see [6]). 5734 Rx Fragment Count: A 32-bit value representing the number of 5735 fragmented frames received. The value of this field comes from 5736 the IEEE 802.11 dot11ReceivedFragmentCount MIB element (see [6]). 5738 Multicast RX Count: A 32-bit value representing the number of 5739 multicast frames received. The value of this field comes from the 5740 IEEE 802.11 dot11MulticastReceivedFrameCount MIB element (see 5741 [6]). 5743 FCS Error Count: A 32-bit value representing the number of FCS 5744 failures. The value of this field comes from the IEEE 802.11 5745 dot11FCSErrorCount MIB element (see [6]). 5747 Decryption Errors: A 32-bit value representing the number of 5748 Decryption errors that occurred on the WTP. Note that this field 5749 is only valid in cases where the WTP provides encryption/ 5750 decryption services. The value of this field comes from the IEEE 5751 802.11 dot11WEPUndecryptableCount MIB element (see [6]). 5753 Discarded QoS Fragment Count: A 32-bit value representing the number 5754 of discarded QoS fragments received. The value of this field 5755 comes from the IEEE 802.11 dot11QoSDiscardedFragmentCount MIB 5756 element (see [6]). 5758 Associated Station Count: A 32-bit value representing the number of 5759 number of associated stations. The value of this field comes from 5760 the IEEE 802.11 dot11AssociatedStationCount MIB element (see [6]). 5762 QoS CF Polls Received Count: A 32-bit value representing the number 5763 of (+)CF-Polls received. The value of this field comes from the 5764 IEEE 802.11 dot11QosCFPollsReceivedCount MIB element (see [6]). 5766 QoS CF Polls Unused Count: A 32-bit value representing the number of 5767 (+)CF-Polls that have been received, but not used. The value of 5768 this field comes from the IEEE 802.11 dot11QosCFPollsUnusedCount 5769 MIB element (see [6]). 5771 QoS CF Polls Unusable Count: A 32-bit value representing the number 5772 of (+)CF-Polls that have been received, but could not be used due 5773 to the TXOP size being smaller than the timethat is required for 5774 one frame exchange sequence. The value of this field comes from 5775 the IEEE 802.11 dot11QosCFPollsUnusableCount MIB element (see 5776 [6]). 5778 11.9.17. IEEE 802.11 Supported Rates 5780 The supported rates message element is sent by the WTP to indicate 5781 the rates that it supports. The value contains the following fields. 5783 0 1 2 3 5784 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 5785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5786 | Radio ID | Supported Rates... 5787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5789 Type: 1040 for IEEE 802.11 Supported Rates 5791 Length: >= 3 5793 Radio ID: An 8-bit value representing the radio. 5795 Supported Rates: The WTP includes the Supported Rates that its 5796 hardware supports. The format is identical to the Rate Set 5797 message element and is between 2 and 8 bytes in length. 5799 11.9.18. IEEE 802.11 Tx Power 5801 The Tx power message element value is bi-directional. When sent by 5802 the WTP, it contains the current power level of the radio in 5803 question. When sent by the AC, it contains the power level the WTP 5804 MUST adhere to. 5806 0 1 2 3 5807 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 5808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5809 | Radio ID | Reserved | Current Tx Power | 5810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5812 Type: 1041 for IEEE 802.11 Tx Power 5814 Length: 4 5816 Radio ID: An 8-bit value representing the radio to configure. 5818 Reserved: MUST be set to zero 5820 Current Tx Power: This attribute contains the transmit output power 5821 in mW. 5823 11.9.19. IEEE 802.11 Tx Power Level 5825 The Tx power level message element is sent by the WTP and contains 5826 the different power levels supported. The values found in this 5827 message element are found in the IEEE 802.11 Dot11PhyTxPowerEntry MIB 5828 table (see (see [6]). 5830 The value field contains the following: 5832 0 1 2 3 5833 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 5834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5835 | Radio ID | Num Levels | Power Level [n] | 5836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5838 Type: 1042 for IEEE 802.11 Tx Power Level 5840 Length: >= 4 5842 Radio ID: An 8-bit value representing the radio to configure. 5844 Num Levels: The number of power level attributes. The value of this 5845 field comes from the IEEE 802.11 dot11NumberSupportedPowerLevels 5846 MIB element (see [6]). 5848 Power Level: Each power level fields contains a supported power 5849 level, in mW. The value of this field comes from the 5850 corresponding IEEE 802.11 dot11TxPowerLevel[n] MIB element (see 5851 [6]). 5853 11.9.20. IEEE 802.11 Update Mobile QoS 5855 The Update Mobile QoS message element is used to change the Quality 5856 of Service policy on the WTP for a given mobile station. 5858 0 1 2 3 5859 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 2 5860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5861 | Radio ID | MAC Address | 5862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5863 | MAC Address | DSCP Tag | 802.1P Tag | 5864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5866 Type: 1043 for IEEE 802.11 Update Mobile QoS 5868 Length: 8 5870 Radio ID: The Radio Identifier, typically refers to some interface 5871 index on the WTP 5873 MAC Address: The mobile station's MAC Address. 5875 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 5877 802.1P Tag: The 802.1P precedence value to use if packets are to be 5878 IEEE 802.1P tagged. 5880 11.9.21. IEEE 802.11 Update WLAN 5882 The Update WLAN message element is used by the AC to define a 5883 wireless LAN on the WTP. The inclusion of this message element MUST 5884 also include the IEEE 802.11 Information Element message element, 5885 containing the following 802.11 IEs: 5887 Power Capability information element 5889 WPA information element 5891 RSN information element 5893 EDCA Parameter Set information element 5895 QoS Capability information element 5897 WMM information element 5899 The message element uses the following format: 5901 0 1 2 3 5902 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 5903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5904 | Radio ID | WLAN ID | Capability | 5905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5906 | Key Index | Key Status | Key Length | 5907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5908 | Key... | 5909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5911 Type: 1044 for IEEE 802.11 Update WLAN 5913 Length: 43 5915 Radio ID: An 8-bit value representing the radio. 5917 WLAN ID: An 8-bit value specifying the WLAN Identifier. 5919 Capability: A 16-bit value containing the capabilities information 5920 field to be advertised by the WTP within the Probe and Beacon 5921 messages. 5923 Key-Index: The Key Index associated with the key. 5925 Key Status: A 1 byte value that specifies the state and usage of the 5926 key that has been included. The following values describe the key 5927 usage and its status: 5929 0 - A value of zero, with the inclusion of the RSN Information 5930 Element means that the WLAN uses per-station encryption keys, and 5931 therefore the key in the 'Key' field is only used for multicast 5932 traffic. 5934 1 - When set to one, the WLAN employs a shared WEP key, also known as 5935 a static WEP key, and uses the encryption key for both unicast and 5936 multicast traffic for all stations. 5938 2 - The value of 2 indicates that the AC will begin rekeying the GTK 5939 with the STA's in the BSS. It is only valid when IEEE 802.11i is 5940 enabled as the security policy for the BSS. 5942 3 - The value of 3 indicates that the AC has completed rekeying the 5943 GTK and broadcast packets no longer need to be duplicated and 5944 transmitted with both GTK's. 5946 Key Length: A 16-bit value representing the length of the Key field. 5948 Key: A 32 byte Session Key to use to provide data privacy. For 5949 static WEP keys, which is true when the 'Key Status' bit is set to 5950 one, this key is used for both unicast and multicast traffic. For 5951 encryption schemes that employ a separate encryption key for 5952 unicast and multicast traffic, the key included hereonly applies 5953 to multicast data, and the cipher suite is specified in an 5954 accompanied RSN Information Element. In these scenarios, the key, 5955 and cipher information, is communicated via the Add Mobile Station 5956 (Section 4.4.8). 5958 11.9.22. IEEE 802.11 WTP Quality of Service 5960 The WTP Quality of Service message element value is sent by the AC to 5961 the WTP to communicate quality of service configuration information. 5963 0 1 5964 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 5965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5966 | Radio ID | Tag Packets | 5967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5969 Type: 1045 for IEEE 802.11 WTP Quality of Service 5971 Length: >= 2 5973 Radio ID: The Radio Identifier, typically refers to some interface 5974 index on the WTP 5976 Tag Packets: An value indicating whether CAPWAP packets should be 5977 tagged with for QoS purposes. The following values are currently 5978 supported: 5980 0 - Untagged 5982 1 - 802.1P 5984 2 - DSCP 5986 Immediately following the above header is the following data 5987 structure. This data structure will be repeated five times; once 5988 for every QoS profile. The order of the QoS profiles are Voice, 5989 Video, Best Effort and Background. 5991 0 1 2 3 5992 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 5993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5994 | Queue Depth | CWMin | CWMax | 5995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5996 | CWMax | AIFS | Dot1P Tag | DSCP Tag | 5997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5999 Queue Depth: The number of packets that can be on the specific QoS 6000 transmit queue at any given time. 6002 CWMin: The Contention Window minimum value for the QoS transmit 6003 queue. The value of this field comes from the IEEE 802.11 6004 dot11EDCATableCWMin MIB element (see [6]). 6006 CWMax: The Contention Window maximum value for the QoS transmit 6007 queue. The value of this field comes from the IEEE 802.11 6008 dot11EDCATableCWMax MIB element (see [6]). 6010 AIFS: The Arbitration Inter Frame Spacing to use for the QoS 6011 transmit queue. The value of this field comes from the IEEE 6012 802.11 dot11EDCATableAIFSN MIB element (see [6]). 6014 Dot1P Tag: The 802.1P precedence value to use if packets are to be 6015 802.1P tagged. 6017 DSCP Tag: The DSCP label to use if packets are to be DSCP tagged. 6019 11.9.23. IEEE 802.11 WTP Radio Configuration 6021 The WTP WLAN radio configuration is used by the AC to configure a 6022 Radio on the WTP, and by the WTP to deliver its radio configuration 6023 to the AC. The message element value contains the following fields: 6025 0 1 2 3 6026 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 6027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6028 | Radio ID |Short Preamble| Num of BSSIDs | DTIM Period | 6029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6030 | BSSID | 6031 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6032 | BSSID | Beacon Period | 6033 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6034 | Country Code | 6035 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6037 Type: 1046 for IEEE 802.11 WTP WLAN Radio Configuration 6039 Length: 16 6041 Radio ID: An 8-bit value representing the radio to configure. 6043 Short Preamble: An 8-bit value indicating whether short preamble is 6044 supported. The following values are currently supported: 6046 0 - Short preamble not supported. 6048 1 - Short preamble is supported. 6050 BSSID: The WLAN Radio's base MAC Address. 6052 Number of BSSIDs: This attribute contains the maximum number of 6053 BSSIDs supported by the WTP. This value restricts the number of 6054 logical networks supported by the WTP, and is between 1 and 16. 6056 DTIM Period: This attribute specifies the number of beacon intervals 6057 that elapse between transmission of Beacons frames containing a 6058 TIM element whose DTIM Count field is 0. This value is 6059 transmitted in the DTIM Period field of Beacon frames. The value 6060 of this field comes from the IEEE 802.11 dot11DTIMPeriod MIB 6061 element (see [6]). 6063 Beacon Period: This attribute specifies the number of TU that a 6064 station uses for scheduling Beacon transmissions. This value is 6065 transmitted in Beacon and Probe Response frames. The value of 6066 this field comes from the IEEE 802.11 dot11BeaconPeriod MIB 6067 element (see [6]). 6069 Country Code: This attribute identifies the country in which the 6070 station is operating. The value of this field comes from the IEEE 6071 802.11 dot11CountryString MIB element (see [6]). Special 6072 attention is required with use of this field, as implementations 6073 which take action based on this field could violate regulatory 6074 requirements. Some regulatory bodies do permit configuration of 6075 the country code under certain restrictions, such as the FCC, when 6076 WTPs are certified as Software Defined Radios. 6078 The WTP and AC may ignore the value of this field, depending upon 6079 regulatory requirements, for example to avoid classification as a 6080 Software Defined Radio. When this field is used, the first two 6081 octets of this string is the two character country code as 6082 described in document ISO/IEC 3166- 1, and the third octet MUST 6083 have the value 1, 2 or 3 as defined below. When the value of the 6084 third octet is 255, the country code field is not used, and MUST 6085 be ignored. 6087 1 an ASCII space character, if the regulations under which the 6088 station is operating encompass all environments in the country, 6090 2 an ASCII 'O' character, if the regulations under which the 6091 station is operating are for an outdoor environment only, or 6093 3 an ASCII 'I' character, if the regulations under which the 6094 station is operating are for an indoor environment only 6096 255 Country Code field is not used; ignore the field. 6098 11.9.24. IEEE 802.11 WTP Radio Fail Alarm Indication 6100 The WTP Radio Fail Alarm Indication message element is sent by the 6101 WTP to the AC when it detects a radio failure. 6103 0 1 2 3 6104 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 6105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6106 | Radio ID | Type | Status | Pad | 6107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6109 Type: 1047 for IEEE 802.11 WTP Radio Fail Alarm Indication 6111 Length: 4 6113 Radio ID: The Radio Identifier, typically refers to some interface 6114 index on the WTP 6116 Type: The type of radio failure detected. The following values are 6117 supported: 6119 1 - Receiver 6121 2 - Transmitter 6123 Status: An 8-bit boolean indicating whether the radio failure is 6124 being reported or cleared. A value of zero is used to clear the 6125 event, while a value of one is used to report the event. 6127 Pad: Reserved field MUST be set to zero (0). 6129 11.10. Technology Specific Message Element Values 6131 This section lists IEEE 802.11 specific values for any generic CAPWAP 6132 message elements which include fields whose values are technology 6133 specific. 6135 IEEE 802.11 uses the following values: 6137 4 - Encrypt AES-CCMP 128: WTP supports AES-CCMP, as defined in [7]. 6139 5 - Encrypt TKIP-MIC: WTP supports TKIP and Michael, as defined in 6140 [24]. 6142 12. NAT Considerations 6144 There are two specific situations in which a NAT system may be used 6145 in conjunction with a CAPWAP-enabled system. The first consists of a 6146 configuration where the WTP is behind a NAT system. Given that all 6147 communication is initiated by the WTP, and all communication is 6148 performed over IP using two UDP ports, the protocol easily traverses 6149 NAT systems in this configuration. 6151 The second configuration is one where the AC sits behind a NAT. Two 6152 issues exist in this situation. First, an AC communicates its 6153 interfaces, and associated WTP load on these interfaces, through the 6154 WTP Manager Control IP Address. This message element is currently 6155 mandatory, and if NAT compliance became an issue, it would be 6156 possible to either: 6158 1. Make the WTP Manager Control IP Address optional, allowing the WTP 6159 to simply use the known IP Address. However, note that this 6160 approach would eliminate the ability to perform load balancing of 6161 WTP across ACs, and therefore is not the recommended approach. 6163 2. Allow an AC to be able to configure a NAT'ed address for every 6164 associated AC that would generally be communicated in the WTP 6165 Manager Control IP Address message element. 6167 3. Require that if a WTP determines that the AC List message element 6168 consists of a set of IP Addresses that are different from the AC's 6169 IP Address it is currently communicating with, then assume that 6170 NAT is being enforced, and require that the WTP communicate with 6171 the original AC's IP Address (and ignore the WTP Manager Control 6172 IP Address message element(s). 6174 Another issue related to having an AC behind a NAT system is CAPWAP's 6175 support for the CAPWAP Objective to allow the control and data plane 6176 to be separated. In order to support this requirement, the CAPWAP 6177 protocol defines the WTP Manager Data IP Address message element, 6178 which allows the AC to inform the WTP that the CAPWAP data frames are 6179 to be forwarded to a separate IP Address. This feature MUST be 6180 disabled when an AC is behind a NAT. However, there is no easy way 6181 to provide some default mechanism that satisfies both the data/ 6182 control separation and NAT objectives, as they directly conflict with 6183 each other. As a consequence, user intervention will be required to 6184 support such networks. 6186 The CAPWAP protocol allows for all of the ACs identities supporting a 6187 group of WTPs to be communicated through the AC List message element. 6188 This feature must be disabled when the AC is behind a NAT and the IP 6189 Address that is embedded would be invalid. 6191 The CAPWAP protocol has a feature that allows an AC to configure a 6192 static IP address on a WTP. The WTP Static IP Address Information 6193 message element provides such a function, however this feature SHOULD 6194 NOT be used in NAT'ed environments, unless the administrator is 6195 familiar with the internal IP addressing scheme within the WTP's 6196 private network, and does not rely on the public address seen by the 6197 AC. 6199 When a WTP detects the duplicate address condition, it generates a 6200 message to the AC, which includes the Duplicate IP Address message 6201 element. The IP Address embedded within this message element is 6202 different from the public IP address seen by the AC. 6204 13. Security Considerations 6206 This section describes security considerations for the CAPWAP 6207 protocol. It also provides security recommendations for protocols 6208 used in conjunction with CAPWAP. 6210 13.1. CAPWAP Security 6212 As it is currently specified, the CAPWAP protocol sits between the 6213 security mechanisms specified by the wireless link layer protocol 6214 (e.g.IEEE 802.11i) and AAA. One goal of CAPWAP is to bootstrap trust 6215 between the STA and WTP using a series of preestablished trust 6216 relationships: 6218 STA WTP AC AAA 6219 ============================================== 6221 DTLS Cred AAA Cred 6222 <------------><-------------> 6224 EAP Credential 6225 <------------------------------------------> 6227 wireless link layer 6228 (e.g.802.11 PTK) 6229 <--------------> or 6230 <---------------------------> 6231 (derived) 6233 Within CAPWAP, DTLS is used to secure the link between the WTP and 6234 AC. In addition to securing control messages, it's also a link in 6235 this chain of trust for establishing link layer keys. Consequently, 6236 much rests on the security of DTLS. 6238 In some CAPWAP deployment scenarios, there are two channels between 6239 the WTP and AC: the control channel, carrying CAPWAP control 6240 messages, and the data channel, over which client data packets are 6241 tunneled between the AC and WTP. Typically, the control channel is 6242 secured by DTLS, while the data channel is not. 6244 The use of parallel protected and unprotected channels deserves 6245 special consideration, but does not create a threat. There are two 6246 potential concerns: attempting to convert protected data into un- 6247 protected data and attempting to convert un-protected data into 6248 protected data. These concerns are addressed below. 6250 13.1.1. Converting Protected Data into Unprotected Data 6252 Since CAPWAP does not support authentication-only ciphers (i.e. all 6253 supported ciphersuites include encryption and authentication), it is 6254 not possible to convert protected data into unprotected data. Since 6255 encrypted data is (ideally) indistinguishable from random data, the 6256 probability of an encrypted packet passing for a well-formed packet 6257 is effectively zero. 6259 13.1.2. Converting Unprotected Data into Protected Data (Insertion) 6261 The use of message authentication makes it impossible for the 6262 attacker to forge protected records. This makes conversion of 6263 unprotected records to protected records impossible. 6265 13.1.3. Deletion of Protected Records 6267 An attacker could remove protected records from the stream, though 6268 not undetectably so, due the built-in reliability of the underlying 6269 CAPWAP protocol. In the worst case, the attacker would remove the 6270 same record repeatedly, resulting in a CAPWAP session timeout and 6271 restart. This is effectively a DoS attack, and could be accomplished 6272 by a man in the middle regardless of the CAPWAP protocol security 6273 mechanisms chosen. 6275 13.1.4. Insertion of Unprotected Records 6277 An attacker could inject packets into the unprotected channel, but 6278 this may become evident if sequence number desynchronization occurs 6279 as a result. Only if the attacker is a MiM can packets be inserted 6280 undetectably. This is a consequence of that channel's lack of 6281 protection, and not a new threat resulting from the CAPWAP security 6282 mechanism. 6284 13.2. Use of Preshared Keys in CAPWAP 6286 While use of preshared keys may provide deployment and provisioning 6287 advantages not found in public key based deployments, it also 6288 introduces a number of operational and security concerns. In 6289 particular, because the keys must typically be entered manually, it 6290 is common for people to base them on memorable words or phrases. 6291 These are referred to as "low entropy passwords/passphrases". 6293 Use of low-entropy preshared keys, coupled with the fact that the 6294 keys are often not frequently updated, tends to significantly 6295 increase exposure. For these reasons, we make the following 6296 recommendations: 6298 o When DTLS is used with a preshared-key (PSK) ciphersuite, each WTP 6299 SHOULD have a unique PSK. Since WTPs will likely be widely 6300 deployed, their physical security is not guaranteed. If PSKs are 6301 not unique for each WTP, key reuse would allow the compromise of 6302 one WTP to result in the compromise of others 6304 o Generating PSKs from low entropy passwords is NOT RECOMMENDED. 6306 o It is RECOMMENDED that implementations that allow the 6307 administrator to manually configure the PSK also provide a 6308 capability for generation of new random PSKs, taking RFC 1750 [4] 6309 into account. 6311 o Preshared keys SHOULD be periodically updated. Implementations 6312 may facilitate this by providing an administrative interface for 6313 automatic key generation and periodic update, or it may be 6314 accomplished manually instead. 6316 13.3. Use of Certificates in CAPWAP 6318 For public-key-based DTLS deployments, each device SHOULD have unique 6319 credentials, with an extended key usage authorizing them to act as 6320 either a WTP or AC. If devices do not have unique credentials, it is 6321 possible that by compromising one, any other one using the same 6322 credential may also be considered to be compromised. 6324 Certificate validation involves checking a large variety of things. 6325 Since the necessary things to validate are often environment- 6326 specific, many are beyond the scope of this document. In this 6327 section, we provide some basic guidance on certificate validation. 6329 Each device is responsible for authenticating and authorizing devices 6330 with which they communicate. Authentication entails validation of 6331 the chain of trust leading to the peer certificate, followed by the 6332 the peer certificate itself. At a minimum, devices SHOULD use SSH- 6333 style certificate caching to guarantee consistency. If devices have 6334 access to a certificate authority, they SHOULD properly validate the 6335 trust chain. Implementations SHOULD also provide a secure method for 6336 verifying that the credential in question has not been revoked. 6338 Note that if the WTP relies on the AC for network connectivity (e.g. 6339 the AC is a layer 2 switch to which the WTP is directly connected), 6340 there is a chicken and egg problem, in that the WTP may not be able 6341 to contact an OCSP server or otherwise obtain an up to date CRL if a 6342 compromised AC doesn't explicitly permit this. This cannot be 6343 avoided, except through effective physical security and monitoring 6344 measures at the AC. 6346 Proper validation of certificates typically requires checking to 6347 ensure the certificate has not yet expired. If devices have a real- 6348 time clock, they SHOULD verify the certificate validity dates. If no 6349 real-time clock is available, the device SHOULD attempt to determine 6350 the current time using NTP prior to certificate validation. If 6351 neither is available, devices SHOULD verify that the start validity 6352 date of its peer's certificate is less than its own certificate's 6353 expiration date, and its peer's expiration date is greater than its 6354 own start date. Note that failure to check a certificate's temporal 6355 validity can make a device vulnerable to man-in-the-middle attacks 6356 launched using compromised, expired certificates, and therefore 6357 devices should make every effort to perform this validation. 6359 Another important part of certificate authentication is binding a 6360 certificate to a particular device. There are many ways to 6361 accomplish this. CAPWAP RECOMMENDS specifying the certificate common 6362 name (CN) as the WTP or AC MAC address formatted as ASCII HEX, 6363 followed by an @ symbol, and then an administrative domain. For 6364 example, 01:23:45:67:89:ab@DOMAIN.NET. During authentication, 6365 devices SHOULD ensure that the MAC matches the MAC specified in the 6366 CAPWAP header, and that the domain in both the AC and WTP 6367 certificates match. 6369 13.4. AAA Security 6371 The AAA protocol is used to distribute EAP keys to the ACs, and 6372 consequently its security is important to the overall system 6373 security. When used with TLS or IPsec, security guidelines specified 6374 in RFC 3539 [12] SHOULD be followed. 6376 In general, the link between the AC and AAA server SHOULD be secured 6377 using a strong ciphersuite keyed with mutually authenticated session 6378 keys. Implementations SHOULD NOT rely solely on Basic RADIUS shared 6379 secret authentication as it is often vulnerable to dictionary 6380 attacks, but rather SHOULD use stronger underlying security 6381 mechanisms. 6383 13.5. IEEE 802.11 Security 6385 When used with an IEEE 802.11 infrastructure with WEP encryption, the 6386 CAPWAP protocol does not add any new vulnerabilities. Derived 6387 session keys between the STA and WTP can be compromised, resulting in 6388 many well-documented attacks. Implementors SHOULD discourage the use 6389 of WEP and encourage use of technically sound cryptographic solutions 6390 such as those in an IEEE 802.11 RSN. 6392 STA authentication in CAPWAP is performed using IEEE 802.lX, and 6393 consequently EAP. Implementors SHOULD use EAP methods meeting the 6394 requirements specified in RFC4017 [13]. 6396 14. IANA Considerations 6398 A separate UDP port for data channel communications is (currently) 6399 the selected demultiplexing mechanism, and a port must be assigned 6400 for this purpose. 6402 15. References 6404 15.1. Normative References 6406 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 6407 Levels", BCP 14, RFC 2119, March 1997. 6409 [2] National Institute of Standards and Technology, "Advanced 6410 Encryption Standard (AES)", FIPS PUB 197, November 2001, 6411 . 6413 [3] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC- 6414 MAC (CCM)", RFC 3610, September 2003. 6416 [4] Eastlake, D., Crocker, S., and J. Schiller, "Randomness 6417 Recommendations for Security", RFC 1750, December 1994. 6419 [5] Manner, J. and M. Kojo, "Mobility Related Terminology", 6420 RFC 3753, June 2004. 6422 [6] "Information technology - Telecommunications and information 6423 exchange between systems - Local and metropolitan area networks 6424 - Specific requirements - Part 11: Wireless LAN Medium Access 6425 Control (MAC) and Physical Layer (PHY) specifications", 6426 IEEE Standard 802.11, 1999, 6427 . 6430 [7] "Information technology - Telecommunications and information 6431 exchange between systems - Local and metropolitan area networks 6432 - Specific requirements - Part 11: Wireless LAN Medium Access 6433 Control (MAC) and Physical Layer (PHY) specifications Amendment 6434 6: Medium Access Control (MAC) Security Enhancements", 6435 IEEE Standard 802.11i, July 2004, . 6438 [8] Clark, D., "IP datagram reassembly algorithms", RFC 815, 6439 July 1982. 6441 [9] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) 6442 Key Wrap Algorithm", RFC 3394, September 2002. 6444 [10] Mills, D., "Network Time Protocol (Version 3) Specification, 6445 Implementation", RFC 1305, March 1992. 6447 [11] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 6448 Public Key Infrastructure Certificate and Certificate 6449 Revocation List (CRL) Profile", RFC 3280, April 2002. 6451 [12] Aboba, B. and J. Wood, "Authentication, Authorization and 6452 Accounting (AAA) Transport Profile", RFC 3539, June 2003. 6454 [13] Stanley, D., Walker, J., and B. Aboba, "Extensible 6455 Authentication Protocol (EAP) Method Requirements for Wireless 6456 LANs", RFC 4017, March 2005. 6458 [14] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites for 6459 Transport Layer Security (TLS)", RFC 4279, December 2005. 6461 [15] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) 6462 Protocol Version 1.1", RFC 4346, April 2006. 6464 [16] Clancy, C., "Security Review of the Light Weight Access Point 6465 Protocol", May 2005, 6466 . 6468 [17] Rescorla et al, E., "Datagram Transport Layer Security", 6469 June 2004. 6471 [18] "Recommendation for Block Cipher Modes of Operation: the CMAC 6472 Mode for Authentication", May 2005, . 6475 15.2. Informational References 6477 [19] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by an On- 6478 line Database", RFC 3232, January 2002. 6480 [20] Bradner, S., "The Internet Standards Process -- Revision 3", 6481 BCP 9, RFC 2026, October 1996. 6483 [21] Kent, S. and R. Atkinson, "Security Architecture for the 6484 Internet Protocol", RFC 2401, November 1998. 6486 [22] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing 6487 for Message Authentication", RFC 2104, February 1997. 6489 [23] Karn, P. and W. Simpson, "ICMP Security Failures Messages", 6490 RFC 2521, March 1999. 6492 [24] "WiFi Protected Access (WPA) rev 1.6", April 2003. 6494 [25] Dierks et al, T., "The TLS Protocol Version 1.1", June 2005. 6496 [26] Modadugu et al, N., "The Design and Implementation of Datagram 6497 TLS", Feb 2004. 6499 [27] "Internet Key Exchange (IKEv2) Protocol", 6500 draft-ietf-ipsec-ikev2-17.txt", September 2004. 6502 Editors' Addresses 6504 Pat R. Calhoun 6505 Cisco Systems, Inc. 6506 170 West Tasman Drive 6507 San Jose, CA 95134 6509 Phone: +1 408-853-5269 6510 Email: pcalhoun@cisco.com 6512 Michael P. Montemurro 6513 Research In Motion 6514 5090 Commerce Blvd 6515 Mississauga, ON L4W 5M4 6516 Canada 6518 Phone: +1 905-629-4746 x4999 6519 Email: mmontemurro@rim.com 6521 Dorothy Stanley 6522 Aruba Networks 6523 1322 Crossman Ave 6524 Sunnyvale, CA 94089 6526 Phone: +1 630-363-1389 6527 Email: dstanley@arubanetworks.com 6529 Intellectual Property Statement 6531 The IETF takes no position regarding the validity or scope of any 6532 Intellectual Property Rights or other rights that might be claimed to 6533 pertain to the implementation or use of the technology described in 6534 this document or the extent to which any license under such rights 6535 might or might not be available; nor does it represent that it has 6536 made any independent effort to identify any such rights. Information 6537 on the procedures with respect to rights in RFC documents can be 6538 found in BCP 78 and BCP 79. 6540 Copies of IPR disclosures made to the IETF Secretariat and any 6541 assurances of licenses to be made available, or the result of an 6542 attempt made to obtain a general license or permission for the use of 6543 such proprietary rights by implementers or users of this 6544 specification can be obtained from the IETF on-line IPR repository at 6545 http://www.ietf.org/ipr. 6547 The IETF invites any interested party to bring to its attention any 6548 copyrights, patents or patent applications, or other proprietary 6549 rights that may cover technology that may be required to implement 6550 this standard. Please address the information to the IETF at 6551 ietf-ipr@ietf.org. 6553 Disclaimer of Validity 6555 This document and the information contained herein are provided on an 6556 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 6557 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 6558 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 6559 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 6560 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 6561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 6563 Copyright Statement 6565 Copyright (C) The Internet Society (2006). This document is subject 6566 to the rights, licenses and restrictions contained in BCP 78, and 6567 except as set forth therein, the authors retain all their rights. 6569 Acknowledgment 6571 Funding for the RFC Editor function is currently provided by the 6572 Internet Society.